1 INFORMATION SYSTEMS CONCEPTS 1.0 INTRODUCTION The term system is in common parlance.

People talk of transport system, educational system, solar system and many others. System concepts provide a framework for many organizational phenomenons including features of information system. 1.1 DEFINITION OF A SYSTEM The term system may be defined as a set of interrelated elements that operate collectively to accomplish some common purpose or goal. One can find many examples of a system. Human body is a system, consisting of various parts such as head heart, hands, legs and so on. The various body parts are related by means of connecting networks of blood vessels and nerves. This systems has a main goal which we may call living. Thus, a system can be described by specifying its parts, the way in which they are related, and the goals which they are expected to achieve. A business is also a system where economic resources such as people, money, material, machines, etc are transformed by various organisational processes (such as production, marketing, finance etc.) into goods and services. A computer based information system is also a system which is a collection of people, hardware, software, data and procedures that interact to provide timely information to authorised people who need it. Systems can be abstract or physical. An abstract system is an orderly arrangement of interdependent ideas or constructs. For example, a system of theology is an orderly arrangement of ideas about Good and the relationship of humans to God. A physical system is a set of elements which operate together to accomplish an objective. A physical system may be further defined by examples: Physical system Circulatory system Transportation system Description The heart and blood vessels which move blood through the body. The personnel, machines, and organisations which transport goods.

1.2 Information Systems Control and Audit Weapons system School system The equipment, procedures, and personnel which make it possible to use a weapon. The buildings, teachers, administrators, and textbooks that function together to provide instruction for students. The equipment which functions, together to accomplish computer processing The records, rules, procedures, equipment, and personnel, which operate to record data, measure income, and prepare reports. Computer system Accounting system The examples illustrate that a system is not a randomly assembled set of elements; it consists of elements, which can be identified as belonging together because of a common purpose, goal, or objective. Physical systems are more than conceptual construct; they display activity or behaviour. The parts interact to achieve an objective. 1.1.1 General model of a system : A general models of a physical system is input, process and output. This is, of course, very simplified because a system may have several inputs and outputs as shown below: Input Process Simple system model Output Input1 Input2 Process Inputn System with many inputs and outputs Output1 Output2 Outputn Fig. 1 Figure 1

Information Systems Concepts 1.1.2 System Environment 1.3 All systems function within some sort of environment. The environment like the system, is a collection of elements. These elements surround the system and often interact with it. For any given problem, there are many types of systems and many types of environments. Thus, it is important to be clear about what constitutes the system and the environment of interest. For example, a physiologist looking at human system may be interested in studying the entire human body as a system, and not just a part of it (such as the central nervous system only). If the entire human body is the system of interest, the physiologist is likely to define the environment more broadly than he might if the focus was on just the central nervous system. The features that define and delineate a system form its boundary. The system is inside the boundary; the environment is outside the boundary. In some cases, it is fairly simple to define what is part of the system and what is not; in other cases, the person studying the system may arbitrarily define the boundaries. Some examples of boundaries are: System Human Automobile Production Boundary Skin, hair, nails, and all parts contained inside form the system; all things outside are environment. The automobile body plus tires and all parts contained within form the system. Production machines, production inventory of work in process, production employees, production procedures, etc. form the system. The rest of the company is in the environment. The production system example illustrates the problem of the boundary concept. Is raw material inventory included in the production system? One definition of the production system may include raw material because it is necessary for the purpose being studied; another use may exclude it. A system and its environment can be described in many ways. A subsystem is a part of a larger system. Each system is composed of subsystems, which in turn are made up of other subsystems, each sub-system being delineated by its boundaries. The interconnections and interactions between the subsystems are termed interfaces. Interfaces occur at the boundary and take the form of inputs and outputs. Figure 3 shows examples of subsystems and interfaces at boundaries.

1.4 Information Systems Control and Audit Computer Configuration as system Storage Subsystem Storage Units Input Subsystem Processing Subsystem Output Subsystem Input Units CPU Output Units Interfaces (at channels) Central Processing unit as system Subsystem Subsystem Subsystem Arithmetic Unit Control Unit Storage Units Interfaces Figure 2 A supra-system refers to the entity formed by a system and other equivalent systems with which it interacts. For example, an organisation may be subdivided into numerous functional areas such as marketing, finance, manufacturing, research and development, and so on. Each of these functional areas can be viewed as a subsystem of a larger organisational system because each could be considered to be a system in and of itself. For example, marketing may be viewed as a system that consists of elements such as market research, advertising, sales, and so on. Collectively, these elements in the marketing area may be viewed as making up the marketing supra-system. Similarly the various functional areas (subsystems) of an organisation are elements in the same supra- system within the organisation. 1.1.3 Sub Systems The use of subsystems as building blocks is basic to analysis and development. This requires an understanding of the principles, which dictate how systems are built from subsystems.

Information Systems Concepts 1.5 Decomposition : A complex system is difficult to comprehend when considered as a whole. Therefore the system is decomposed or factored into subsystems. The boundaries and interfaces are defined, so that the sum of the subsystems constitutes the entire system. This process of decomposition is continued with subsystems divided into smaller subsystems until the smallest subsystems are of manageable size. The subsystems resulting from this process generally form hierarchical structures (Figure 3). In the hierarchy, a subsystem is one element of supra-system (the system above it). Hierarchical relations of subsystems System Subsystem A Subsystem B Subsystem C A1 A2 B1 B2 B3 C1 C2 A2 1 A2 2 C1 1 C1 2 Figure 3 An example of decomposition is the factoring of an information processing system into subsystems. One approach to decomposition might proceed as follows: 1. Information system divided

into subsystem such as: a. Sales and order entry b. Inventory c. Production d. Personnel and payroll e. Purchasing f. Accounting and control g. Planning h. Environmental intelligence 2. Each subsystem is divided further into subsystems. For example, the personnel and payroll subsystem might be divided into the following smaller subsystems:

1.6 Information Systems Control and Audit a. Creation and update of personnel pay-roll records b. Personnel reports c. Payroll data entry and validation d. Hourly payroll processing e. Salaried payroll processing f. Payroll reports for management g. Payroll reports for government 3. If the task is to design and program a new system, the subsystems (major applications) defined in (2) might be further subdivided into smaller subsystems or modules. For example, the hourly payroll processing subsystem might be factored into modules for the calculation of deductions and net pay, payroll register and audit controls preparation, cheque printing, and register and controls output (Figure 4). Hourly payroll processing Calculation of gross pay, deductions, and net pay Preparation of payroll register and audit controls Cheque Printing Payroll register and controls output Figure 4 Decomposition into subsystems is used to analyse an existing system and to design and implement a new system. In both cases, the investigator or designer must decide how to factor, i.e., where to draw the boundaries. The decisions will depend on the objectives of the decomposition and also on individual differences among designers: the latter should be minimized. 1.1.4 Characteristics of a business system We have described system as an organized grouping of interdependent functioning units or components, linked together according to a plan, to achieve a specific objective. Doing business is also a system with its components being marketing, manufacturing, sales, research, shipping, accounting and personnel. All these components work together with a common focus to create a profit that benefits the organization. All systems have some common characteristics. These are as follows:

Information Systems Concepts 1) 2) 1.7 All systems work for predetermined objectives and the system is designed and developed accordingly. In general a system has a number of interrelated and interdependent subsystems or components. No subsystem can function in isolation; it depends on other subsystems for its inputs. If one subsystem or component of a system fails, in most cases the whole system does not work. However, it depends on how the subsystems are interrelated. The way a subsystem works with another subsystem is called interaction. The different subsystems interact with each other to achieve the goal of the system The work done by individual subsystems is integrated to achieve the central goal of the system. The goal of individual subsystem is of lower priority than the goal of the entire system. 3) 4) 5) 1.2 NATURE AND TYPES OF SYSTEM The word system is used to refer to development of a systematic and theoretical framework to convert an input into a desirable format of output for further use. A system may be even 100% manual. In earlier days, all accounting procedures and transactions, production details or sales data used to be maintained in different ledgers that were created by human efforts only and all these were manual systems. With introduction of computers and complexity in business procedures, these manual jobs were passed to computers in a major way and now a business system inherently involves a close man-machine interaction. The reasons for using computer in business area are as follows: Handling huge volume of data that is not manageable by human efforts. Storing enormous volume of data for indefinite period without any decay. Quick and accurate processing of data to match the competitive environment. Quick retrieval of information on query. Quick and efficient transportation of data/information to distant places almost at no cost. Availability of software tools for quick decision making in a complex situation. Thus we may categorize the systems broadly in two categories: Manual system where data collection, manipulation, maintenance and final reporting are carried out absolutely by human efforts. Automated systems where computers or microprocessors are used to carry out all the tasks mentioned above. However it will be wrong to say that a business system is 100% automated; rather, to some extent, it depends on manual intervention, may be in a negligible way. Computers made it possible to carry out processing which would have been either too difficult or too much timeconsuming or even impossible to do manually.

1.8 Information Systems Control and Audit 1.2.1 Computer-based business system Today use of computers or Information Technology (IT) has become a strategic necessity for running a business and IT has become a vital component of successful businesses and organizations. In fact in every wing of business, managers identify opportunities to forge ahead or to improve with the help of IT. One of the advantages of use of IT in business functions is a better costperformance ratio compared to that of traditional labour intensive manual systems. Major areas of computer-based applications are finance and accounting, marketing and sales, manufacturing, inventory/stock management, human resource management etc. Finance and accounting The main goal of this subsystem (considering Business functions as whole system) is to ensure financial viability of the organization, enforce financial discipline and plan and monitor the financial budget. Also it helps forecasting revenues, determining the best resources and uses of funds and managing other financial resources. Typical sub-application areas in finance and accounting are: Financial accounting General ledger Accounts receivable/payable Asset accounting Investment management Cash management Treasury management Fund management Balance sheet Marketing and sales Marketing and sales activities have great importance in running a business successfully in a competitive environment. The objective of this subsystem is to maximize sales and ensure customer satisfaction. The marketing system facilitates the chances of order procurement by marketing the products of the company, creating new customers and advertising the products. The sales department may use an order processing system to keep status and track of orders. It may also generate bills for the orders executed and delivered to the customer. Servicing is an important function of sales department. Strategies for rendering services during warranty period and beyond may be implemented by using a computer based system that uses a large database of customers. Analyzing the sales data by category such as by region, product, salesman or sales value helps the corporate managers take decisions in many crucial areas. The system may also be used to compute commissions for dealers or salesmen.

Information Systems Concepts Production or manufacturing 1.9 The objective of this subsystem is to optimally deploy man, machine and material to maximize production or service. The system generates production schedules and schedules of material requirements, monitors the product quality, plans for replacement or overhauling the machinery. It also helps in overhead cost control and waste control. A whole new discipline Computer Aided Design and Computer Aided Manufacturing (CAD / CAM) has evolved due to application of IT and using this technology quick change in design and manufacturing process is possible to examine the possibilities of various alternatives. Inventory / Stores management In a manufacturing set-up, generally a major part of the manufacturing cost is involved in raw materials used in production. Though the production manager desires to have a supply of materials for production without any delay at ay time, it is not wise to maintain a huge stock of material in the stores as it will involve a lot additional costs. So the manufacturing organizations aims to maintain an optimal level stock of raw materials, component tools and equipment in such a way so that production is not hampered at any cost and the inventory cost is minimum at the same time. The inventory management system is designed with a view to keeping track of materials in the stores. The system is used to regulate the maximum and minimum level of stocks, raise alarm at danger level stock of any material, give timely alert for re-ordering of materials with optimal re-order quantity and facilitate various queries about inventory like total inventory value at any time, identification of important items in terms stock value (ABC analysis), identification most frequently moving items (XYZ analysis) etc. Similarly well-designed inventory management system for finished goods and semi-finished goods provides important information for production schedule and marketing/sales strategy. Human resource management Human resource is the most valuable asset for an organization. Utilization of this resource in most effective and efficient way is an important function for any enterprise. Less disputes, right utilization of manpower and quiet environment in this functional area will ensure smooth sailing in business. Human resource management system aims to achieve this goal. Skill database maintained in HRM system, with details of qualifications, training, experience, interests etc helps management for allocating manpower to right activity at the time of need or starting a new project. This system also keeps track of employees output or efficiency. Administrative functions like keeping track of leave records or handling other related functions are also included HRM system. An HRM system may have the following modules Personnel administration Recruitment management Travel management

1.10 Information Systems Control and Audit Benefit administration Salary administration Promotion management Thus management of human resource is just like management of other resources in an organization. Organizational effectiveness and efficiency, growth of business, sustainability in competitive environment can be seen through proper management of this resource. An ideal HR development emphasizes an optimal utilization of human resource by introducing a consistent and coherent policy aiming at promoting commitment to the enterprise. The HRM system assists to achieving this goal. 1.2.2 Open system and Closed system We have seen that a system may be composed of a number of components that work together in a cascade to achieve a goal for which the system is designed. All systems work in a specific environment and based on how they perform within an environment, systems can be categorized in two classes: Open System A system that interacts freely with its environment by taking input and returning output is termed as an open system. With change of environment an open system also changes to match itself with the environment. For example, the education system or any business process system will quickly change when the environment changes. To do this an open system will interact with elements that exist and influence form outside the boundary of the system. Information systems are open systems because they accept inputs from environment and sends outputs to environment. Also with change of environmental conditions they adapt themselves to match the changes. Closed system A system that does not interact with the environment nor changes with the change in environment is termed as a closed system. Such systems are insulated from the environment and are not affected with the changes in environment. Closed systems are rare in business area but often available in physical systems that we use in our day to work. For example, consider a throw-away type sealed digital watch, which is a system, composed of a number of components that work in a cooperative fashion designed to perform some specific task. This watch is a closed system as it is completely isolated from its environment for its operation. It works and dies out after some time. In general the life cycle of a closed system is much shorter compared to that of an open system because it decays faster for not having any input/ interaction from environment. Organisations are considered to be relatively open systems. They continuously interact with the external environment, by processes or transformation of inputs into useful output. However, organisation behave as a relatively closed system in certain respects so as to preserve their identity and autonomy. They may ignore many opportunities so as to maintain their core-competence. Organisations are open systems, because they are input-output systems. The input consists of finance, physical & mental labour and raw material.

Information Systems Concepts 1.11 No exchanges with environment Closed System Known and defined input Controlled exchange with environment insulated from outside disturbances Relatively Closed System Known and defined output Known Known Unknown Disturbance Subject to known and unknown inputs and environmental disturbances Open system Output Figure 5 Organisations perform several operations on these inputs and process out products or services. The process of exchange generates some surplus, in the form of profit, goodwill experience and so on, which can be retained in the organisation and can be used for further input output process. Organisations are dependent upon their external environment for the inputs required by them and for disposing of their outputs in a mutually beneficial manner. 1.2.3 Deterministic and Probabilistic system: A deterministic system operates in a predictable manner. The interaction among the parts is known with certainty. If one has a description of the state of the system at a given point in time plus a description of its operation, the next state of the system may be given exactly, without error. An example is a correct computer program, which performs exactly according to a set of instructions. The probabilistic system can be described in terms of probable behaviour, but a certain degree of error is always attached to the prediction of what the system will do. An inventory system is an example of a probabilistic system. The average demand, average time for replenishment, etc, may be defined, but the exact value at any given time is not known. Another example is a set of instructions given to a human who, for a variety of reasons, may not follow the instructions exactly as given. 1.3 INFORMATION Information is data that have been put into a meaningful and useful context. It has been defined by Davis and Olson as-information is data that has been processed into a form that is meaningful to the recipient and is of real or perceived value in current or progressive decision. For example, data regarding sales by various salesmen can be merged to provide

1.12 Information Systems Control and Audit information regarding total sales through sales personnel. This information is of vital importance to a marketing manager who is trying to plan for future sales. The term data and information are often used interchangeably. However, the relation of data to information is that of raw material to finished product. A data processing system processes data to generate information. Information is the substance on which business decisions are based. Therefore, the quality of information determines the quality of action or decision. The management plays the part of converting the information into action through the familiar process of decision-making. Information has come to occupy a very important position in the survival of a business. Information is a basic resource in the modern society. We are living in an information society whose economy is heavily dependent on the information resources. Organisations spend most of their time generating, processing, creating, using, and distributing information. Information and information systems are valuable organisational resources that must be properly managed for the organisation to succeed. Information is the substance on which business decisions are based. Therefore, the quality of raw materials is crucial. Raw material i.e. data determined quality of output i.e. information. This phenomenon is also known as garbage in garbage out (GIGO). The management plays the part of converting the information into action through the familiar process of decision making. Information has come to occupy a very important position in the survival of business. Indeed, information flows are as important to the survival of a business as the flow of blood is to the life and survival of an individual. Information flows is important for good business decisions and it has been often said that a receipt of a good business is 90% information and 10% inspiration. Some persons define it as a catalyst of management and the ingredients that coalesces the managerial functions of planning, and control. 1.3.1 Attributes of Information : The important attributes of useful and effective information are as follows : 1. Availability: This is a very important property of information. If information is not available at the time of need, it is useless. Data is organized in the form of facts and figures in databases and files from where various information is derived for useful purpose. . 2. Purpose: Information must have purposes at the time it is transmitted to a person or machine, otherwise it is simple data. Information communicated to people has a variety of purposes because of the variety of activities performed by them in business organisations. The basic purpose of information is to inform, evaluate, persuade, and organise. It helps in creating new concepts, identifying problems, solving problems, decision making, planning, initiating, and controlling. These are just some of the purposes to which information is directed to human activity in business organisations.

Information Systems Concepts 3. 1.13 Mode and format: The modes of communicating information to humans are sensory (through sight, hear, taste, touch and smell) but in business they are either visual, verbal or in written form. Format of information should be so designed that it assists in decision making, solving problems, initiating planning, controlling and searching. Therefore, all the statistical rules of compiling statistical tables and presenting information by means of diagram, graphs, curves, etc., should be considered and appropriate one followed. The reports should preferably be supplied on an exception basis to save the manager from an overload of information. Also, the data should only be classified into those categories, which have relevance to the problem at hand. Sales analysis can be conducted by several categories. But the reports should be provided only on those that appear to be significant to decision making. Occasionally, the reports may be required in entirely, for example, for the auditors. Even in this case, the exceptional deviation or variance should be indicated by say, asterisks. It is also desirable to give the analysis of variances to assist the manager in initiating corrective action. Likewise, for such information as Return on Investment (ROI), the summary figures in the entire ROI hierarchy should also be given. This would assist the manager to trace the causes for a rise or fall in ROI. Format of information dissemination is a matter of imagination and perception. It should be simple and relevant, should highlight important points but should not be too cluttered up. Every space in the information format should have current relevance. Often unnecessary waste of space is noticed in the information not required. This should be avoided. 4. Decay: Value of information usually decays with time and usage and so it should be refreshed from time to time. From example, we access the running score sheet of a cricket match through Internet sites and this score sheet is continually refreshed at a fixed interval or based on status of the state. Similarly, in highly fluctuating share market a broker is always interested about the latest information of a particular stock/s. Rate: The rate of transmission/reception of information may be represented by the time required to understand a particular situation. Quantitatively, the rate for humans may be measure by the number of numeric characters transmitted per minute, such as sales reports from a district office. For machines the rate may be based on the number of bits of information per character (sign) per unit of time. Frequency: The frequency with which information is transmitted or received affects its value. Financial reports prepared weekly may show so little changes that they have small value, whereas monthly reports may indicate changes big enough to show problems or trends. Frequency has some relationship with the level of management also it should be related to an operational need. For example, at the level of foreman it should be on a daily or weekly basis but, at the management control level, it is usually on monthly basis. 5. 6. 7. Completeness: The information should be as complete as possible. The classical ROI or Net Present Value (NPV) models just provide a point estimate and do not give any indication of the range within which these estimates may vary. Hartz's model for

1.14 Information Systems Control and Audit investment decisions provides information on mean, standard deviation and the shape of the distribution of ROI and NPV. With this complete information, the manager is in a much better position to decide whether or not to undertake the venture. 8. Reliability: It is just not authenticity or correctness of information; rather technically it is a measure of failure or success of using information for decision-making. If an information leads to correct decision on many occasions, we say the information is reliable. Cost benefit analysis: The benefits that are derived from the information must justify the cost incurred in procuring information. The cost factor is not difficult to establish. Using costing techniques, we shall have to find out the total as well as the marginal cost of each managerial statement but benefits are hard to quantify, i.e., they are usually intangibles. In fact, the assessment of such benefits is very subjective and its conversion into objective units of measurement is almost impossible. However, to resolve this problem, we can classify all the managerial statements into many categories with reference to the degree of importance attached, say, (a) absolutely essential statements, (b) necessary statement, (c) normal statements, (d) extra statements. The statements falling in the first category cannot be discontinued whatever be the cost of preparing them. The second category statements may have a high cost but may be discontinued only in a very stringent circumstances. The normal statements may include those, which can be discontinued or replaced if their costs are too high. In the last category we may list those statements which may be prepared only if the benefits arising out of them are substantially higher than the costs involved. 9. 10. Validity: It measures the closeness of the information to the purpose which it purports to serve. For example, some productivity measure may not measure, for the given situation, what they are supposed to do e.g., the real rise or fall in productivity. The measure suiting the organisation may have to be carefully selected or evolved. 11. Quality: A study conducted by Adams a management expert, about management attitude towards information system, reveals that 75% of managers treated quantity investments as nearly identical in terms of job performance; yet given a choice, 90% of them preferred an improvement in quality of information over an increase in quantity. Quality refers to the correctness of information. Information is likely to be spoiled by personal bias. For example, an overoptimistic salesman may give rather too high estimates of the sales. This problem, however, can be circumvented by maintaining records of salesman's estimates and actual sales and deflating or inflating the estimates in the light of this. Errors may be the result of: 1. 2. 3. Incorrect data measurement and calculation methods. Failure to follows processing procedure, and, Loss or non-processing of data, etc., To get rid of the errors, internal controls should be developed and procedure for measurements prescribed.

Information Systems Concepts 1.15 Information should, of course, be accurate otherwise it will not be useful; but accuracy should not be made a fetish, for example, the sales forecast for groups of products can well be rounded off to thousands of rupees. 12. Transparency: If information does not reveal directly what we want to know for decisionmaking, it is not transparent. For example, total amount of advance does not give true picture of utilization of fund for decision about future course of action; rather depositadvance ratio is perhaps more transparent information in this matter. 13. Value of information: It is defined as difference between the value of the change in decision behaviour caused by the information and the cost of the information. In other words, given a set of possible decisions, a decision-maker may select one on basis of the information at hand. If new information causes a different decision to be made, the value of the new information is the difference in value between the outcome of the old decision and that of the new decision, less the cost of obtaining the information. 1.4 INFORMATION SYSTEM AND ITS ROLE IN MANAGEMENT An information system can be considered as an arrangement of a number of elements that provides effective information for decision-making and / or control of some functionalities of an organization. Information is an entity that reduces uncertainty about an event or situation. For example, correct information about demand of products in the market will reduce the uncertainty of production schedule. Enterprises use information system to reduce costs, control wastes or generate revenue. Hence onwards we will focus our discussions only to computer-based information system. In modern business perspective the information system has far reaching effects for smooth and efficient operations. Some of important implications of information system in business are as follows: (1) Information system will help managers in effective decision-making to achieve the organizational goal. (2) Based on well-designed information system, an organization will gain edge in the competitive environment. (3) Information systems helps take right decision at the right time. (4) Innovative ideas for solving critical problems may come out from good information system. (5) Knowledge gathered though information system may be utilized by managers in unusual situations. (6) If information system is viewed as a process it can be integrated to formulate a strategy of action or operation.

1.16 Information Systems Control and Audit 1.4.1 Factors on which Information requirements Depend The factors on which information requirements of executives depend are: 1. Operational function. 2. 3. Type of decision making. Level of management activity. (1) Operational function: The grouping or clustering of several functional units on the basis of related activities into a sub-systems is termed as operational function. For example, in a business enterprise, marketing is an operational function, as it is the clustering of several functional units like market research, advertising, sales analysis and so on. Likewise, production finance, personnel etc. can all be considered as operational functions. Operational functions differ in respect of content and characteristics of information required by them. Information requirement depends upon operational function. The information requirement of different operational functions vary not only in content but also in characteristics. In fact, the content of information depends upon the activities performed under an operational function. For example, in the case of production, the information required may be about the production targets to be achieved, resources available and so on. Whereas in the case of marketing functions, the content of information may be about the consumer behaviour, new product impact in the market etc. The characteristics which must be possessed by a particular information too are influenced by an operational function. For example, the information required by accounts department for preparing payroll of the employees should be highly accurate. (2) Type of decision making: Organisational decisions can be categorised as programmed and non-programmed ones. *Programmed decisions : Programmed decisions or structured decisions refer to decisions made on problems and situations by reference to a predetermined set of precedents, procedures, techniques and rules. These are well-structured in advance and are time-tested for their validity. As a problem or issue for decision-making emerges, the relevant pre-decided rule or procedure is applied to arrive at the decision. For example, in many organisations, there is a set procedure for receipt of materials, payment of bills, employment of clerical personnel, release of budgeted funds, and so on. Programmed decisions are made with respect to familiar, routine, recurring problems which are amenable for structured solution by application of known and well-defined operating procedures and processes. Not much judgement and discretion is needed in finding solutions to such problems. It is a matter of identifying the problem and applying the rule. Decision making is thus simplified. Organisations evolve a repertory of procedures, rules, processes and techniques for handling routine and recurring situations and problems, on which managers have previous experience and familiarity. One characteristic of programmed decisions is that they tend to be consistent over situations and time. Also managers do not have to lose much sleep in brooding over

Information Systems Concepts 1.17 them. However, programmed decisions do not always mean solutions to simple problems. Decisionmaking could be programmed even to complex problems-such as resource allocation problems for example-by means of sophisticated mathematical/statistical techniques. *Non-programmed decisions or unstructured decisions are those which are made on situations and problems which are novel and non-repetitive and about which not much knowledge and information are available. They are nonprogrammed in the sense that they are made not by reference to any pre-determined guidelines, standard operating procedures, precedents and rules but by application of managerial intelligence, experience, judgement and vision to tackling problems and situations, which arise infrequently and about which not much is known. There is no simple or single best way of making decisions on unstructured problems, which change their character from time to time, which are surrounded by uncertainty and enigma and which defy quick understanding. Solutions and decisions on them tend to be unique or unusual-for example, problems such as a sudden major change in government policy badly affecting a particular industry, the departure of a top level key executive, drastic decline in demand for a particular high profile product, competitive rivalry from a previously little known manufacturer etc. do not have ready-made solutions. It is true that several decisions are neither completely programmed or completely nonprogrammed but share the features of both. (3) Level of management activity : Different levels of management activities in management planning and control hierarchy areStrategic level, tactical level and operational level. *Strategic Level or Top level : Strategic level management is concerned with developing of organisational mission, objectives and strategies. Decisions made at this level of organisation to handle problems critical to the survival and success of the organisation are called strategic decisions. They have a vital impact on the direction and functioning of the organisation-as for example decisions on plant location, introduction of new products, making major new fundraising and investment operations, adoption of new technology, acquisition of outside enterprises and so on. Much analysis and judgement go into making strategic decisions. In a way, strategic decisions are comparable to non-programmed decisions and they share some of their characteristics. Strategic decisions are made under conditions of partial knowledge or ignorance. *Tactical Level or middle level: Tactical level lies in middle of managerial hierarchy. At this level, managers plan, organise, lead and control the activities of other managers. Decisions made at this level called the tactical decisions (which are also called operational decisions) are made to implement strategic decisions. A single strategic decision calls for a series of tactical decisions, which are of a relatively structured nature. Tactical decisions are relatively short, step-like spot solutions to breakdown strategic decisions into implementable packages. The other features of tactical decisions are: they are more specific and functional; they are made in a relatively closed setting; information for tactical decisions is more easily available and digestible; they are less surrounded by uncertainty and complexity; decision variables can be forecast and quantified without much difficulty and their impact is relatively localised and short-range. Tactical decisions are made with a strategic focus.

1.18 Information Systems Control and Audit The distinction between strategic and operational decisions could be high-lighted by means of an example. Decisions on mobilisation of military resources and efforts and on overall deployment of troops to win a war are strategic decisions. Decisions on winning a battle are tactical decisions. As in the case of programmed and non-programmed decisions, the dividing line between strategic and tactical decision is thin. For example, product pricing is tactical decision in relation to the strategic decision of design and introduction of a new product in the market. But product pricing appears to be a strategic decision to down-line tactical decisions on dealer discounts. *Supervisory or operational Level: This is the lowest level in managerial hierarchy. The managers at this level coordinate the work of others who are not themselves managers. They ensure that specific tasks are carried out effectively and efficiently. 1.4.2 Information systems at different levels of management It is a fact that much of management is primarily concerned with decision- making and so the importance of information system is further emphasized in this matter. Management at different levels take decisions matching to their position or hierarchy in the organization and different types of information systems are designed and developed for them i.e. an information system for a departmental manager will be characteristically different from one designed for a corporate manager. If we consider an organization having a pyramidal management structure with the corporate level managers at the top and operational managers at the bottom we will observe that typical categories of data are manipulated at different levels. EIS Top management Middle management level management MIS, DSS TPS Figure 6 This Figure 6 exhibits data available at different functional areas of an organization for management. At the lowest level that is managed by operational level managers (like

Information Systems Concepts 1.19 supervisor, section in-charge), all types of inputs available from various sources are collected. The routine office work, like maintaining inward register and public interaction are mostly done at this level. However, no decision-making process is carried out at this level. But proper organization of data for further processing is an important task to be completed at this level. So sufficiently trained manpower will be deployed at this stage. At the middle level of management the decision makingprocess starts. Inputs from different internal and external information sources are collected (normally passed from operational level managers) and processed for strategic decisions. Middle level managers who are expected to contribute significantly towards development of the organization will be the key personnel to carry out the processing activities of the strategic data. They will use various tools of analysis and typical software products to report to the higher level with options and possible effects. This job is very critical and important as well because tactical decisions by the top management are dependent on the information passed from middle management. 1.4.3 Types of Information Information, broadly, can be divided into two different types internal information and external information in the context of business organizations. *Internal information: The internal information can be defined as information that has been generated from the operations of the organization at various functional areas. The internal information gets processed and summarized from junior to top most level of management. The internal information always pertains to the various operational units of the organization. Examples of internal information would be production figures, sales figures, information about personnel, accounts, material etc. Middle and junior level managers usually consume this type of information. However, condensed or summarized information are important for top-level management. *External information: The external information is collected from the external environment of the business organization. External information is considered to affect the organizational performance from outside the organization. Planning information related to external environment Top Middle Junior Figure 7 Information such as Govt. policies, competition, economic status etc. considered to be external information. Access to internal and external information by different levels of Controlling information related to internal environment Internal information External information

1.20 Information Systems Control and Audit management is shown in Fig: 7. Obviously mainly top management uses the external information and since this information is not structured vision, personal experience and wisdom are important factors to take the right decision. 1.5 TYPES OF INFORMATION SYSTEMS AT DIFFERENT LEVELS We have discussed about the different types of data that are concerned with activities at various levels of management. Now we will focus towards the information systems used at different levels. Top level management Tactical data Middle level management Supervisory level management Strategic data Operational data Figure 8 In an organization managers at different levels take decisions that are characteristically different in nature. Managers at lower level of organization will take decisions in matters that are concerned within their limited area of functions while the corporate managers will be responsible for decisions related to functions covering the entire organization. So their nature of decision-making process also varies widely. Fig: 8 shows the different decision-making systems that exist at different levels of organization. Each of the above categories of systems will be discussed, in detail, in the subsequent sections. 1.5.1 Transaction Processing System (TPS) TPS at the lowest level of management is an information system that manipulates data from business transactions. Any business activity such as sales, purchase, production, delivery, payments or receipts involves transaction and these transactions are to be organized and manipulated to generate various information products for external use. For example, selling of a product to a customer will give rise to the need of further information like customer billing, inventory status and increase in account receivable balance. Transaction processing system will thus record and manipulate transaction data into usable information. Typically, a TPS involves the following activities: (i) (ii) Capturing data to organize in files or databases. Processing of files / databases using application software.

Information Systems Concepts (iii) Generating information in the form of reports. (iv) Processing of queries from various quarters of the organization. 1.21 A transaction processing system may follow periodic data preparation and batch processing (as in payroll application) or on-line processing (as in inventory control application). Both approaches have their merits and demerits. However in industries and business houses nowa-days on-line approach is preferred in many applications as it provides information with up-todate status. It is to be noted that the people who participate in Transaction processing system usually are not in a position to take any management decision. 1.5.2 Management information systems: Transaction processing systems are operations oriented. In contrast, Management Information Systems (MIS) assist managers in decision making and problem solving. They use results produced by the Transaction processing systems, but they may also use other information. In any organisation, decisions must be made on many issues that recur regularly and require a certain amount of information. Because the decision making process is well understood, the manager can identify the information that will be needed for the purpose. In turn, the information systems can be developed so that reports are prepared regularly to support these recurring decisions. 1.5.2.1 Definition of Management Information System (MIS): Many experts have defined MIS in different languages. But the central theme of all these definitions is same. A Management Information System has been defined by Davis and Olson as an integrated user-machine system designed for providing information to support operational control, management control and decision making functions in an organization. The information system makes use of resources such as hardware, software, personnel, procedure and supplies as well. MIS is designed to provide accurate, relevant and timely information to managers at different levels and in different functional areas throughout the organization for decision-making purpose. MIS support the managers at different levels to take strategic (at top level) or tactical (at middle level) management decisions to fulfill the organizational goals. Nature of MIS at different levels has different flavours and they are available in the form of reports, tables, graphs and charts or in presentation format using some tools. MIS at the top level is much more comprehensive and condensed or summarized compared to that existing in the middle level management. Before we go for further discussions let us understand Management Information System in terms of its constituent components. Management Information Systems Management Information System Management: A manager may be required to perform following activities in an organisation: (i) Determination of organisational objectives and developing plans to achieve them.

1.22 (ii) Information Systems Control and Audit Securing and organising the human and physical resources so that these objectives could be accomplished. (iii) Exercising adequate controls over the functions. (iv) Monitoring the results to ensure that accomplishments are proceeding according to plan. Thus, management comprises the processes or activities that describe what managers do in the operation of their organisation: plan, organise, initiate, and control operations. In other words, management refers to a set of functions and processes designed to initiate and coordinate group efforts in an organised setting directed towards promotion of certain interest, preserving certain values and pursuing certain goals. It involves mobilisation, combination, allocation and utilisation of physical, human and other needed resources in a judicious manner by employing appropriate skills, approaches and techniques. Information (as referred to MIS): Information could be defined as sets of facts, figures and symbols processed for the current decisionmaking situation. The information is considered to be of significance in a particular situation. System: We have already defined a system as a set of related components, activities, process and human beings interacting together so as to accomplish some common objective. Putting all these three components together, it could be seen that MIS are sets of related processes, activities individuals or entities interacting together to provide processed data to managers at various levels and functional areas. The function of MIS can be shown with the help of following diagram: Determination of Information needs Data Gathering and Processing Evaluation, Indexing, Abstraction Dissemination Storage Information Use Figure 9 MIS provided for the identification of relevant information needs, the collection of relevant information, processing of the same to become usable by the business managers, and timely dissemination of processed information to the users of the information for properly managing the affairs of an enterprise by informed decisions. For example, in a competitive market for products manufactured by an enterprise, its management needs information on the pricing policy of the competitors, specially of competing products, sales techniques etc., to effectively combat the effect of the competition.

Information Systems Concepts 1.23 1.5.2.2 Characteristics of an effective MIS : Important characteristic for an effective MIS are eight in number and are briefly discussed below : 1. Management oriented: It means that effort for the development of the information system should start from an appraisal of management needs and overall business objectives. Such a system is not necessarily for top management only, it may also meet the information requirements of middle level or operating levels of management as well. Management directed: Because of management orientation of MIS, it is necessary that management should actively direct the systems development efforts. Mere one time involvement is not enough. For systems effectiveness, it is necessary for management to devote their sufficient time not only at the stage of designing the system but for its review as well, to ensure that the implemented system meets the specifications of the designed system. In brief, management should be responsible for setting system specifications and it must play a key role in the subsequent trade off decisions that occur in system development. (system development process has been discussed, in detail, in Chapter 2). Integrated: Development of information should be an integrated one. It means that all the functional and operational information sub-system should be tied together into one entity. An integrated information system has the capability of generating more meaningful information to management. The word integration here means taking a comprehensive view or a complete look at the inter locking subsystems that operate within a company. Common data flows: It means the use of common input, processing and output procedures and media whenever possible is desirable. Data is captured by system analysts only once and as close to its original source as possible. They, then, try to utilise a minimum of data processing procedures and sub-systems to process the data and strive to minimise the number of output documents and reports produced by the system. This eliminates duplication in data collections and documents and procedures. It avoids duplication, also simplifies operations and produces an efficient information system. However, some duplication is necessary in order to insure effective information system. Heavy planning element : An MIS usually takes 3 to 5 years and sometimes even longer period to get established firmly within a company. Therefore, a heavy planning element must be present in MIS development. It means that MIS designer should keep in view future objectives and requirements of firm's information in mind. The designer must avoid the possibility of system obsolescence before the system gets into operation. Sub system concept: Even though the information system is viewed as a single entity, it must be broken down into digestible sub-systems which can be implemented one at a time by developing a phasing plan. The breaking down of MIS into meaningful subsystems sets the stage for this phasing plan. Common database: Database is the mortar that holds the functional systems together. It is defined as a "superfile" which consolidates and integrates data records formerly stored in many separate data files. The organisation of a database allows it to be accessed by several information sub-systems and thus, eliminates the necessity of duplication in data 2. 3. 4. 5. 6. 7.

1.24 Information Systems Control and Audit storage, updating, deletion and protection. Although it is possible to achieve the basic objectives of MIS without a common database, thus paying the price of duplicate storage and duplicate file updating, database is a definite characteristic of MIS. 8. Computerised: It is possible to have MIS without using a computer. But use of computers increases the effectiveness of the system. In fact, its use equips the system to handle a wide variety of applications by providing their information requirements quickly. Other necessary attributes of the computer to MIS are accuracy and consistency in processing data and reduction in clerical staff. These attributes make computer a prime requirement in management information system. 1.5.2.3 Misconceptions or Myths about MIS: Let us clarify some of the misconceptions of myths about MIS. 1. The study of management information system is about the use of computers. This statement is not true. MIS may or may not be computer based, computer is just a tool, just take any other machine. Installing a MIS depends largely on several factors such as, how critical is the response time required for getting an information; how big is the organisation, and how complex are the needs of the information processing. More data in reports means more information for managers : This is a misapprehension. It is not the quantity of data, but its relevance, which is important to managers in process of decision-making. Data provided in reports should meet information requirements of managers. It is the form of data and its manner of presentation that is of importance to business managers. Unorganised mass of data creates confusion. 2. 3. Accuracy in reporting is of vital importance : The popular belief is that accuracy in reporting should be of high order. At the operating level, it is true. Other examples, where accuracy is really important, can be the dispensing of medicine; the control of aircraft; the design of a bridge etc. Accuracy, however, is a relevant but not an absolute ideal. Higher levels of accuracy involve higher cost. At higher decision levels, great accuracy may not be required. The degree of accuracy is closely related to the decision problem. Higher management is concerned with broad decisions on principles and objectives. A fairly correct presentation of relevant data often is adequate for top management decisions. For a decision on a new project proposal, top management is not interested in knowing the project cost in precise rupee terms. A project cost estimated at a fairly correct figure is all what it wants. 1.5.2.4 Prerequisites of an effective MIS: The main pre-requisites of an effective MIS are as follows: (a) Database : It can be defined as a superfile which consolidates data records formerly stored in many data files. The data in database in organised in such a way that accesses to the data is improved and redundancy is reduced. Normally, the database is subdivided into the major information sub-sets needed to run a business. These sub-sets are (a) Customer and Sale File; (b) Vendor file; (c) Personnel file; (d) Inventory file; and (e)

Information Systems Concepts 1.25 General Ledger Accounting file. The main characteristic of database is that each subsystem utilises same data and information kept in the same file to satisfy its information needs. The other important characteristics of data base are as follows : (i) (ii) It is useroriented. It is capable of being used as a common data source, to various users, helps in avoiding duplication of efforts in storage and retrieval of data and information. (iii) It is available to authorised persons only. (iv) It is controlled by a separate authority established for the purpose, known as Data Base Management System (DBMS). The maintenance of data in database requires computer hardware, software and experienced computer professionals. In addition it requires a good data collection system equipped with experts who have first-hand knowledge of the operations of the company and its information needs. The database structured on above lines is capable of meeting information requirements of its executives, which is necessary for planning organising and controlling the operations of the business concern. But, it has been observed that such a database meets the information needs of control to its optimum. (b) Qualified system and management staff : The second pre-requisite of effective MIS is that it should be manned by qualified officers. These officers who are expert in the field should understand clearly the views of their fellow officers. For this, the organisational management base should comprise of two categories of officers viz. (1) Systems and Computer experts and (2) Management experts. Systems and Computer experts in addition to their expertise in their subject area should also be capable of understanding management concepts to facilitate the understanding of problems faced by the concern. They should also be clear about the process of decision making and information requirements for planning and control functions. Management experts should also understand quite clearly the concepts and operations of a computer. This basic knowledge of computers will be useful to place them in a comfortable position, while working with systems technicians in designing or otherwise of the information system. This prerequisite is confronted with a problem viz., procurement of suitable experts. The problem is dealt by recruiting fresh candidates and developing them to meet specific requirements. Also, its is difficult to retain such experts on long term basis as their scope in the job market is quite high.

1.26 Information Systems Control and Audit (c) Support of Top Management : The management information system to be effective, should receive the full support of top management. The reasons for this are as follows: 1. 2. Subordinate managers are usually lethargic about activities, which do not receive the support of their superiors (top management). The resources involved in computer-based information systems are large and are growing larger in view of importance gained by management information system. To gain the support of top management, the officers should place before top management all the supporting facts and state clearly the benefits, which will accrue from it to the concern. This step will certainly enlighten management, and will change their attitude towards MIS. Their wholehearted support and cooperation will help in making MIS an effective one. (d) Control and maintenance of MIS: Control of the MIS means the operation of the system as it was designed to operate. Some time, users develop their own procedures or short cut methods to use the system, which reduce its effectiveness. To check such habits of users, the management at each level in the organisation should devise checks for the information system control. Maintenance is closely related to control. There are times when the need for improvements to the system will be discovered. Formal methods for changing and documenting changes must be provided. (e) Evaluation of MIS: An effective MIS should be capable of meeting the information requirements of its executives in future as well. This capability can be maintained by evaluating the MIS and taking appropriate timely action. The evaluation of MIS should take into account the following points. 1. 2. 3. Examining whether enough flexibility exists in the system, to cope with any expected or unexpected information requirement in future. Ascertaining the views of users and the designers about the capabilities and deficiencies of the system. Guiding the appropriate authority about the steps to be taken to maintain effectiveness of MIS. 1.5.2.5 Constraints in operating a MIS: Major constraints which come in the way of operating an information system are the following : 1. Non-availability of experts, who can diagnose the objectives of the organisation and provide a desired direction for installing and operating system. This problem may be overcome by grooming internal staff. The grooming of staff should be preceded by proper selection and training. Experts usually face the problem of selecting the sub-system of MIS to be installed and operated upon. The criteria, which should guide the experts here, may be the need and importance of a function for which MIS can be installed first. 2.

Information Systems Concepts 3. 1.27 Due to varied objectives of business concerns, the approach adopted by experts for designing and implementing MIS is a non-standardised one. Though in this regard nothing can be done at the initial stage but by and by standardisation may be arrived at, for the organisation in the same industry. Nonavailability of cooperation from staff in fact is a crucial problem. It should be handled tactfully. Educating the staff may solve this problem. This task should be carried out by organising lecturers, showing films and also explaining to them the utility of the system. Besides this, some persons should also be involved in the development and implementation of the system. There is high turnover of experts in MIS. Turnover in fact arises due to several factors like pay packet; promotion chances; future prospects, behaviour of top ranking managers etc. Turnover of experts can be reduced by creating better working conditions and paying at least at par with other similar concerns. Difficulty in quantifying the benefits of MIS, so that it can be easily comparable with cost. This raises questions by departmental managers about the utility of MIS. They forget that MIS is a tool, which is essential to fight out competition and the state of uncertainty that surrounds business today. 4. 5. 1.5.2.6 Effects of using Computer for MIS: The effect of applying computer technology to information system can be listed as below : 1. Speed of processing and retrieval of data increases : Modern business situations are characterised by high degree of complexity, keen competition and high risk and reward factors. This invariably calls for systems capable for providing relevant information with minimum loss of time. Manual systems, howsoever well organised, often fail to match the demand for information for decision making. Computer with its unbelievably fast computational capability and systematic storage of information with random access facility has emerged as an answer to the problems faced in modern days management. Processing of data in relevant form and design and retrieval of them when needed in facts requires considerably less time and facilitate the management action and decision making. The speed of computer processing is in new range, i.e., an operation takes only billionths of a second. This characteristic of computer has accounted for as a major factor in inducing MIS development. Computers today are capable of meeting varied type of information requirements of executives. Scope of use of information system has expanded : The importance and utility of information system in business organisations was realised by most of the concerns, specially after the induction of computers for MIS development. Systems experts in business organisations developed areas and functions, where computerised MIS could be used to improve the working of the concern. This type of applications hitherto are not feasible under the manual system. For example, it was made possible by using an on line real time system to provide information to various users sitting at a remote distance from a centrally located computer system. 2.

1.28 3. Information Systems Control and Audit Scope of analysis widened : The use of computer can provide multiple type of information accurately and in no time to decision makers. Such information equips an executive to carry out a thorough analysis of the problems and to arrive at the final decision. Computer is capable of providing various types of sales reports for example; area wise sales commission of each salesman, product-wise sales, etc. These reports are quite useful in analysing the sales department working and to ascertain their weaknesses so that adequate measures may be taken in time. In this way, the use of computer has widened the scope of analysis. Complexity of system design and operation increased : The need for highly processed and sophisticated information based on multitudes of variables has made the designing of the system quite complex. During the initial years, after the induction of computer for MIS development, systems experts faced problems in designing systems and their operations. The reason at that time was the non-availability of experts required for the purpose. But these days the situation is better. The computer manufactures have developed some important programs (software) to help their users. Besides some private agencies are also there who can perform the task of developing programs to cater to the speciliased needs of their customers, either on consultancy basis or on contract. Integrates the working of different information sub-system : A suitable structure of management information system may be a federation of information subsystem, viz., production, material, marketing, finance, engineering and personnel. Each of these subsystems are required to provide information to support operational control, management control and strategic planning. Such information may be made available from a commondata-base. This common data base may meet out the information requirements of different information sub-system by utilising the services of computers for storing, processing, analysing and providing such information as and when required. In this way, computer technology is useful for integrating the day-to-day working of different information sub system. 4. 5. 6. Increases the effectiveness of Information system : Information received in time is of immense value and importance to a concern. Prior to the use of computer technology for information purposes, it was difficult to provide the relevant information to business executives in time even after incurring huge expenses. The use of computer technology has overcome this problem. Now, it is not difficult to provide timely, accurate and desired information for the purpose of decision making. Hence, we can conclude that the use of computer has increased the effectiveness of information system also. 7. More comprehensive information : The use of computer for MIS enabled systems expert to provide more comprehensive information to executives on business matters. 1.5.2.7 Limitations of MIS : The main limitations of MIS are as follows : 1. The quality of the outputs of MIS is basically governed by the quantity of input and processes.

Information Systems Concepts 1.29 2. MIS is not a substitute for effective management. It means that it cannot replace managerial judgement in making decisions in different functional areas. It is merely an important tool in the hands of executives for decision making and problem solving. 3. MIS may not have requisite flexibility to quickly update itself with the changing needs of time, especially in fast changing and complex environment. 4. MIS cannot provide tailor-made information packages suitable for the purpose of every type of decision made by executives. 5. MIS takes into account mainly quantitative factors, thus it ignores the non-quantitative factors like morale and attitude of members of the organisation, which have an important bearing on the decision making process of executives. 6. MIS is less useful for making non-programmed decisions. Such type of decisions are not of the routine type and thus require information, which may not be available from existing MIS to executives. 7. The effectiveness of MIS is reduced in organisations, where the culture of hoarding information and not sharing with other holds. 8. MIS effectiveness decreases due to frequent changes in top management, organisational structure and operational team. 1.5.3 Decision Support Systems (DSS). During the 1970s, systems designed to help decision-makers devised solutions to unstructured and partially structured problems. These systems largely consist of tools that can be customized in a variety of ways to solve computationally or clerically intensive problems. Such systems are particularly useful to higher-level managers whose requirements for information are somewhat unpredictable. They are called decision support systems (DSS). 1.5.3.1 What is a DSS? The term management information system was first coined to distinguish the systems that merely process transaction data from systems whose primary purpose is to provide information. The first information-oriented MIS possessed the characteristics of the management reporting systems (MRS); that is, they provided fixed, preformatted information in a standardized way. Typical outputs of this type were computer-produced, hardcopy summary and exception reports that a companys MIS department might circulate periodically to various middle managers. As developments in interactive display technology, micro-computing, and easy-to-use software systems changed the way in which managers were provided with information and led to a growing understanding of how technology could support difficult decisions a new term was coined to distinguish this new system from a report-based MRS. This new term decision support system resulted from the fact that these systems were more flexible and adaptable to changing decisionmaking requirements than traditional management reporting system.

1.30 Information Systems Control and Audit A decision support system (DSS) can be defined as a system that provides tools to managers to assist them in solving semistructured and unstructured problems in their own, somewhat personalized, way. Often, some type of modeling environment perhaps a very simple environment such as the one accompanying a spreadsheet package is involved. A DSS is not intended to make decisions for managers, but rather to provide managers with a set of capabilities that enables them to generate the information required by them in making decisions. In other words, a DSS supports the human decisionmaking process, rather than providing a means to replace it. Systems that replace human decision making rather than support it are sometimes called programmed decision systems. These systems are used to make routine, structured decisions, such as approving loans or credit, reordering inventory, triggering reminder notices, and selecting audit samples. In programmed decision systems, the focus is on doing something more efficiently. On the other hand; in decision support systems, the focus is on helping decision makers become more effective. Technically, a DSS does not need to involve high technology. For example, to a writer, a selected group of journal and text resources at a local library and a strategy for using those resources may serve as part of a decision support system. To a novice accountant in a large accounting firm, the advice offered by a senior tax partner might be part of that novices decision support system. 1.5.3.2 DSS GOALS AND APPLICATIONS The decision support systems are characterised by at least three properties: (1) They support semistructured or unstructured decision-making. (2) They are flexible enough to respond to the changing needs of decision makers, and (3) They are easy to use. We will now briefly discuss each of the above mentioned characteristics. (i) Semistructured and Unstructured Decisions : Structured decisions are those that are easily made from a given set of inputs. These types of decisions such as deciding to issue a reminder notice if a bill is overdue or deciding to sell a stock under a given set of market conditions can be programmed fairly easily. Unstructured decisions and semistructured decisions, however, are decisions for which information obtained from a computer system is only a portion of the total knowledge needed to make the decision. The DSS is particularly well adapted to help with semistructured and unstructured decisions. However, it can be designed to support structured decision making as well. A manager, for instance, can browse through data at will (perhaps at a display terminal). When enough information is gathered from this process to supplement other information (perhaps some of it may be non computer-based), a decision can be reached. In a well-designed DSS, the depth to which the available data can be tapped for useful information often depends on the time availability and patience of the manager.

Information Systems Concepts Steps in solving a problem with a DSS Define and formulate problem 1.31 Frame problem into DSS model Use model to obtain results Reformulate problem Figure 10 In Figure 10, it is shown how a semistructured problem might be solved by using a DSS. The problem is first defined and formulated. It is then modeled with DSS software. Next, the model is run on the computer to provide results. The modeler, in reviewing these results, might decide to completely reformulate the problem, refine the model, or use the model to obtain other results. For example, a user might define a problem that involves simulating cash flows under a variety of business conditions by using financial modeling software. The DSS model is then run, providing results. Depending on what the results of the model indicate about cash flow, the user might decide to completely remodel the problem, make small modifications to the current model, run the model under a number of new assumptions, or accept the results. For instance, if the model revealed inadequate cash flows to support organisational operations, model modifications should be developed and run. The modification process might continue for several interations until an acceptable cash flow is identified. (ii) Ability to adapt to changing needs : Semistructured and unstructured decisions often do not conform to a predefined set of decision-making rules. Because of this, their decision support systems must provide for enough flexibility to enable users to model their own information needs. They should also be capable of adapting to changing information needs. With a formal management reporting systems, specific outputs usually in the form of hardcopy reports or preformatted display screens are established well ahead of the time that they are actually used. Such reports are generated by an application system which has to undergo a time consuming system development process which involves a lengthy, customization of application program, supporting documentation, and a run schedule. For example a production manager might make a formal request to the MIS department for a monthly report. The utility of such a report is usually first assessed by a committee and, possibly, a schedule for development is chalked out. After the report is designed and a program is written specifically to generate it, the types of information supplied to the manager by that report are frozen. If information requirements change substantially by that time,

1.32 Information Systems Control and Audit another formal report request must be submitted to get the program rewritten. The whole process thus takes lot of time. The DSS designer understands that managers usually do not know in advance what information they need and, even if they do, those information needs keep changing constantly. Thus, rather than locking the system into rigid information producing requirements, capabilities and tools are provided by DSS to enable users to meet their own output needs. Flexibility in a DSS is of paramount importance. Information requests made to a DSS will often be relatively unsystematic and distinctive. For example, a sales manager at a display device might request the price of a specific product. A few seconds later, the manager might change his mind and ask for a listing of the vendors of several other products. The next request, a couple of minutes later, may be a ranking of the top salespeople in a particular sales region over the last two months. A report might even be requested at the end of the session, combining data from several of these inquiries. Since the demands made by the user on the DSS are not fully predetermined, the user might request information in a variety of formats. In well-designed decision support systems, managers can ask spontaneous questions, as these questions occur to them and receive almost immediate responses for these questions. The manager can make many requests without being sure at any point where the search for information will lead him. The manager often needs a variety of tools to satisfy such requests: formulas, functions, sorts, graphs, formal models, and so on. The output from a DSS may also be used to prepare customised outputs to be examined by other people; for example, a manager preparing presentation graphics for a meeting. (iii) Ease of Learning and Use : Since decision support systems are often built and operated by users rather than by computer professionals, the tools that accompany them should be relatively easy to learn and use. Such software tools employ user-oriented interfaces such as grids, graphics, nonprocedural fourth generation languages (4GL), natural English, and easily read documentation. These interfaces make it easier for users to conceptualize and perform the decision-making process. As is the case with most computer applications developed during the 1990s, graphical user interfaces (GUI) are becoming more common on decision support systems also. Since general users do not have the skills to interpret cryptic error messages, such tools often liberally employ a number of help aids, for example, useful diagnostics, a help feature, and undo commands Although interactive display devices are not considered a requirement for DSS, many decision support systems employ them. First, display devices provide users with relatively fast, often real-time, responses, thus enabling the process depicted in Figure 10 to be conducted as rapidly as the user wants. Fast electronic responses facilitate maintaining a chain of thought as the problem solving process takes place; real-time responses assure the user that up-todate data are being supplied to the decision-making process. In addition, interactive systems enable the user to base each new request on the responses of the system supplied for earlier requests. In non-interactive systems, if a decision must be made within a certain time frame and system turnaround time is slow, managers are often forced to batch together a large number of potentially useful requests. This can involve a lot of extra contingency planning.

Information Systems Concepts 1.33 The point here is that although interactive display devices are not required for a DSS, they do help to make many decision support systems friendly and useful. 1.5.3.3 COMPONENTS OF A DSS A decision support system has four basic components: (1) the user, (2) one or more databases, (3) a planning language, and (4) the model base (see Figure 11 below). The Components of a decision support system. Decision support system Corporate database Dialogue system, often using a planning language User database User with a difficult, unstructured problem DSS model base Figure 11 (i) The users : The user of a decision support system is usually a manager with an unstructured or semi-structured problem to solve. The manager may be at any level of authority in the organisation (e.g., either top management or operating management). Typically, users do not need a computer background to use a decision support system for problem solving. The most important knowledge is a thorough understanding of the problem and the factors to be considered in finding a solution. A user does not need extensive education in computer programming in part because a special planning language performs the communication function within the decision support system. Often, the planning language is nonprocedural, meaning that the user can concentrate on what should be accomplished rather than on how the computer should perform each step. (ii) Databases : Decision support systems include one or more databases. These databases contain both routine and nonroutine data from both internal and external sources. The data from external sources include data about the operating environment surrounding an organisation for example, data about economic conditions, market demand for the organisations goods or services, and industry competition.

1.34 Information Systems Control and Audit Decision support system users may construct additional databases themselves. Some of the data may come from internal sources. An orgnaisation often generates this type of data in the normal course of operations for example, data from the financial and managerial accounting systems such as account, transaction, and planning data. The database may also capture data from other subsystems such as marketing, production, and personnel. External data include assumptions about such variables as interest rates, vacancy rates, market prices, and levels of competition. (iii) Planning languages : Two types of planning languages that are commonly used in decision support systems are: (1) general purpose planning languages and (2) specialpurpose planning languages. General-purpose planning languages allow users to perform many routine tasks for example, retrieving various data from a database or performing statistical analyses. The languages in most electronic spreadsheets are good examples of general-purpose planning languages. These languages enable user to tackle a broad range of budgeting, forecasting, and other worksheet-oriented problems. Special-purpose planning languages are more limited in what they can do, but they usually do certain jobs better than the general-purpose planning languages. Some statistical languages, such as SAS, SPSS, and Minitab, are examples of special purpose planning languages. (iv) Model base : The planning language in a decision support system allows the user to maintain a dialogue with the model base. The model base is the brain of the decision support system because it performs data manipulations and computations with the data provided to it by the user and the database. There are many types of model bases, but most of them are custom-developed models that do some types of mathematical functions-for example, cross tabulation, regression analysis, time series analysis, linear programming and financial computations. The analysis provided by the routines in the model base is the key to supporting the users decision. The model base may dictate the type of data included in the database and the type of data provided by the user. Even where the quantitative analysis is simple, a system that requires users to concentrate on certain kinds of data can improve the effectiveness of decision making. 1.5.3.4 The tools of decision support systems The tools of decision support include a variety of software supporting database query, modeling, data analysis, and display. A comprehensive tool kit for DSS would include software supporting these application areas. Examples of software tools falling into these four categories are given in Table 1. Data-based Software Dbase IV FOCUS NOMAD II RAMIS R : base 5000 SQL Model Based Statistical Display-Based Software Software Software SAS ChartMaster Foresight SPSS SASGRAPH IFPS TSAM TELLAGRAF Lotus 1-2-3 Model Multiplan Omnicalc Table 1 : Software tools for decision support systems

Information Systems Concepts 1.35 Database Languages : Tools supporting database query and report generation use mainframe, minicomputer, and microcomputer-based databases. FOCUS, RAMIS, and NOMAD II, for example, are mainframe-based languages supporting database query, report generation, and simple analysis. FOCUS and RAMIS are also available in PC versions. Ingres, Oracle, and Informix are database languages on mainframes, mini-computers, and microcomputers. Managers frequently use microcomputer-based database tools such as MSAccess and R: base 5000. Using a student database and a database query tool, a college administrator could generate the output shown in Figure 12 by asking for a list of courses with tuition greater than Rs.215. This is an example of a simple query requiring a search for records with certain characteristics. Using a database query tool, the user could also generate a report with a title, page headings, column headings, subtotals, and totals. A database query DEMO) DEMO) Record# 3 7 9 12 16 18 19 21 .USE COURSE . LIST ALL FOR CTUIT > 215 CID CDESC AC370 AUDITING FIN350 PRIN OF FIN FIN325 PRIN OF CREDIT MGT365 BUSINESS ETHICS MIS350 COBOL PROGRAMMING II MIS400 DATABASE DESIGN MIS421 SYS ANALY AND DES II MKT400 PRIN OF MKT MGT CDEPT AC FIN FIN MGT MIS MIS MIS MKT CTUIT 250.00 250.00 220.00 250.00 250.00 250.00 255.00 250.00 CLFEE 10.00 0.00 15.00 0.00 25.00 0.00 0.00 17.00 Figure 12 Model-Based Decision Support Software: Model-based analysis tools such as spreadsheet software enable managers to design models that incorporate business rules and assumptions. Microcomputer-based spreadsheet programs such as Lotussuits and Excel all support model building and what if? types of analysis. Mainframe-based spreadsheets such as Megacalc and Omnicalc fulfill the same purpose. Modeling tools like IFPS and Model are designed to support financial modeling and analysis. A good example of a spreadsheet application is a cash flow analysis. Figure 13 shows a cash flow statement for a small business. The spreadsheet includes formulas that calculate expenses, profits, and cash flow. In developing this spreadsheet, the manager projected that inflation would rise by 10 percent each year. Using this assumption, the free cash flow at the end of five year is Rs.3,351 thousands. By building in different assumptions, such as changes in inflation, operating expenses, and revenues, the manager could use the formulas in the spreadsheet to recalculate values such as total expenses, pretax profit, and cash flow. A

1.36 Information Systems Control and Audit spreadsheet is a valuable analysis tool because it makes it possible to analyze the impacts of different what if? situations. Tools for Statistics and Data Manipulation: Statistical analysis software such as SAS and SPSS supports market researchers, operations research analysts, and other professionals using statistical analysis functions. Because of the need for increased number crunching capabilities, this type of software usually runs on mainframe computers. Microcomputer-based statistical packages are available as well. For example, the micro-based version of SPSS has about the same capabilities as the mainframe version, but it is much slower. Year 1 REVENUE EXPENSES General & Admin. Salaries Payroll Taxes Office Expenses Professional Fees Travel Ent. And Promo. Total G & A Total Financing Interest Principal Principal Remaining TOTAL EXPENSES PRE-TAX PROFIT Income Tax AFTER-TAX PROFIT Repayment of Debt FREE CASH FLOW 19,500 5,000 6,500 1,000 1,500 6,000 39,500 8,318 8,125 193 49,807 47,625 2,375 1,188 1,188 193 995 50,000 Year 2 55,000 Year 3 60,000 Year 4 66,550 Year 5 73,205 21,450 5,500 7,150 1,100 1,650 6,600 43,450 8,318 8,094 224 49,583 51,543 3,457 1,728 1,728 224 1,504 23,595 6,050 7,865 1,210 1,815 7,260 47,795 8,318 8,057 261 49,322 55,852 4,648 2,324 2,324 261 2,063 23,955 6,655 8,652 1,331 1,997 7,986 52,574 8,318 8,015 303 49,019 60,589 5,961 2,980 2,980 303 2,677 28,550 7,320 9,517 1,464 2,196 8,785 57,832 8,318 7,966 352 48,666 65,797 7,408 3,704 3,704 352 3,351 Figure 13 : Cash flow analysis using spreadsheet Source : Arthur Williams, what IF (New York : John Wiley & Sons)

Information Systems Concepts 1.37 Display-Based Decision Support Software: The final category of decision support software is displaybased software. Graphic displays of output generated from MS-Excel spreadsheets, for example, are very effective in management presentations. Graphics tools running in a mainframe environment include DISSPLA, TELLAGRAF, and SASGRAPH. Microcomputerbased tools such as Harvard Graphics and PowerPoint display graphics output in the form of pie charts, bar charts, and graphs. One issue concerning decision support systems is the need for integrated tools. Integrated tools provide the ability to generate, manipulate, and statistically analyse data within a single software package. Individual tools supporting isolated decision support functions such as database query or modeling exist, but these tools are not always integrated with each other. An integrated tool can transfer data from a spreadsheet into a graphics program or from a database into a statistics program. For example, one might gather data on the profit percentage contribution of four major customers over the past five years. These data could be stored in a database. Based on these figures, one may like to project the profit percentage and gross income from these customers for the next five years. Using an integrated package like MS-EXCEL which is a microcomputer-based package incorporating spreadsheet, database, and graphics capabilities- one could use data from the database in a spreadsheet and then build a model to generate the desired projections. If one wants these projections to be displayed in graphics format, using a line graph or bar chart, one could transfer the data in the spreadsheet into a graphics format for display. 1.5.3.5 Examples of decision support systems in accounting Decision support systems are widely used as part of an orgnaisations AIS. The complexity and nature of decision support systems vary. Many are developed in-house using either a general type of decision support program or a spreadsheet program to solve specific problems. Below are several illustrations of these systems. Cost Accounting system : The health care industry is well known for its cost complexity. Managing costs in this industry requires controlling costs of supplies, expensive machinery, technology, and a variety of personnel. Cost accounting applications help health care organisations calculate product costs for individual procedures or services. Decision support systems can accumulate these product costs to calculate total costs per patient. Health care managers many combine cost accounting decision support systems with other applications, such as productivity systems. Combining these applications allows managers to measure the effectiveness of specific operating processes. One health care organisation, for example, combines a variety of decision support system applications in productivity, cost accounting, case mix, and nursing staff scheduling to improve its management decision making. Capital Budgeting System : Companies require new tools to evaluate high-technology investment decisions. Decision makers need to supplement analytical techniques, such as net present value and internal rate of return, with decision support tools that consider some benefits of new technology not captured in strict financial analysis. One decision support system designed to support decisions about investments in automated manufacturing technology is AutoMan, which allows decision makers to consider financial, nonfinancial,

1.38 Information Systems Control and Audit quantitative, and qualitative factors in their decision-making processes. Using this decision support system, accountants, managers, and engineers identify and prioritize these factors. They can then evaluate up to seven investment alternatives at once. Budget Variance Analysis System : Financial institutions rely heavily on their budgeting systems for controlling costs and evaluating managerial performance. One institution uses a computerized decision support system to generate monthly variance reports for division comptrollers. The system allows these comptrollers to graph, view, analyse, and annotate budget variances, as well as create additional one-and five-year budget projections using the forecasting tools provided in the system. The decision support system thus helps the comptrollers create and control budgets for the cost-center managers reporting to them. General Decision Support System : As mentioned earlier, some planning languages used in decision support systems are general purpose and therefore have the ability to analyze many different types of problems. In a sense, these types of decision support systems are a decision-makers tools. The user needs to input data and answer questions about a specific problem domain to make use of this type of decision support system. An example is a program called Expert Choice. This program supports a variety of problems requiring decisions. The user works interactively with the computer to develop a hierarchical model of the decision problem. The decision support system then asks the user to compare decision variables with each other. For instance, the system might ask the user how important cash inflows are versus initial investment amount to a capital budgeting decision. The decision maker also makes judgments about which investment is best with respect to these cash flows and which requires the smallest initial investment. Expert Choice analyzes these judgments and presents the decision maker with the best alternative. 1.5.4 Executive Information Systems (EIS) An executive information system (EIS) which is sometimes referred to as an executive support system (ESS) is a DSS that is designed to meet the special needs of top-level managers. Some people use the terms EIS and ESS inter changeably, but others do not. Any distinction between the two usually is because executive support systems are likely to incorporate additional capabilities such as electronic mail. In this section, we first cover those people in organisations that are considered to be executives and examine the types of decisions they make. Then, we will turn to the nature of executive decisions and the types of information that executives need most. Finally, some of the special characteristics of executive information systems beyond those of other decision support systems are discussed. Executives : An executive can probably best be described as a manager at or near the top of the organisational hierarchy who exerts a strong influence on the course taken by the organisation. The slots in a firm considered to be executive positions vary from company to company. For example, in many firms, the chief information officer (CIO) is usually an executive who participates in key strategic decisions. In other firms, the CIO is a middle manager (who often has a title other than CIO). And sometimes, the person in charge of an organisations CBIS is basically a data processing director.

Information Systems Concepts 1.39 1.5.4.1 Executive Roles and Decision Making: Most executive decisions fall into one of three classes: strategic planning, tactical planning, and fire-fighting activities (see Figure 14). Also, executives need a certain degree of control to ensure that these activities are carried out properly. A data flow representation of the executive decision-planning environment. Corresponding control activities exist for each of the planning functions Performance of firm Executive data bank Transaction processing data External environment Internal Projections Strategic planning Tactical planning Other areas of firm External data Firefighting The organization Figure 14 Strategic Planning: Strategic planning involves determining the general, long-range direction of the organisation. Typically, the CEO is ultimately responsible for the development of strategic plans. Tactical Planning : Whereas strategic planning addresses the general concerns of the firm, tactical planning refers to the how, when, where, and what issues involved with carrying out the strategic plan. Although executives will not normally be concerned with tactical details, they do need to worry about general tactics. For example, the vicepresident of finance must address how the firm can best achieve a balance between debt and equity financing. And the marketing vice-president will need to consider which classes of products the company should produce to be successful in the marketplace. Fire Fighting : Major problems arise sometimes that must be resolved by someone at an executive level. For example, if a company is involved in a big lawsuit that threatens its financial solvency, an executive must get involved. Other possible fire-fighting activities include damage caused to a major facility, the announcement of an important product by a

1.40 Information Systems Control and Audit competitor, a strike, and a sharp reversal of the economy. Many of these events will call for key alterations in plans. Control : In addition to planning and fire-fighting, executive management also needs to exert some general control over the organisation. For example, if the strategic plan calls for a 20 percent increase in profitability, feedback is needed to ensure that certain actions taken within the organisation are accomplishing that objective. Thus, executives will also periodically review key performance data to see how they compare against planned amounts. 1.5.4.2 The Executive DecisionMaking Environment : The three main sources for executive information are as follows: 1. 2. 3. Environmental information Competitive information Internal information The type of decisions that executives must make is broad. Often, executives make these decisions based on a vision they have regarding what it will take to make their companies successful. To a large extent, executives rely much more on their own intuition than on the sophisticated analytical skills. The intuitive character of executive decision-making is reflected strongly in the types of information found most useful to executives. Five characteristics of the types of information used in executive decision making are lack of structure, high degree of uncertainty, future orientation, informal source, and low level of detail. These are discussed below: Lack of structure: Many of the decisions made by executives are relatively unstructured. For instance, what general direction should the company take? Or what type of advertising campaign will best promote the new product line? These types of decisions are not as clear-cut as deciding how to debug a computer program or how to deal with an overdue account balance. Also, it is not always obvious which data are required or how to weigh available data when reaching a decision. For example, how does an executive assess the future direction of the economy if the six sources on which that person typically depends for information each forecast something different? Even the portfolio of decisions that need to be made by the executive is an open issue. Should time be spent, for instance, considering new businesses to enteror should the company concentrate on looking for new markets for existing products? High degree of uncertainty: Executives work in a decision space that is often characterized by a lack of precedent. ? For example, when the Arab oil embargo hit in the mid-1970s, no such previous event could be referenced for advice. Executives also work in a decision space where results are not scientifically predictable from

Information Systems Concepts 1.41 actions. If prices are lowered, for instance, product demand will not automatically increase. Future orientation: Strategic-planning decisions are made in order to shape future events. As conditions change, organisations must change also. It is the executives responsibility to make sure that the organisation keeps pointed toward the future. Some key questions about the future include: How will future technologies affect what the company is currently doing? What will the competition (or the government) do next? What products will consumers demand five years from now? Where will the economy move next, and how might that affect consumer buying patterns? As one can see, the answers to all of these questions about the future external environment are vital. Informal source: Executives, more than other types of managers, rely heavily on informal source for key information. For example, lunch with a colleague in another firm might reveal some important competitor strategies. Informal sources such as television might also feature news of momentous concern to the executive news that he or she would probably never encounter in the companys database or in scheduled computer reports. Besides business meals and the media, some other important information sources of information are meetings, tours around the companys facilities to chat with employees, brainstorming with a trusted colleague or two, and social events. Low level of detail: Most important executive decisions are made by observing broad trends. This requires the executive to be more aware of the large overview than the tiny items. Even so, many executives insist that the answers to some questions can only be found by mucking through details. EIS Roles and Characteristics 1.5.4.3 Because executives deal primarily with data about the external environment and data that come from informal sources, they are usually less reliant on direct contact with information technology than other types of managers. When information from their companys computers is needed, many chief executive officers make their subordinates retrieve that information. Because executive information needs are more ambiguous than those of other levels of management, computers have historically been less useful to executives. Many executives have little hands-on experience with computers and do not fully appreciate how information technology can improve their personal productivity and decision making skills. Studies on EIS implementation show that thousands of companies have implemented executive information systems. Usually, the executive information systems provide executives with access to financial data, marketing and sales information, human resources information, manufacturing data, and competitive/ strategic information.

1.42 Information Systems Control and Audit Electronic mail, access to external news and databases, word processing, spreadsheet, and automated filing capabilities are also common in business executive information systems. While it is often expensive to develop and maintain an EIS, many organisations feel that enhanced top level decision making is a benefit that more than balances out any costs associated with the system. 1.5.4.4 What is An Executive Information System? An Executive Information System (EIS) is a tool that provides direct on-line access to relevant information in a useful and navigable format. Relevant information is timely, accurate, and actionable information about aspects of a business that are of particular interest to the senior manager. The useful and navigable format of the system means that it is specifically designed to be used by individuals with limited time, limited keyboarding skills, and little direct experience with computers. An EIS is easy to navigate so that managers can identify broad strategic issues, and then explore the information to find the root causes of those issues. Executive Information Systems differ from traditional information systems in the following ways: They are specifically tailored to executive's information needs. They are able to access data about specific issues and problems as well as aggregate reports. They provide extensive on-line analysis tools including trend analysis, exception reporting. They can access a broad range of internal and external data. They are particularly easy to use (typically mouse or touch-screen driven). They are used directly by executives without assistance. Screen-based - All EISs are delivered through terminals using easy-to-use software. Information tends to be presented by pictorial or graphical means. Information is presented in summary format, e.g. sales for the whole company. There is, however, the facility to drill down to other levels of information to see how the sale figure were arrived at -by geographical location, by product group etc. (although individual transactions are not usually available). The ability to manipulate data, to project what if outcomes and to work with modeling tools within the system are also evident in EIS. This is particularly so with external information that can be superimposed onto the companys information, e.g. sales forecasts with information from the Meteorological Office about the weather.

Information Systems Concepts 1.43 EIS require large amounts of capacity and processing power within both the system and the network, and whilst suppliers hardware costs per unit of power are falling, the software costs required to support such systems are increasing, and this will be where the efficiencies are required in the future. Although most computer systems may contain some of the above characteristics, they can be differentiated from EIS in a number of ways. Most MIS and operational systems are based on transaction processing carried out by a variety of on-line and batched inputs. Unlike the EIS, information is usually presented in numerical or textual form and reporting is by exception, usually in printed report format. Also, EISs tend to be externally-focused, strategically-based systems using both internal and external data, whereas other computer systems mainly concentrate on internal control aspects of the organisation. 1.5.4.5 Purpose of EIS: These are stated below : (i) The primary purpose of an Executive Information System is to support managerial learning about an organization, its work processes, and its interaction with the external environment. Informed managers can ask better questions and make better decisions. (ii) A secondary purpose for an EIS is to allow timely access to information. All of the information contained in an EIS can typically be obtained by a manager through traditional methods. However, the resources and time required to manually compile information in a wide variety of formats, and in response to ever changing and ever more specific questions usually inhibit managers from obtaining this information. Often, by the time a useful report can be compiled, the strategic issues facing the manager have changed, and the report is never fully utilized. Timely access also influences learning. When a manager obtains the answer to a question, that answer typically sparks other related questions in the manager's mind. If those questions can be posed immediately, and the next answer retrieved, the learning cycle continues unbroken. Using traditional methods, by the time the answer is produced, the context of the question may be lost, and the learning cycle will not continue. (iii). A third purpose of an EIS is commonly misperceived. An EIS has a powerful ability to direct management attention to specific areas of the organization or specific business problems. Some managers see this as an opportunity to discipline subordinates. Some subordinates fear the directive nature of the system and spend a great deal of time trying to outwit or discredit it. Neither of these behaviours is appropriate or productive. Rather, managers and subordinates can work together to determine the root causes of issues highlighted by the EIS. The powerful focus of an EIS is due to the saying what gets measured gets done. Managers are particularly attentive to concrete information about their performance when it is available to their superiors. This focus is very valuable to an organization if the

1.44 Information Systems Control and Audit information reported is actually important and represents a balanced view of the organizations objectives. Misaligned reporting systems can result in inordinate management attention to things that are not important or to things which are important but to the exclusion of other equally important things. For example, a production reporting system might lead managers to emphasize volume of work done rather than quality of work. Worse yet, productivity might have little to do with the organization's overriding customer service objectives. 1.5.4.6 Contents of EIS: A general answer to the question of what data is appropriate for inclusion in an Executive Information System is whatever is interesting to executives. Executive Information Systems in government have been constructed to track data about Ministerial correspondence, case management, worker productivity, finances, and human resources to name only a few. Other sectors use EIS implementations to monitor information about competitors in the news media and databases of public information in addition to the traditional revenue, cost, volume, sales, market share and quality applications. Frequently, EIS implementations begin with just a few measures that are clearly of interest to senior managers, and then expand in response to questions asked by those managers as they use the system. Over time, the presentation of this information becomes stale, and the information diverges from what is strategically important for the organization. While the above indicates that selection of data for inclusion in an EIS is difficult, there are several guidelines that help to make that assessment. A practical set of principles to guide the design of measures and indicators to be included in an EIS is presented below 1. EIS measures must be easy to understand and collect. Wherever possible, data should be collected naturally as part of the process of work. An EIS should not add substantially to the workload of managers or staff. EIS measures must be based on a balanced view of the organization's objective. Data in the system should reflect the objectives of the organization in the areas of productivity, resource management, quality and customer service. Performance indicators in an EIS must reflect everyone's contribution in a fair and consistent manner. Indicators should be as independent as possible from variables outside the control of managers. EIS measures must encourage management and staff to share ownership of the organization's objectives. Performance indicators must promote both team-work and friendly competition. Measures will be meaningful for all staff; people must feel that they, as individuals, can contribute to improving the performance of the organization. 2. 3. 4.

Information Systems Concepts 5. 1.45 EIS information must be available to everyone in the organization. The objective is to provide everyone with useful information about the organization's performance. Information that must remain confidential should not be part of the EIS or the management system of the organization. EIS measures must evolve to meet the changing needs of the organization. Commercially Available EIS Products 6. 1.5.4.7 Many EIS generators EIS development packages are commercially available. Commander EIS (from Comshare, Inc.), Command Center (from Pilot Executive Software), Executive Edge (from Execucom Systems Corporation), and Express EIS (from Information Resources, Inc.) are among the market leaders in the U.S. RESOLVE is another leading product, especially in Europe. Self-examination Questions 1. Define in following terms : (i) (ii) 2. (i) (ii) 3. 4. 5. 6. 7. 8. 9. System Subsystem Deterministic and probabilistic systems Open and closed systems (iii) Boundary (iv) System environment Differentiate between the following : (iii) Sub-system and supra-system Explain the concept of decomposition with the help of an example. What is information? What are the attributes of information ? Explain various types of information systems at various levels of management. What is decision support system ? Explain, in brief, various characteristics of a decision support system. What are the four basic components of a DSS? Explain them. Explain four categories of software tools available for Decision support systems. 10. Decision support systems are widely used as part of an organisations AIS. Give examples to support this statement. 11. What is an Executive Information System? 12. What role do executives play in decision making? 13. Discuss the characteristics of the information used in decision making?

1.46 Information Systems Control and Audit 14. What purposes are served by an EIS? 15. Outline various principles to be followed while designing an EIS.

2 SYSTEM DEVELOPMENT LIFE CYCLE METHODOLOGY 2.0 INTRODUCTION The purpose of this chapter is to introduce the students to the concepts of system development process. The system development life cycle i.e., the set of activities that a system analyst or designer has to carry out to develop an information system and various approaches of development are also discussed. 2.1 WHAT IS SYSTEMS DEVELOPMENT PROCESS? Computer information systems serve many different purposes, ranging from the processing of business transactions-the life blood of many rganization -to providing information needed to decide recurring issues, assisting senior officials with difficult strategy formulation, and linking office information and corporate data. But how do such complex information systems come into existence? Of course, through people. Technology has developed at a rapid race but the most important aspect of any system is human know-how and the use of ideas to harness the computer so that it performs the required tasks. This process is essentially what system development is all about. To be of any use, a computer-based information system must function properly, be easy to use, and suit the rganization for which it has been designed. If a system helps people to work more efficiently they will use it. If not, they will surely avoid it. In business, systems development refers to the process of examining a business situation with the intent of improving it through better procedures and methods. Systems development can generally be thought of as having two major components: systems analysis and systems design. Systems design is the process of planning a new business system or one to replace or complement an existing system. But before this planning can be done, one must thoroughly understand the old system and determine how computers can be used (if at all) to make its operation more effective. Systems analysis, then, 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 System Analyst. Consider, for example, stockroom operations of a clothing store. To better control its inventory and gain access to more up-to-date information about stock levels and reordering, the Stores

2.2 Information Systems Control and Audit Manager asks a system analyst to rganizatio the stockroom operations. Before the analyst can design a system to capture data, update files and produce reports, he needs to know more about how the store currently operates: what forms are being used to store information manually, such as requisitions, purchase orders and invoices etc, and what reports are being produced and how they are being used. To proceed, the analyst seeks information about lists of reorder notices, outstanding purchase orders, records of stock on hand, and other reports. He also tries to find out where this information originates, whether in the purchasing department, stockroom or accounting department. In other words, he tries to understand how the existing system works and more specifically what the flow of information through the system looks like. He will also try to know why the stores manager wants to change the current operations. Does the business have problems tracking orders, merchandise, or money, etc? Is the system falling behind in handling inventory records? Does it need a more efficient system before it can expand operations? After collecting all these facts, the analyst begins to determine how and where a computer information system can benefit all the users of the system. This accumulation of information called a system study must precede all other analysis activities. System analysts do more than just solve current problems. They assess, as carefully as possible, what the future need of the system will be and what changes should be considered to meet these needs. They may recommend alternatives for improving the situation. For each alternative, they consider its suitability to the particular rganization setting, the support it may get from the employees, time involved in its development and costs and benefits of the system in question. Based on these factors, the analysts recommend to the management, after consulting various managers and employees in the rganization, which alternative to adopt. The management then decides which alternative to accept. Once this decision is made, a plan is developed to implement the recommendations. The plan includes all system design features, file specifications, operating procedures, and design features, and equipment and personnel requirements. The system design is like the blue print for a building, it specifies all the features that should be there in the finished product. 2.2 SYSTEM DEVELOPMENT LIFE CYCLE The process of system development starts when management or sometimes system development personnel realise that a particular business system needs improvement. The system development life cycle method can be thought of as a set of activities that analysts, designers and users carry out to develop and implement an information system. In this chapter, we will examine each of the six activities that make up the systems development life cycle. In most business situations, these activities are all closely related, usually inseparable and even the order of the steps in these activities may be difficult to determine. Different parts of a project can be in various phases at the same time, with some components undergoing analysis while others are at advanced design stages.

System Development Life Cycle Methodology The systems development life cycle method consists of the following activities: (i) (ii) Preliminary investigation Requirements analysis or systems analysis 2.3 (iii) Design of system (iv) Development of software (v) Systems testing (vi) Implementation and maintenance (i) Preliminary investigation : A preliminary investigation is undertaken when users come across a problem or opportunity and submit a formal request for a new system to the MIS department. This activity consists of three parts: request clarification, feasibility study and request approval. Generally the requests which are submitted to the MIS department, are not clearly stated. Hence, before any system investigations can be considered, the system request must be examined to determine precisely what the originator wants. Thereafter, the analyst tries to determine whether the system requested is feasible or not. Aspects of technical, economic and operational feasibility of the system are covered in the feasibility study. The third part of the investigation relates to approval of the request. Not all requested systems are desirable or feasible. Based on the observations of the analyst, the management decides which system should be taken up for development. (ii) Requirements analysis or systems analysis : If, after studying the results of preliminary investigation, management decides to continue the development process, the needs of the users are studied. Analysts work closely with employees and managers of the organisation for determining information requirements of the users. Several fact-finding techniques and tools such as questionnaires, interviews, observing decision-maker behaviour and their office environment etc. are used for understanding the requirements. As details are gathered, the analysts study the present system to identify its problems and shortcomings and identify the features, which the new system should include to satisfy the new or changed user application environment. This step is also referred to as systems analysis. (iii) Design of the system: During system design, the user requirements that arose from analysing the user applications environment are incorporated into a new systems design. The design of an information system produces the details that state how a system will meet the requirements identified above. The analyst designs various reports/outputs, data entry procedures, inputs, files and database. He also selects file structures and data storage devices. These detailed design specifications are then passed on to the programming staff so that software development can begin. (iv) Acquisition and development of software : After the system design details are resolved, such resources needs as specific type of hardware, software, and services are determined. Subsequently, choices are made regarding which products to buy or lease from

2.4 Information Systems Control and Audit which vendors. Software developers may install (or modify and then install, purchased software or they may write new, custom-designed programs. The choice depends on many factors such as time, cost and availability of programmers. The analyst works closely with the programmers if the software is to be developed in-house. During this phase, the analyst also works with users to develop worthwhile documentation for software, including various procedure manuals. (v) Systems testing : Before the information system can be used, it must be tested. Systems testing is done experimentally to ensure that the software does not fail i.e. it will run according to its specifications and in the way users expect. Special test data are input for processing, and results examined. If it is found satisfactory, it is eventually tested with actual data from the current system. (vi) Implementation and maintenance : After the system is found to be fit, it is implemented with the actual data. Hardware is installed and users are then trained on the new system and eventually work on it is carried out independently. The results of the development efforts are reviewed to ensure that the new system satisfies user requirements. After implementation, the system is maintained; it is modified to adapt to changing users and business needs so that the system can be useful to the organisation as long as possible. The system development life cycle should be viewed as a continuous iterative process that recycles through each stage for many applications. Thus, even when a system is fully specified, designed, purchased and running, it is continually being enhanced or maintained. Enhancement and maintenance may require returning to one of the earlier stages of system development life cycle. 2.2.1 Achieving systems development objectives: There are many reasons why organisations fail to achieve their systems development objectives. Although we cannot catalog all the reasons, we can summarize a few representative samples here: Lack of senior management support for and involvement in information systems development. Developers and users of information systems will watch senior management to determine which systems development projects are important and will act accordingly by shifting their efforts away from any project not receiving management attention. In addition, management can see that adequate resources, as well as budgetary control over use of those resources, as well as budgetary control over use of those resources, are dedicated to the project. Shifting user needs. User requirements for information technology are constantly changing. As these changes accelerate, there will be more requests for systems development and more development projects. When these changes occur during a development process, the development team may be faced with the challenge of developing systems whose very purposes have changed since the development process began. Development of strategic systems. Because strategic decision making is unstructured, the requirements, specifications, and objectives for such development projects are difficult to define; and determining successful development will be elusive.

System Development Life Cycle Methodology 2.5 New technologies. When an organisation tries to create a competitive advantage by applying advanced information technology, it generally finds that attaining systems development objectives is more difficult because personnel are not as familiar with the technology. Lack of standard project management and systems development methodologies. Some organisations do not formalise their project management and systems development methodologies, thereby making it very difficult to consistently complete projects on time or within budget. Overworked or under-trained development staff. Estimates of the backlog of systems development work facing development staffs range up to 4 years!. In addition to being overworked, systems developers often lack sufficient education background. Furthermore, many companies do little to help their development personnel stay technically currently; in these organisations, a training plan and training budget do not exist. Resistance to change: People have a natural tendency to resist change, and information systems development projects signal changes -often radical- in the workplace. Business process reengineering is often the catalyst for the systems development project. When personnel perceive that the project will result in personnel cutbacks, threatened personnel will dig in their heels, and the development project is doomed to failure. Personnel cutbacks often result when reengineering projects are really attempts at "downsizing" (or "rightsizing") Lack of user participation: Users must participate in the development effort to define their requirements, feel ownership for project success, and work to resolve development problems. User participation also helps reduce user resistance to change. Inadequate testing and user training. New systems must be tested before installation to determine that they will operate correctly. Users must be training to effectively utilise the new system. To overcome these and other problems, organisations must execute the systems development process efficiently and effectively. 2.2.2 Approaches to Systems Development: Since organisations vary significantly in the way that they automate their business procedures, and since each new type of system usually differs from any other, several different systems development approaches are often used within an organisation. We will now discuss the traditional approach now. Alternate approaches will be discussed in subsequent sections. Traditional approach : In the traditional approach of the systems development, activities are performed in sequence. Figure-1 shows examples of the tasks performed during each phase of the traditional approach. Managers and users are most likely to interact with systems

2.6 Information Systems Control and Audit analysts, systems designers and application programmers when the traditional approach is used. During the preliminary investigation and requirement analysis phases in which user information needs are identified, systems development activities are usually led by a systems analyst. The system analyst may play a less important role during the design and implementation stages. During these later stages, they may turn over the project to system designers. If new programs are required to be written or existing programs are to be modified, application programmes become involved during the software development and implementation stages. When the traditional approach is applied, an activity is undertaken only when the prior step is fully completed. Managers and users consider and review the work performed by MIS professionals during each stage of process before proceeding to the next stage. Managers will probably review diagrams, explanation charts and so on, in order to ensure that the work is accurate and complete. If the work is satisfactory, managers and users formally sign off or accept the work and allow the systems development team to proceed to the next step. It is important under traditional approach that managers and users should throughly review the work before granting their permission to start the next activity. Perception and expression of needs Preliminary investigation Requirements analysis System design System acquisition System testing System implementation and maintenance Figure 1. The traditional approach is applied to the development of larger computer based information systems such as the transaction processing systems. Because the processing requirements of these systems are well understood, the risk of users and systems analysts misperceiving the system are less than for other types of systems. Feed back

System Development Life Cycle Methodology 2.3 SYSTEMS DEVELOPMENT METHODOLOGY 2.7 A systems development methodology [also known as systems development life cycle (SDLC) methodology] is a formalized, standardized, documented set of activities used to manage a systems development project. It should be used when information systems are developed, acquired, or maintained. The methodology is characterised by the following: The project is divided into a number of identifiable processes, and each process has a starting point and an ending point. Each process comprises several activities, one or more deliverables, and several management control points. The division of the project into these small, manageable steps facilitates both project planning and project control. Specific reports and other documentation, called deliverables, must be produced periodically during systems development to make development personnel accountable for faithful execution of system development tasks. An organisation monitors the development process by reviewing the deliverables that are prepared at the end of each key step. Many organisations rely on this documentation for training new employees; it also provides users with a reference while they are operating the system. Users, managers, and auditors are required to participate in the project. These people generally provide approvals, often called signoffs, at pre-established management control points. Signoffs signify approval of the development process and the system being developed. The system must be tested thoroughly prior to implementation to ensure that it meets users needs. A training plan is developed for those who will operate and use the new system. Formal program change controls are established to preclude unauthorized changes to computer programs. A postimplementation review of all developed systems must be performed to assess the effectiveness and efficiency of the new system and of the development process. An organization's systems development methodology should be documented in the form of a systems development standards manual. Among other items, such manuals often indicate: Methods for requesting systems development. Procedures to be followed, techniques to be used, and documentation to be prepared during systems development. Reviews to be performed and signoffs to be obtained. 2.3.1 System Development Team : Several people in the organisation are responsible for systems development. In large systems, the worth of a particular project is typically decided by a top management level steering committee. This committee usually consists of a group of key

2.8 Information Systems Control and Audit IS services users that acts as a review body for IS plans and applications development. The steering committee ensures that ongoing systems development activities are consistently aimed at satisfying the information requirements of managers and users within the organisation. If the project appears worthwhile to the steering committee, it becomes the responsibility of the IS department to develop it successfully. In order to coordinate development activities of the system, a project management team generally consisting of both computer professionals and key users is appointed. Systems analysts are subsequently assigned to determine user requirements, design the system and assist in development and implementation activities. In any systems organisation, however, systems designers take a lead role during the design, development and implementation stages. In end-user developed systems, the end-user is ultimately responsible for the system. Generally, the end-user seeks guidance from information centre personnel while developing the system. Some organisations require the information centre to certify the final system as a quality assurance measure. 2.3.2 Accountants involvement in development work : Most accountants are uniquely qualified to participate in systems development because they may be among the few people in an organization who can combine knowledge of IT, business, accounting, and internal control, as well as behaviour and communications, to ensure that new systems meet the needs of the user and possess adequate internal controls. They have specialized skills - such as accounting and auditing - that can be applied to the development project. For example, an accountant might perform the analysis of a proposed system's costs and benefits. As internal, information technology (IT), and independent auditors, accountants provide a unique- and independent -perspective with which to evaluate the systems development process and the systems being developed. 2.4 THE PRELIMINARY INVESTIGATION In Section 2.1, we briefly discussed the systems development process and its six stages. We will now discuss each of the stages of the systems development cycle in more detail. The purpose of this section is to highlight basic activities that are performed by the system analyst during the first stage of system development life cycle. 2.4.1 Definition of the scope of the study : Systems development usually begins when a problem or opportunity is identified by managers and users. For instance, personnel in a functional area may feel that an existing system is outdated or a manager might want access to specific, new information that he claims will lead to better decisions. Shifting business requirements, changing organizational environments, and evolving information technology may render systems ineffective or inefficient. For example, the availability of Universal Product Code (UPC) scanners led supermarkets to study their existing checkout and inventory systems to determine whether these systems could be improved by installing this new technology. In addition to conducting reviews to determine whether we should adopt new

System Development Life Cycle Methodology information technology, we conduct planned reviews to determine whether: 2.9 A system still satisfies users' information needs. For example, do the system's reports provide sufficient information to solve the problems presently facing management? New design ideas can be incorporated. For example, should the organization develop an online transaction processing (OLTP) system? Evolving environmental changes, such as competition, require system changes. For example, should the organisation provide direct computer links with its customers for online, direct customer ordering, perhaps using EDI? New types of business by the firm require system changes. For example, has a traditional wholesaler added a service or retail oriented branch requiring that consideration be given to an Internet site for customer sales and service? The user requests systems development when the system no longer efficiently and effectively meets the goals of the system. For example, a change in government regulations may require new or modified reports. Excessive time spent correcting errors. Current reports not meeting user decision-making needs. Escalating customer or vendor complaints. Erroneous system outputs causing problems Information system-caused delays slowing the operations system. Application is not year-2000 ("Y2K") compliant and will be unable to accurately handle dates. Other examples in the user-request category are: Whatever may be the reason, managers and users may feel compelled to submit a request for a new system to the IS department. If the need seems genuine, a system analyst is assigned to make a preliminary investigation. Whether a system will be developed by means of the traditional approach, a prototype strategy or end-user approach, or a combination of these methods, the request for the project development should first be reviewed. It is advisable for all proposals to be submitted to the steering committee for evaluation to identify those projects that are most beneficial to the organisation. A preliminary investigation is then carried out by systems analyst, working under the direction of the steering committee. The purpose of the preliminary investigation is to evaluate the project request. It is neither a designed study, nor it includes the collection of details to completely describe the business system. Rather it relates to collection of information that permits committee members to evaluate the merits of the project request and make an informed judgement about the feasibility of the proposed project.

2.10 Information Systems Control and Audit The analyst working on the preliminary investigation should accomplish the following objectives: 1. Clarify and understand the project request : What is presently being done? What is required and why ? Is there an underlying reason different from the one the user has identified? Determine the size of the project : Does a request for a project call for new development or for modification of the existing system? The investigation to answer this question will also gather the details useful in estimating the amount of time and number of people required to develop the project. Determine the technical and operational feasibility of alternative approaches. Assess costs and benefits of alternative approaches : What are the estimated cost for developing a particular system? Will the proposed system reduce operating costs? Will the proposed system provide better services to customers, etc? Report findings to the management with recommendation outlining the acceptance or rejection of the proposal. 2. 3. 4. 5. 2.4.2 Conducting the Investigation : During preliminary investigation, the analysis collect the data through two primary methods. 1 Reviewing internal documents : The analysts conducting the investigation first try to learn about the organisation involved in, or affected by, the project. For example, to review an inventory system proposal, the analyst will try to know how the inventory department operates and who are the managers and supervisors. Analysts can usually learn these details by examining organisation charts and studying written operating procedures. 2. Conducting Interviews : Written documents tell the analyst how the systems should operate, but they may not include enough details to allow a decision to be made about the merits of a systems proposal, nor do they present users' views about current operations. To learn these details, analysts use interviews. Interviews allow analysts to know more about the nature of the project request and the reasons for submitting it. Usually, preliminary investigation interviews involve only management and supervisory personnel. 2.4.3 Identifying Viable Options : After problems or opportunities are identified, the analysts must determine the scale of response needed to meet the user's requests for a new system, as well as the approximate amount of time and money that will be required in the effort. The analysts then determine just how much management wants to spend or change. Possible solutions are then examined in the light of the findings. Because of the myriad possibilities involved in most business situations every problem is different, and may require a solution different from that used in the past. Thus, common sense and intuition are key ingredients in the solution development process.

System Development Life Cycle Methodology 2.11 2.4.4 Testing Project's Feasibility : After possible solution options are identified, project feasibility-the likelihood that these systems will be useful for the organisation-is determined. A feasibility study is carried out by the system analysts for this purpose. Feasibility study refers to a process of evaluating alternative systems through cost/benefit analysis so that the most feasible and desirable system can be selected for development. The feasibility study of a system is undertaken from three angles : technical, economic and operational feasibility. The proposed system is evaluated from a technical view point first and if technically feasible, its impact on the organisation and staff is assessed. If a compatible technical and social system can be devised, it is then tested for economic feasibility. Technical feasibility: It is concerned with hardware and software. Essentially, the analyst ascertains whether the proposed system is feasible with existing or expected computer hardware and software technology. The technical issues usually raised during the feasibility stage of investigation include the following: 1. 2. 3. 4. 5. Does the necessary technology exist to do what is suggested (and can it be acquired)? Does the proposed equipment have the technical capacity to hold the data required to use the new system? Will the proposed system provide adequate responses to inquires, regardless of the number or location of users? Can the system be expanded if developed? Are there technical guarantees of accuracy, reliability, ease of access, and data security? Table-1 Design Considerations Communications channel configuration Communications channels Communications network Computer programs Data storage medium Data storage structure File organization and access Input medium Operations Design Alternatives Point to point, multidrop, or line sharing Telephone lines, coaxial cable, fiber optics, microwave, or satellite Centralized, decentralised, distributed, or local area Independent vendor or inhouse Tape, floppy disk, hard disk, or hard copy Files or database Direct access or sequential files Keying, OCR, MICR, POS, EDI, or voice recognition Some of the technical issues to be considered are given in the Table-1 below.

2.12 Information Systems Control and Audit In-house or outsourcing Instantaneous, hourly, daily, weekly, or monthly CRT, hard copy, voice, or turnaround document Predetermined times or on demand Preprinted forms or system-generated forms Micro, mini, or mainframe Batch or online Instantaneous, hourly, daily, weekly, or monthly Output frequency Output medium Output scheduling Printed output Processor Transaction processing Update frequency Due to tremendous advancements in computer field these days, the technology is available for most business data processing systems but sometimes not within the constraints of the firm's resources or its implementation schedule. Therefore, trade offs are often necessary. A technically feasible system may not be economically feasible or may be so sophisticated that the firm's personnel cannot effectively operate it. Economic feasibility : It includes an evaluation of all the incremental costs and benefits expected if the proposed system is implemented. This is the most difficult aspect of the study. The financial and economic questions raised by analysts during the preliminary investigation are for the purpose of estimating the following : (i) The cost of conducting a full systems investigation. (ii) The cost of hardware and software for the class of applications being considered. (iii) The benefits in the form of reduced costs or fewer costly errors. (iv) The cost if nothing changes (i.e., the proposed system is not developed) The procedure employed is the traditional cost-benefit study. Operational feasibility : It is concerned with ascertaining the views of workers, employees, customers and suppliers about the use of computer facility. The support or lack of support that the firm's employees are likely to give to the system is a critical aspect of feasibility. A system can be highly feasible in all respects except the operational and fails miserably because of human problems. Some of the questions which help in testing the operational feasibility of a project are stated below: Is there sufficient support for the system from management? From users? If the current system is well liked and used to the extent that persons will not be able to see reasons for a change, there may be resistance. Are current business methods acceptable to users? If they are not, users may welcome a change that will bring about a more operational and useful system.

System Development Life Cycle Methodology 2.13 Have the users been involved in planning and development of the project? Early involvement reduces the chances of resistance to the system and change in general and increase the likelihood of successful projects. Will the proposed system cause harm? Will it produce poorer results in any respect or area? Will loss of control result in any areas? Will accessibility of information be lost? Will individual performance be poorer after implementation than before? Will performance be affected in an undesirable way? Will the system slow performance in any areas? Schedule Feasibility : Schedule feasibility involves the design teams estimating how long it will take a new or revised system to become operational and communicating this information to the steering committee. For example, if a design team projects that it will take 16 months for a particular system design to become fully functional, the steering committee may reject the proposal in favour of a simpler alternative that the company can implement in a shorter time frame. Legal Feasibility : Legal feasibility is largely concerned with whether there will be any conflict between a newly proposed system and the organisations legal obligations. For example, a revised system should comply with all applicable federal and state statutes about financial reporting requirements, as well as the companys contractual obligations. Estimating costs and benefits : After possible solution options are identified, the analyst should make a primary estimate of each solution's costs and benefits. Cost : System costs can be sub divided into development, operational and intangible costs. Development costs for a computer based information system include costs of the system development process such as (i) (ii) salaries of the system analysts and computer programmers who design and program the system, cost of converting and preparing data files and preparing systems manual and other supportive documents, (iii) cost of preparing new or expanded computer facilities, (iv) cost of testing and documenting the system, training employees, and other start up costs. Operating costs of a computer based information system include (i) (ii) hardware/software rental or depreciation charges, salaries of computer operators and other data processing personnel who will operate the new system, (iii) salaries of system analysts and computer programmers who perform the system maintenance function,

2.14 Information Systems Control and Audit (iv) cost of input data preparation and control, (v) cost of data processing supplies, (vi) cost of maintaining proper physical facilities including power, light, heat, air conditioning, building rental or other facility charges and equipment and building maintenance charges, overhead charges of the business firm. Intangible costs are costs that cannot be easily measure. For example, the development of a new system may disrupt the activities of an organisation and cause a loss of employee productivity or morale. Customer sales and goodwill may be lost by errors made during the installation of a new system. Such costs are difficult to measure in rupees but are directly related to the introduction and operation of information system. Benefits: The benefits which result from developing new or improved information systems that utilise EDP can be subdivided into tangible and intangible benefits. Tangible benefits are those that can be accurately measured and are directly related to the introduction of a new system, such as decrease in data processing cost. Intangible benefits such as improved business image are harder to measure and define. Benefits that can result from the development of a computerised system are summarised below: 1. 2. 3. 4. 5. 6. 7. 8. 9. Increase in sales or profits (improvement in product or service quality). Decrease in data processing costs (elimination of unnecessary procedures and documents). Decrease in operating costs (reduction in inventory carrying costs). Decrease in required investment (decrease in inventory investment required). Increased operational ability and efficiency (improvement in production ability and efficiency; for example, less spoilage, waste, and idle time). New or improved information availability (more timely and accurate information, and new types and forms of information) Improved abilities in computation and analysis (mathematical simulation). Improved customer service (more timely service). Improved employee morale (elimination of burdensome and boring job tasks). 10. Improved management decision making (better information and decision analysis) 11. Improved competitive position (faster and better response to actions of competitors) 12. Improved business and community image (progressive image as perceived by customers, investors, other businesses, government and the public). Intangible though it is important to put a rupee and paise tag to each benefit for purposes of

System Development Life Cycle Methodology 2.15 profit and loss statement, which can be done with diligence on the part of operating managers. The operating manager has homework to do here. The analyst can estimate for him the proportion of time the computer would save for the Chief Buyer, for example, by taking over his routine tasks and programmable decision making. It is now for the chief buyer to deliberate and come out with how best to utilise this time. He can, for example, undertake more extensive sourcing, spend more time on negotiations, participate more heavily in the value analysis effort and so on; therefore, it is he who has to quantify the benefits in monetary terms. This has led to dual advantage that subsequently during systems audit his performance can be appraised i.e., to what extent the payoffs he anticipated were actually realised upon computerization. However, it must be mentioned in passing that not all benefits are so hard to quantify. A computersied payroll system, for example, would likely displace some clerks and it is easy enough to measure benefits in that case. 2.4.5 Reporting Results to Management : After the analyst articulates the problem and its scope, provides one or more solution alternatives and estimates the cost and benefits of each alternative, he reports these results to the management. The report should be accompanied by a short cover letter that summarizes the results and makes the recommendation regarding further procedures. From the analyst's report, management should determine what to do next. Not all projects submitted for evaluation and review are accepted. Requests that fail to pass feasibility test are not pursued further unless they are reworked and resubmitted as new proposals. In some cases, only a part of the project is actually unworkable and the steering committee may decide to combine the workable part of the project with another feasible proposal. In certain other cases, primary investigation produces new information to suggest that improvements in management and supervision, and not the development of information systems are the actual solutions to the reported problems. 2.5 STAGE II - REQUIREMENTS ANALYSIS OR SYSTEMS ANALYSIS In this section, we shall discuss the second stage of systems development life cycle viz. requirements analysis which involves determining users' needs studying the present system of the organisation indepth, and determining the features which the new system should possess. Various fact finding techniques and system development tools are also discussed. Requirements Analysis : If the management decides to continue developing the system after reading the analyst's report, the requirement analysis phase of system development begins. During the requirement analysis phase of the traditional approach, the focus is on determining user needs, studying the application area in depth, assessing the strengths and weaknesses of the present system and reporting results to management. However, under prototype approach the requirement analysis and design phases proceed in tandem and in small increments. For example, user needs are determined at any time only to the degree that they are needed to design the next iteration of the prototype. While the user is experimenting with the prototype, the systems analyst observes the user and puts these observations into perspective in order to determine how the prototype should be further designed.

2.16 Information Systems Control and Audit How thoroughly the present system is studied depends on the situation. To determine if the present system needs just a few adjustments instead of a complete overhaul, the system should be studied in depth. However, if management is determined to replace the current system, the analyst would probably just waste time by studying it thoroughly. In this case, it is better to spend time in determining exactly what management desires in the new system. While studying the present system the systems analyst must analyse how this system uses hardware, software and human resources to convert the data of the organisation into information for end users. He should also analyse how these resources are used to accomplish the activity of input, processing, output, storage and control. 2.5.1 Fact finding techniques : Every system is built to meet some set of needs, for example, the need of the organisation for lower operational costs, better information for managers, smooth operations for users or better levels of service to customers. To assess these needs, the analysts often interact extensively with the people, who will be benefited from the system, in order to determine what are their actual requirements. Various fact-finding techniques, which are used by the system analyst for determining these needs/ requirements, are briefly discussed below : 1. Documents : Document means manuals, input forms, output forms, diagrams of how the current system works, organisation charts showing hierarchy of users and manager responsibilities, job descriptions for the people who work with the current system, procedure manuals, program codes for the applications associated with the current system, etc. Documents are a very good source of information about user needs and the current system. They are easy to collect, convey a lot of information and provide relatively objective data. The analyst should ensure that the documents which he is collecting are current, accurate and contain upto-date information. 2. Questionnaires : Users and managers are asked to complete questionnaire about the information system when the traditional system development approach is chosen. The main strength of questionnaires is that a large amount of data can be collected through a variety of users quickly. Also, if the questionnaire is skillfully drafted, responses can be analysed rapidly with the help of a computer. 3. Interviews: Users and managers may also be interviewed to extract information in depth. The data gathered through interviews often provide systems developer with a complete picture of the problems and opportunities. Interviews also give analyst the opportunity to note user reaction first-hand and to probe for further information. 4. Observation. In prototyping approaches, observation plays a central role in requirement analysis. Only by observing how users react to prototypes of a new system, the system can be successfully developed. In the traditional approach, observation is not always mandatory. But it is desirable in most instances. The analyst should visit the user site to watch how the work was taking place. The value of observational visits by analyst can be great. Often what the

System Development Life Cycle Methodology 2.17 analyst hears from managers or reads in documents about the system is different from what he observes when watching people at work. Such a surprise visit often helps the analyst in getting a clear picture of the users environment and to determine why a request for a new system was submitted. 2.5.2 Analysis of the Present System : Detailed investigation of the present system involves collecting, organizing and evaluating facts about the system and the environment in which it operates. There should be enough information assembled so that a qualified person can understand the present system without visiting any of the operating departments. Survey of existing methods, procedures, data flow, outputs, files, input and internal controls should he intensive in order to fully understand the present system and its related problems. The following areas should be studied in depth: 1. Review historical aspects : A brief history of the organisation is a logical starting point for an analysis of the present system. The historical facts should identify the major turning points and milestones that have influenced its growth. A review of annual reports can provide an excellent historical perspective. A historical review of the organisation chart can identify the growth of management levels as well as the development of various functional areas and departments. The system analyst should investigate what system changes have occurred in the past. These should include operations that have been successful or unsuccessful with computer equipments and techniques. 2. Analyse inputs: A detailed analysis of present inputs is important since they are basic to the manipulation of data. Source documents are used to capture the originating data for any type of system. The system analyst should be aware of the various sources from where the data are initially captured, keeping in view the fact that outputs for one area may serve as an input for another area. The system analyst must understand the nature of each form, what is contained in it, who prepared it, from where the form is initiated, where it is completed, the distribution of the form and other similar considerations. If the analyst investigates these questions thoroughly, he will be able to determine how these inputs fit into the framework of the present system. 3. Review data files maintained: The analyst should investigate the data files maintained by each department, noting their number and size, where they are located, who uses them and the number of times per given time interval these are used. Information on common data files and their size will be an important factor, which will influence the new information system. This information may be contained in the systems and procedures manuals. The system analyst should also review all on-line and off-line files which are maintained in the organisation as it will reveal information about data that are not contained in any outputs. The related cost of retrieving and processing the data is another important factor that should be considered by the systems analyst.

2.18 Information Systems Control and Audit 4. Review methods, procedures and data communications: Methods and procedures transform input data into useful output. A method is defined as a way of doing something; a procedure is a series of logical steps by which a job is accomplished. A procedure review is an intensive survey of the methods by which each job is accomplished, the equipment utilized and the actual location of the operations. Its basic objective is to eliminate unnecessary tasks or to perceive improvement opportunities in the present information system. A system analyst also needs to review and understand the present data communications used by the organisation. He must review the types of data communication equipments including data interface, data links, modems, dial-up and leased lines and multiplexers. The system analyst must understand how the data-communications network is used in the present system so as to identify the need to revamp the network when the new system is installed. 5. Analyse outputs : The outputs or reports should be scrutinized carefully by the system analysts in order to determine how well they will meet the organisation's needs. The analysts must understand what information is needed and why, who needs it and when and where it is needed. Additional questions concerning the sequence of the data, how often the form reporting it is used, how long it is kept on file, etc. must be investigated. Often many reports are a carry-over from earlier days and have little relevance to current operations. Attempt should be made to eliminate all such reports in the new system. 6. Review internal controls : A detailed investigation of the present information system is not complete until internal control is reviewed. Locating the control points helps the analyst to visualize the essential parts and framework of a system. An examination of the present system of internal controls may indicate weaknesses that should be removed in the new system. The adoption of advanced methods, procedures and equipments might allow much greater control over the data. 7. Model the existing physical system and logical system : As the logic of inputs, methods, procedures, data files, data communications, reports, internal controls and other important items are reviewed and analysed in a top down manner, the process must be properly documented. The logical flow of the present information system may be depicted with the help of system flow charts. The physical flow of the existing system may be shown by employing data flow diagrams (which are discussed in section 2.6.2). The data flow diagrams are drawn after reviewing or developing system flow charts. Each major operation in the system flow charts is broken down into its lowest-level modules and the data flow diagram is drawn for each one of them. During the process of developing the data flow diagram, work on data dictionary (discussed in section 2.6.6) for the new information system should be begun. The data elements needed in the new system will be found in the present system only. Hence, it is wise to start the development of the data dictionary as early as possible. The flow charting and diagramming of present information not only organizes the facts, but also helps disclose gaps and duplication in the data gathered. It allows a thorough comprehension of the numerous details and related problems in the present operation.

System Development Life Cycle Methodology 2.19 8. Undertake overall analysis of present system: Based upon the aforesaid investigation of the present information system, the final phase of the detailed investigation includes the analysis of: a. b. c. the present work volume the current personnel requirements the present benefits and costs Each of these must be investigated thoroughly. 2.5.3 Systems Analysis of Proposed Systems : After each functional area of the present information system has been carefully analysed, the proposed system specifications must be clearly defined. These specifications are determined from the desired objectives setforth at the first stage of the study. Likewise consideration should be given to the strengths and short comings of the present system. The required systems specifications which should be in conformity with the project's objectives are as follows: a. b. c. d. e. Outputs produced with great emphasis on timely managerial reports that utilise the 'management by exception' principle. Database maintained with great accent on online processing capabilities. Input data prepared directly from original source documents for processing by the computer system. Methods and procedures that show the relationship of inputs and outputs to the database, utilizing data communications where deemed appropriate. Work volumes and timings carefully considered for present and future periods including peak periods. The starting point for compiling these specifications is output. After outputs have been determined, it is possible to infer what inputs, database, methods, procedures and data communications must be employed. The output-to-input process is recommended since outputs are related directly to the objectives of the organisation. The future workload of the system must be defined for inputs, database and outputs in terms of average and peak loads, cycles and trends. After completing the various steps mentioned above, the information gathered is documented in the explanatory survey report, which is authorised and signed by the team of system analysts and approved by the user group. This report is then presented to the steering committee. The contents of this report must be as objective as possible to ensure that the best system is selected. Consideration must be given to the fact that the computeroriented system can more readily absorb growth in volume with a slight increase in operating cost.

2.20 2.6 Information Systems Control and Audit SYSTEM DEVELOPMENT TOOLS Many tools and techniques have been developed to improve current information systems and to develop new ones. Such tools help end users and systems analysts to: conceptualise, clarify, document and communicate the activities and resources involved in the organisation and its information systems. analyse present business operations, management decision making and information processing activities of the organisation. Propose and design new or improved information systems to solve business problems or pursue business opportunities that have been identified. Many systems development tools take the form of diagrams and other graphic representations. The major tools used for system development can be grouped into four categories based on the systems features each document has: 1. System components and flows : These tools help the system analysts to document the data flow among the major resources and activities of an information system. System flow charts are typically used to show the flow of data media as they are processed by the hardware devices and manual activities. A data flow diagram uses a few simple symbols to illustrate the flow of data among external entities (such as people or organisations, etc.), processing activities and data storage elements. A system component matrix provides a matrix framework to document the resources used, the activities performed and the information produced by an information system. 2. User interface: Designing the interface between end users and the computer system is a major consideration of a system analyst while designing the new system. Layout forms and screens are used to construct the formats and contents of input/output media and methods. Dialogue flow diagrams analyse the flow of dialogue between computers and people. They document the flows among different display screens generated by alternative end user responses to menus and prompts. 3. Data attributes and relationships : The data resources in information system are defined catalogued and designed by this category of tools. A data dictionary catalogs the description of the attributes (characteristics) of all data elements and their relationships to each other as well as to external systems. Entity-relationship diagrams are used to document the number and type of relationship among the entities in a system. File layout forms document the type, size and names of the data elements in a system. Grid charts help in identifying the use of each type of data element in input/output or storage media of a system. 4. Detailed system process : These tools are used to help the programmer develop detailed procedures and processes required in the design of a computer program. Decision trees and decision tables use a network or tabular form to document the complex conditional logic involved in choosing among the information processing alternatives in a system.

System Development Life Cycle Methodology 2.21 Structure charts document the purpose, structure and hierarchial relationships of the modules in a program. We will now describe some of these tools in detail. (a) Systems flow chart : It is a graphic diagramming tool that documents and communicates the flow of data media and information processing procedures taking place in an information system. This is accomplished by using a variety of labeled symbols connected by arrows to show the sequence of information processing activities. System flow charts typically emphasise the media and hardware used and the processes that take place within an information system. Thus, they represent a graphic model of the physical information system that exists or is proposed. Systems flow charts are widely used to communicate the overall structure and flows of a system to end-users. (b) Data flow diagrams : A data flow diagram (DFD) graphically describes the flow of data within an organisation. It is used to document existing systems and to plan and design new ones. There is no ideal way to develop a DFD; different problems call for different methods. A DFD is composed of four basic elements: data sources and destinations, data flows, transformation processes, and data stores. Each is represented on a DFD by one of the symbols shown in Figure 2. Data Flow Diagram Symbols Symbol Name Explanation Data Sources and The people and organizations that send data to destinations and receive data from the system are represented by square boxes. Data destinations are also referred to as data sinks. Data flows The flow of data into or out of a process is represented by curved or straight lines with arrows. The processes that transform data from inputs to outputs are represented by circles. They are often referred to as bubbles. The storage of data is represented by two horizontal lines. Figure 2 Transformation process Data stores

2.22 Information Systems Control and Audit Basic Data Flow Diagram Elements Data store (H) Data flow (G) Data source (A) Data flow (B) Data flow (D) Data flow (I) Data destination (K) Process (C) Process (F) Data flow (E) Data destination (J) Figure 3 These four symbols are combined to show how data are processed. For example, the DFD in Figure 3 shows that the input to process C is data flow B, which comes from data source A. The outputs of process C are data flows D and E. Data flow E is sent to data destination J. Process F uses data flows D and G as input and produces data flow I and G as output. Data flow G comes from and returns to data store H. Data flow I is sent to data destination K. Figure 4 assigns specific titles to each of the processes depicted in Figure 3. Figures 3 and 4 will be used to examine the four basic elements of a DFD in more detail. Data Flow Diagram of Customer Payment Process Accounts receivable (H) (G) Customer payment (B) 1.0 Process payment (C) Remittance data (D) Receivables Information (I) Credit manager (K) Customer (A) Deposit (E) Bank (J) Figure 4

System Development Life Cycle Methodology 2.23 Data Source and Destinations: A source or destination symbol on the DFD represents an organisation or individual that sends or receives data used or produced by the system. An entity can be both a source and a destination. Data sources and data destinations are represented by squares, as illustrated by items A (customer), J (bank), and K (credit manager) in Figure 4. Data Flows: A data flow represents the flow of data between processes, data stores, and data sources and destinations. Data that pass between data stores and either a data source or a destination must go through some form of data processing- that is, through a transformation process. Data flow arrows are labeled to indicate the type of data being passed. Thus the reader knows exactly what information is flowing; no inferences are required. Data flows are represented in Figure 4 by items B (customer payment), D (remittance data), E (deposit), G (unlabeled; represents information entered into or retrieved from an accounts receivable data file), and I (receivables information). A data flow can consist of one or more pieces of datum. For example, data flow B (customer payment) consists of two parts: a payment and remittance data. Process 1.0 (process payment) splits these two data elements and sends them in different directions. The remittance data (D) flows to another process, where it is used to update accounts receivable records, and the payment (E) is sent to the bank with a deposit slip. Because data flows may be composed of more than one data element, it must be determined whether to show one or more lines. The determining factor is whether the data elements always flow together. For example, if customers sometimes send inquiries about the processing of their payments, the DFD could be revised as shown in Figure 5. The figure shows two lines because customer inquiries, although interacting with the same elements of the DFD, do not always accompany a payment. The two data elements have different purposes, and customer inquiries occur less frequently. If represented by the same data flow, the separate elements would be obscured, and the DFD would be more difficult to interpret. Splitting Customer Payments and Inquiries Customer inquiries (K) (C) Process payment 1.0 Customer (A) Cash receipt (B) Figure 5 Processes: Processes represent the transformation of data. Figure 4 shows that process payment (C) takes the customer payment and splits it into the remittance data and the deposit (which includes the cheques and deposit slip created within process payment). The updating

2.24 Information Systems Control and Audit process (F) takes the remittance data and the accounts receivables data, producing an updated receivables record and sending receivables information to the credit manager. Data Stores: A data store is a temporary or permanent repository of data. DFDs do not show the physical storage medium (disks, paper, and the like) used to store the data. As with the other DFD elements, data store names should be descriptive. As shown in Figure 4, item H, data stores are represented by horizontal lines, with the data stores name recorded inside. Subdividing the DFD : DFDs are subdivided into successively lower levels in order to provide ever-increasing amounts of detail, because few systems can be fully diagrammed on one sheet of paper. Since users have differing needs, a variety of levels can better satisfy these requirements. The highest-level DFD is referred to as a context diagram. A context diagram provides the reader with a summary-level view of a system. It depicts a data processing system as well as the external entities that are the sources and destinations of the systems inputs and outputs. Figure 6 is the context diagram .that Ashwani Sood drew as he was analyzing the payroll processing procedures at a company S & S. It shows that the payroll processing system receives time cards from different departments and employee data from the human resources department. When these data are processed, the system produces (1) Tax reports and payments for governmental agencies, (2) Employee paycheques, (3) A cheque to deposit in the payroll account at the bank, and (4) Management payroll reports. Context Diagram for S & S Payroll Processing ts en ym pa d x Ta o rep rts an Government agencies Departments Time cards Employees paycheques Employees Payroll processing system Bank Human resources Payroll cheque Employee data Pa yr ol l re po rt Management Figure 6

System Development Life Cycle Methodology Table 2: Narrative Description of Payroll Processing at S &S 2.25 When employees are hired, they fill out a new employee form. When a change to an employees payroll status occurs, such as a raise or a change in the number of pay deductions, human resources fills out an employee change form. A copy of these forms is sent to payroll. These forms are used to create or update the records in the employee/payroll file and are then stored in the file. Employee records are stored alphabetically. Some S & S employees are paid a salary, but most are hourly workers who record the times they work on time cards. At the end of each pay period, department managers send the time cards to the payroll department. The payroll clerk uses the time card data, data from the employee file (such as pay rate and annual salary), and the appropriate tax tables to prepare a twopart payroll register showing gross pay, deductions, and net pay for each employee. The clerk updates the employee file to reflect each employees current earnings. The original copy of the employee paycheques is forwarded to Mrs. Suman Sharma. The payroll register is forwarded to the accounts payable clerk. The time cards and the duplicate copies of the payroll register and paychecks are stored by date in the payroll file. Every pay period the payroll clerk uses the data in the employee/payroll file to prepare a payroll summary report for Mrs. Suman Sharma so that she can control and monitor labor expenses. This report is forward to her along with the original copies of the employee paycheques. Every month the payroll clerk uses the data in the employee/payroll file to prepare a two-part tax report. The original is forwarded to the accounts payable clerk, and the duplicate is added to the tax records in the payroll file. The accounts payable clerk uses the tax report to prepare a two part cheque for taxes and a two-part cash disbursements voucher. The tax report and the original copy of each document are forwarded to Mrs. Suman Sharma. The duplicates are stored by date in the accounts payable file. The accounts payable clerk uses the payroll register to prepare a two part cheque for the total amount of the employee payroll and a two-part disbursements voucher. The original copy of each document is forwarded to Mrs. Suman Sharma, and the payroll register and the duplicates are stored by date in the accounts payable file. Mrs. Suman Sharma reviews each packet of information she receives and approves and signs the cheques. She forwards the cash disbursement vouchers to Ashwani, the tax reports and payments to the appropriate governmental agency, the payroll cheque to the bank, and the employee checks to the employees. She files the payroll report chronologically. Ashwani also wants to diagram the details of the system. To do so, he decides to decompose the context diagram into successively lower levels, each with an increasing amount of detail. In preparation for this task, he wrote the narrative description of S& Ss payroll processing procedures contained in Table 2. If we read this description, the following can be determined:

2.26 Information Systems Control and Audit The number of major data processing activities involved The data inputs and outputs of each activity (ignoring all references to people, departments, and document destinations) Based on Ashwanis description, approximately five data processing activities can be identified. The first is updating of the employee/payroll master file (first paragraph of the narrative). The second is employee compensation (second, fifth, and sixth paragraphs). This activity can be broken out into smaller parts in a lower-level DFD. Third is the generation of management reports (third paragraph). Fourth is the payment of taxes (fourth paragraph). Fifth is posting entries to the general ledger (last paragraph). All the data inflows and outflows, as well as the five activities form the basis of the DFD and are summarized in Table 3. Table 3: Activities and Data Flows in Payroll Processing at S & S Activities Update employee/roll file Data Inputs New employee form Employee change form Employee/payroll file Pay employees Time cards Employee/ payroll file Tax tables Employee cheques Payroll register Updated employee/payroll file Payroll cheques Payroll cash voucher Prepare reports Pay taxes Employee/ payroll file Employee/ payroll file Payroll report Tax report Tax payment Payroll tax cash disbursements voucher Updated employee/payroll file Update general ledger Payroll tax cash Disbursements voucher Payroll cash Disbursements voucher Updated general ledger disbursements Data Outputs Updated employee/ payroll file

System Development Life Cycle Methodology 2.27 Using this information, Ashwani exploded his context diagram and created the DFD shown in Figure 7. The data coming from the human resources department were grouped together and called Employee data. Notice that some data inputs and outputs have been excluded from this DFD. For example, in process 2.0 the data inflows and outflows that are not related to an external entity or to another process are not depicted (tax tables and payroll register in this case). These data flows are internal to the Pay employees activity and are shown on the next DFD level. Not fully satisfied with the level of detail he had captured, Ashwani exploded process 2.0 (pay employees). Figure 8 provides more detail about the data processes involved in paying employees, and it includes the tax tables and the payroll register data flow left out of Figure 7. In a similar fashion, each of the processes shown in Figure 7 could be exploded to show a greater level of detail. DFD for S & S Payroll Processing Employee cheques Departments Human Employee data resources Time cards 2.0 Pay employees Payroll cheque Bank Payroll disbursement voucher 1.0 Update employee/ payroll master file Employee/payroll file Payroll disbursement voucher 5.0 update general ledger General Ledger 3.0 Prepare reports 4.0 Pay taxes Payroll report Tax reports and cheque Management Governmental agencies Figure 7

2.28 Information Systems Control and Audit DFD for Process 2.0 in S & S Payroll Processing Tax rates Time cards Employees 2.1 Process Payroll Pay Em p loy es h eq u ee c r che vou roll reg i st e r 2.2 Prepare cash disbursements s bur dis oll r Pay e nt me Employee/payroll master file Pay rol l ch Bank eq u e Figure 8 (c) Layout forms and screens: These consist of electronic displays or preprinted forms on which the size and placement of titles, heading, data and information can be designed. Layout forms and screens are used to design source documents, input/output and storage records, files and output displays and reports. 4GL packages, CASE tools and other software packages for computer-aided development of information systems provide electronic version of layout forms. For example, screen generator package of CASE tools helps in designing prototype of inter-related data entry screens and management reporting displays along with the end user/computer dialogue that links them together. Figure 9 illustrates a layout screen for the design of a display for a customer order report. CUSTOMER ORDER REPORT DATE MM/DD/YY ORDER NUMBER CUSTOMER NAME CATALOG NUMBER XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX 3 Exit 1.8 Column 9999 XXXXXXXXXXXXXXXXXXXXXXX AVAILABLE LOCATION X X X X X X 8 Repeat 10 Field Figure 9 XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX COST 999.99 999.99 999.99 999.99 999.99 999.99 STOCK LEVEL 99999 99999 99999 99999 99999 99999

Hardware resources Software resources Programs Procedures Data entry procedures Computer operators Sales clerks Managers Customer, inventory and sales databases Sales clerks Customers Customer Data entry data displays Product data Processing status displays Data entry program Specialists Users Data Resources Information products People resources Media Bar tags Mag stripe cards Sales processing program, Sales analysis program Sales Clerks Managers Customers Sales transaction procedures Information system activities Machines Input POS terminals Processing Mainframe Computer Output Paper reports POS and receipts terminals, Management workstations Report generator program, Graphic program Output use and distribution procedures Computer operators Magnetic disk packs Database management system program Correction procedures Sales receipts Sales analysis reports and displays Storage Magnetic disk drives Customer, inventory and sales databases System Development Life Cycle Methodology Control POS terminals, Management workstations Paper documents and control reports Performance monitor program, Security monitor program Computer operators Control clerks Sales clerks Managers Customers Customer, inventory and sales database Data entry displays, sales receipts, Error displays and signals

Figure 10 : An example of a system component matrix for a sales processing and analysis system. Note how it emphasises the basic activities needed, resources used and products produced by this information system. 2.29

2.30 Information Systems Control and Audit (d) System components matrix : The system components matrix can be used as an information system framework for both systems analysis and system design. It views the information system as a matrix of components that highlights how the basic activities of input, processing, output, storage and controls are accomplished in an information system, and how the use of hardware, software and people resources can convert data resources into information products. It poses a fundamental question that should be answered in the system development process such as What information system resources are needed to accomplish the processing activities that can produce the reports required by end users? Figure 10 illustrate the use of a system component matrix to document the basic components of a sales processing and analysis system in an organisation. It spotlights the basic information processing activities needed in the organisation, the resources used and products produced by this system. Filling all of the cells in the matrix is not necessary because information for each cell may not be available or applicable. However, duplicate cell entries can be made because many systems resources and products are used to support more than one system activity. (e) CASE Tools : The data flow diagram and system flow charts that users review are commonly generated by systems developers using the on-screen drawing modules found in CASE (Computer-Aided-Software Engineering) software packages. CASE refers to the automation of any thing that humans do to develop systems. In 1980s, these tools enabled system analysts and programmers to create flow charts and data flow diagrams on a mini computer or a micro computer workstation. Today, CASE products can support virtually all phases of traditional system development process. For example, these packages can be used to create complete and internally consistent requirements specifications with graphic generators and specifications languages. CASE products are still relatively new and evolving. However numerous organisations have already reported great success with them. (f) Data Dictionary : A data dictionary is a computer file that contains descriptive information about the data items in the files of a business information system (Figure 11). Thus, a data dictionary is a computer file about data. Each computer record of a data dictionary contains information about a single data item used in a business information system. This information may include: 1. 2. 3. 4. 5. Codes describing the data items length (in characters), data type (alphabetic, numeric, alphanumeric, etc.), and range (e.g., values from 1 to 99 for a department code) The identity of the source document(s) used to create the data item. The names of the computer files that store the data item. The names of the computer programs that modify the data item. The identity of the computer programs or individuals permitted to access the data item for

System Development Life Cycle Methodology the purpose of file maintenance, upkeep, or inquiry. 6. 2.31 The identity of the computer programs or individuals not permitted to access the data item. As new data fields are added to the record structure of a business file (e.g., adding a reorder quantity field to the inventory record of Figure 11), information about each new data item is used to create a new computer record in the data dictionary. Similarly, when new computer programs are created those access data items in existing files, the data dictionary is updated to indicate the data items these new programs access. Finally, when data fields are deleted from the structure of file records, their corresponding records in the data dictionary are dropped. Data dictionaries have a variety of uses. One is as a documentation aid to programmers and system analysts, who study, correct, or enhance either the database or the computer programs that access it. As suggested in points 5 and 6 in the previous list, a data dictionary is also useful for file security e.g., to prohibit certain employees from gaining access to sensitive payroll data. A sample record from a data dictionary. A data dictionary is basically a file about data. Each file record contains information about one data field used in other files. Name of data field Inventory quantity on hand File in which stored Inventory master file Source document Form number ABC 123 Size in bytes Type 4 Numeric Data dictionary Figure 11 Accountants and auditors can also make good use of a data dictionary. For example, a data dictionary can help establish an audit trail because it can identify the input sources of data items, the computer programs that modify particular data items, and the managerial reports on which the data items are output. When an accountant is participating in the design of a new system, a data dictionary can also be used to plan the flow of transaction data through the system. Finally, a data dictionary can serve as an important aid when investigating or documenting internal control procedures. This is because the details about edit tests, methods of file security, and similar information can be stored in the dictionary (These controls are discussed in Chapter 3). 2.7 STAGE III : SYSTEMS DESIGN After the completion of requirements analysis for a system, systems design activity takes place for the alternative which is selected by management. The system design phase usually consists of following three activities:

2.32 (i) Information Systems Control and Audit Reviewing the system's informational and functional requirements; (ii) Developing a model of the new system, including logical and physical specifications of outputs, inputs, processing, storage, procedures and personnel; (iii) Reporting results to management. The systems design must conform to the purpose, scale and general concepts of the system that management approved during the requirements analysis phase. Therefore, users and system analysts must review each of these matters again before starting the design because they establish both the direction and the constraints that system developers must follow during rest of the activities. As mentioned above, system design involves first logical design and then physical construction of a system. When analysts formulate a logical design, they write the detailed specifications for the new system, they describe its features; the outputs, input files, databases and procedures, all in a manner that meets systems requirements. The statement of these features is termed as the design specifications of the system. The logical design of an information system is like an engineering blueprint; it shows major features of the system and how they are related to one another. The reports and outputs of the system are like the engineer's design components. Data and procedures are linked together to produce a working system. Physical construction, the activity following logical design, produces program software, files and a working system. Design specifications instruct programmers about what the system should do. The programmers, in turn, write the programs that accept input from users, process data, produce the reports, and store data in the files. Developing a model for a new system: When designing a system, the systems analysts and systems development team determine how both manual and software/hardware components will be realised at logical and physical levels in each of the following areas: (i) Output, (ii) Input, (iii) Processing, (iv) Storage, (v) Procedures and (vi) Personnel . 2.7.1 Designing system outputs : The term output applies to any information produced by an information system, whether printed or displayed. System output may be a report, a document or a message. When analysts design computer output, they identify the specific output that is needed to meet the information requirements, select methods for presenting information, create documents, reports or other formats that contain information produced by the system. One of the most important features of an information system for users is the output it produces. Without quality output, the entire system may appear to be so unnecessary that users will avoid using it possibly causing it to fail. We will now discuss how to design the output that a computer information system will produce. Designing computer output should proceed in an organised, well thought out manner. The right output must be developed while ensuring that each output element is designed so that users will find the system easy to use effectively.

System Development Life Cycle Methodology 2.33 Output objectives: The output from an information system should accomplish one or more of the following objectives : 1. 2. 3. 4. Convey information about past activities, current status or projections of the future. Signal important events, opportunities, problems or warnings. Trigger an action. Confirmation of an action. Good systems output design cannot be developed independent of the uses of the output. In other words, aesthetically attractive output or even output that uses innovative computer technology cannot be classified as good unless it meets the needs of the organisation and its users. The design process itself begins when the system analyst identifies the output, which the system must produce, that is, during the requirements phase. In application prototyping, analysts often develop display screen output to allow users to react to both the content and form of the output, taking into consideration how they will use it. Similarly, under the structured analysis development method, data flow diagrams prepared earlier in the development process focus their attention on the nature of the output needed. Important factors in output design : There are six important factors which should be considered by the system analyst while designing user outputs; these are: content, form, volume, timeliness, media and format. We will now discuss, in brief, various issues relating to above factors which should be kept in mind. (i) Content : Content refers to the actual pieces of data included among the outputs provided to users. For example, the contents of a weekly report to a sales manager might consist of sales person's name, sales calls made by each sales person during the week, and the amount of each product sold by each salesperson to each major client category. It is to be noted here that systems designers generally put too much content into managerial reports instead of too little. Too much content can cause managers to waste time in isolating the information that they need; it also diminishes the impact of truly important information. Hence, only the required information should be included in various outputs. (ii) Form : Form refers to the way that content is presented to users. Content can be presented in various forms; quantitative, non-quantitative, text, graphics, video and audio. For example, information on distribution channels may be more understandable to the concerned manager if it is presented in the form of a map, with dots representing individual outlets for stores. Various department managers often prefer both summary and detailed information to be presented in relative terms or in chart form such as a pie chart, line chart or bar chart rather than information in absolute terms. Sometimes, converting absolute values to relative values such as percentages often help managers to comprehend the data easily and make better decisions. Hence, the form of the output should be decided keeping in view the requirements for the concerned user. (iii) Output volume : The amount of data output required at any one time is known as output volume. It is better to use high-speed printer or a rapid-retrieval display unit, which are fast

2.34 Information Systems Control and Audit and frequently used output devices in case the volume is heavy. Unusually heavy output volume normally causes concern about paper cost. In such a case, alternative methods of output display such as COM (Computer Output Microfiche) may be considered. (iv) Timeliness : Timeliness refer to when users need outputs. Some outputs are required on a regular, periodic basis - perhaps daily, weekly, monthly, at the end of a quarter or annually. Other types of outputs are generated on request. A sales manager, for example, may be requiring a weekly sales report. Other users, such as airline agents, require both real- time information and rapid response times in order to render better client service. Hence, the system designer might require that display information be provided to the airline agents within a few seconds at least 95% of the time. Communications-oriented and real-time systems are often the solution for such situations. In decision support systems and management reporting system environments, user-oriented 4GL tools are particularly effective. These tools provide both users and programmers with a time-sensitive alternative to the mounting application backlog that troubles many organisations. (v) Media: Input-output medium refers to the physical device used for input, storage or output. A variety of output media are available in the market these days which include paper, video display, microfilm, magnetic tape/disk and voice output. Many of these media are available in different forms. The system designer can select a medium, which is best suited to the user requirements. (vi) Format : The manner in which data are physically arranged is referred to as format. This arrangement is called output format when referring to data output on a printed report or on a display screen. Traditionally, when formatting the printed report for managers or users, a design tool called a printer spacing chart (as shown in figure 12) is used. On the chart, titles, headings, columns of data and other types of report elements are set up in the manner desired by the user. Many prototyping fourth generation languages available with application generators today enable the printer spacing chart task to be performed automatically at a display workstation. A prototyping 4GL develops report prototypes quickly. For instance, in MS-ACCESS, as the operator fills in report-formatting choices on a series of pull down menus, a mock up of the report appears on the bottom half of the screen as shown in the figure13. Besides the time saved in finalising formats, a major advantage of using these 4GL tools is that once the mock up is complete, the programming code can also be generated automatically by them. Thus, the real issue in designing computer output is not how much can be provided, but how little is needed to make important information available. The major concern of the user in the system design effort is properly designed output, that is, intelligent and decision impelling. If, therefore, the output design is poor the entire system developed is likely to be jeopardized. Once the output report, the formats and contents have been fixed, the system analyst can work backward and devise the inputs and master file layouts as also the computations to be performed to derive the figures in the output reports.

0 10 20 30 40 50 60 70 80 DA T E : XX S O F T WA R E D I V I S I O N SA L ES R E POR T J A N UA R Y SA LES P R O D U C T D E S CR I P T I O N I N UN I T S 20 02 XX XX PA G E 9 99 System Development Life Cycle Methodology Figure 12 9 , 999 9 , 999 9 , 999 P R OD U C T UN I T PR I CE SAL E S I N RU P E E S C OD E XXXX 99 . 99 99 . 99 99 . 99 999. 99 999. 99 999. 99 XXXX

XXXX Figure 1 : Partial printer spacing chart. This traditional formatting tool enables systems developers to describe the format of printed reports needed by the managers of users. 2.35

2.36 Information Systems Control and Audit Creating a report mock-up with MS-Access. The report format shown in the bottom part of the screen is developed by making successive choices from the menu template in the top part of the screen. Options Groups Contents Heading Width Decimal Places Total this column Columns Locate PRODUCT 20 Exit 04 : 43 : 15 am PRODUCT NAME Report Format >>>>>> XXXXXXXXXXXXXXXXXXXX CREATE REPORT (A:) B : SALES.FRM COLUMN 1 , Caps Enter column heading. Exit-Ctrl-End. Enter up to four lines of text to display above the indicated column. Figure 13 Format of information reports for the users should be so devised that it assists in decisionmaking, identifying and solving problems, planning and initiating corrective action and searching. For adhoc reports required on demand (usually by the top management) it is not a bad idea to supplement the computer print out with summarisation by means of diagrams, curves, histograms, graphs etc. In order that reports are readily comprehensible, codes and abbreviations should be avoided. Reports should preferably be supplied on an exception basis to save the managers from overload of information. Occasionally, reports may be required in entirety, for example, for auditors in which case significant divergences, or slippages or variances can be highlighted by means of printed asterisks. Only those analyses that are relevant to decision making should be provided in the reports.

System Development Life Cycle Methodology 2.37 For design of the output, collaboration between the users (executives) and system analysts is of great importance. The latter know the computer capabilities in data and symbol manipulation and printing/display, the former know what they need. The reports collected during the systems analysis phase can now be subjected to a close scrutiny for their validity. In most organisations, usually 10% to 30% of the reports do not serve any purpose and they are merely a carry over from some past events. Thus, elimination of such reports is called for. Some of these can be discontinued as an experimentation and if no one demands them they should be abandoned. It is also desirable to merge two or more reports where possible. It is also to be ascertained if the cost of a report is justified by the benefit. The cost factor is somewhat easy to establish. In fact, assessment of benefits is very subjective and their conversion to objective unit of measurement is very difficult. 2.7.1.1 Designing printed output : We will now examine how to design a printed output layout. An output layout is the arrangement of items on the output medium. When analysts design the output layout, they are building a mock-up of the actual report or document, as it will appear after the system is in operation. The layout should show the location and position of all variable information such as item details, summaries and totals, control breaks and all pre-printed details such as headings, documents names and titles, corporate names and addresses, and instruction, notes and comments. The layout is a blue print that will guide the construction of programs later in the development process. To begin the design of a layout, it is necessary to determine what items will be included in the report. The requirement analysis phase provides this information, and the data dictionary contains necessary descriptive information such as data item type and length including desired editing formats. Reports layout can be formed using layout screens, perhaps, with a CASE or other automated tools or manually using paper layout forms. There are certain guidelines, which should be followed while preparing the layout form. It will not only make the analyst's job easier, but will also ensure that users will receive an understandable report. Some of these guidelines are summarised below: 1. 2. 3. Reports and documents should be designed to read from left to right and top to bottom. The most important items should be easiest to find. Each printed report should include the heading or title of the report, page number, date of preparation and column headings. The heading or title of the report orients the user to what it is they are reading. The title should be descriptive, yet concise. Each page should be numbered so that the user has an easy point of reference when discussing output with others or relocating important figures. The date of report preparation should be included on each print out. Sometimes this helps users to estimate the value of the output. Column headings serve to further orient the user as to the report contents. Each data item must have a heading, which should be short and descriptive. Data items 4.

2.38 Information Systems Control and Audit that are related to one another should be grouped together on the report. 5. Control breaks should be used in the report to help readability. They should be separated from the rest of data with additional lines. Attention should be drawn to control breaks summaries and other important information by boxing them off with special characters such as asterisks or extra space. This makes it easier to find critical information. Sufficient margin should be left on the right and left as well as top and bottom of an output report. This enables the user to focus his attention on the material centered on the page and makes reading easier. The detail line for variable data should be defined by indicating whether each space is to be used for an alphabetic, special or numeric character. The mock up reports should be reviewed with users and programmers for feasibility, usefulness, readability, understandability and an esthetic appeal. 6. 7. 8. 2.7.1.2 Designing visual display output : Many of the principles of good design discussed for printed output also apply to output that is shown on work-stations or video display terminals. However, it should be noted that a visual display terminal offers less space to work with compared to most printed outputs. Moreover, the system analyst is also required to give instructions to the user on how to use the display unit. Layout of display screen : Each display page is commonly called a screen or panel. Its lay out will ease or impede its use. Designing a layout begins with verifying the characteristics of the display screen. These include: (i) (ii) Physical dimensions of the screen; Number of rows and columns of data that can be displayed; (iii) Degree of resolution (high, medium, low); (iv) Number of colours available (for example, monochrome, three colours, eight-colours etc.); (v) Methods of highlighting (underline, bold, blinking, alternate intensities); (vi) Methods of intensity control (high/low; normal inverse). Visual display screens typically have 80 columns with 24 or 25 lines. Point-of-sale displays and some portable computers have smaller dimensions. Screen design begins

INVENTORY ON HAND REPORT AMOUNT ON ORDER ON BACK ORDER Item Number DESCRIPTION 999999 999999 999999 UNIT STOCK MIN. ON CLASS BALANCE HAND AMOUNT ALLOCATED 99999999 99999999 99999999 | | (1) | | 99999999 99999999 99999999 (5) 999999 999999 999999 999999 999999 999999 | | (6) | | 999999 999999 999999 999999 999999 999999 | | (8) | | 999999 999999 999999 999999 999999 999999 | | (9) | | 999999 999999 999999 999999 999999 999999 | | (7) | | 999999 999999 999999 XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX | | (2) | | XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXX XXXX XXXX | | (3) | | XXXX XXXX XXXX XX XX XX | | (4) | | XX XX XX 999999.99 999999.99 999999.99 | | (10) | | 999999.99 999999.99 999999.99 System Development Life Cycle Methodology Figure 14 XXX SUMMARY XXX STOCK CLASS XX XX | | (4) | | XX XX 999999 999999 | | (11) | | 999999 999999 999999 999999 | | (12) | | 999999 999999 999999 999999 | | (13) | | 999999 999999 999999 (16) 999999 (17) 999999 (15) TOTAL VALUE ON HAND VALUE ALLOCATED VALUE ON ORDER 999999 999999 | | (14) | | 999999 999999 999999 (18) VALUE BACK-ORDER with the recognition that the screen is composed of different areas. Layout tools assist the analyst in specifying the contents of single or multiple design formats. Figure 4 2.39

2.40 Information Systems Control and Audit It is helpful to divide the display screens into sections that are consistently used in the same way to present information, identifications and messages to the user. In designing output screens, we need areas for (i) headings and titles, (ii) content of the display, (iii) messages and instructions and (iv) sometimes explanations for the information in the report. Figure -5 shows a good placement of this information on the screen. The headings and titles are positioned at the top portion of the screen, messages and instructions at the bottom, and explanations if needed, on the right-hand side. If only a very small amount of information is to be presented, it can be placed in the centre of the screen or in the upper left quadrant. However, it is mainly a matter of preference of the concerned system analysts. 2.7.1.3 Designing of Windows: In computer output, windows are sub-divisions of the display Status line Main window 30 column flag window 80 column window Esc to screen formats menu Figure 5 Figure 15 screen that make it possible to present different sets of output simultaneously. Users can run several programs at the same time (referred to as multi-tasking), displaying the output from each in an individual window. Or, a single program can present more than one output simultaneously. Windowing Capability: Depending on the details of the specific system, it may be possible to reposition windows on the display screen. Users may also want the capability to change the size of the window (say, to increase the one with the most information) or to hide windows that are not needed at a particular moment. Overlapping allows users to move information to the foreground when it is needed and to replace it again with other information, to overlap it i.e. an advantage that enables using a large portion of the display screen without giving up the flexibility offered by windowing. These capabilities must be provided through the computer operating system. Thus, the system analyst should discuss the feature, if it exists in the software, with the user as it applies to the application under development. The use of windows should be considered when the applications are required to be improved by the following abilities: Display different data or report sets simultaneously.

System Development Life Cycle Methodology Switch between several programs, alternatively displaying the output from each. 2.41 Move information from one window to the other (within the same or different programs). Allow individual users to reposition the information on a display screen to suit their unique needs. 2.7.2 Designing systems inputs : Input design consists of developing specifications and procedures for data preparation, developing steps which are necessary to put transactions data into a usable form for processing, and data-entry, i.e., the activity of putting the data into the computer for processing. A starting point for the input design process is a review of the information compiled during the requirement analysis phase. The analyst must review facts related to the current system such as what data are entered, who enters them, where they are entered, and when they are entered. This review highlights basic problems and difficulties with the present system. An understanding of the present system's input directs attention to those areas needing improvement for more efficient data entry. Among the input issues to consider for design of input specifications are content, timeliness, media, format and volume. Many of the issues involved in input are also similar to those of output as discussed briefly below. a. Content: The analyst is required to consider the types of data that are needed to be gathered to generate the desired user outputs. This can be quite complicated because new systems often mean new information and new information often requires new sources of data, Sometimes, the data needed for a new system are not available within the organisation. Hence, the system designer has to prepare new documents for collecting such information. b. Timeliness: In data processing, it is very important that data is inputted to computer in time because outputs cannot be produced until certain inputs are available. Hence, a plan must be established regarding when different types of inputs will enter the system. In transaction data processing, the people needing output are not the same who input most of the data. Hence, timeliness of input becomes more relevant for such systems. c. Media : Another important input consideration includes the choice of input media and subsequently the devices on which to enter the data. Various user input alternatives available in the market include display workstations, magnetic tapes, magnetic disks, key-boards, optical character recognition, pen-based computers and voice input etc. A suitable medium may be selected depending on the application to be computerised. d. Format : After the data contents and media requirements are determined, input formats are considered. While specifying the record formats, for instance, the type and length of each data field as well as any other special characteristics (number decimal places etc.) must be defined. Figure 6 shows how this process can be performed with an application generator. However, designing input formats in mainframe and mini-computer database environments often requires the assistance of a professional programmer or database administrator.

2.42 Information Systems Control and Audit e. Input volume : Input volume refers to the amount of data that has to be entered in the computer system at any one time. In some decision-support systems and many real-time transaction processing systems, input volume is light. In batch-oriented transaction processing systems, input volume could be heavy which involves thousands of records that are handled by a centralised data entry department using key-to-tape or key-to-disk systems. 2.7.2.1 Capturing data for input : The quality of system inputs determines the quality of system output. It is vital that input forms and screens be designed with this critical relationship in mind. Well-designed input forms and visual display terminal screens should meet the objectives of effectiveness, accuracy, ease of use, consistency, simplicity and attractiveness. All these objectives can be attained if the analyst keeps in mind the basic design principles, knowledge of what is needed as input for the system, and an understanding of how users respond to different elements of forms and screens. 2.7.2.2 Form design : Forms are pre-printed papers that require people to fill in responses in a standardised way. Forms elicit and capture information required by organisational members that often will be input to the computer. Through this process, forms often serve as source documents for the data entry personnel. Guidelines for form design: The following guidelines for form design should be observed in order to design useful forms. 1. Making forms easy to fill: To reduce errors, speed-up completion and facilitate entry of data, it is essential that forms should be easy to fill out. This can be achieved by considering the following factors: a. Form flow: Designing a form with proper flow can minimise time and effort expended by employees in a form completion. Forms should flow from left to right and top to bottom. Illogical flow takes extra time and can be frustrating for the user. A form that requires people to go directly to the bottom of the form and then skip back to the top for completion exhibits poor flow. b. Divide forms in logical sections: The second technique that makes it easy for people to fill out forms correctly is logical grouping of information. A good form consists of seven main sections, namely (i) headings, (ii) identification and access, (iii) instructions, (iv) body (v) signature and verification (vi) totals and (vii) comments.

System Development Life Cycle Methodology 2.43 CURSOR Char : Word : Home End Pan : Field Name 1 2 3 4 5 6 7 CUSTOMER NAME STREET CITY STATE PIN-CODE Type INSERT Char : Ins. Word : ^N Help : F1 Width 3 30 30 30 2 6 DELETE Char : Del. ^Y Word : Field : ^U Dec. Field Name Up a field Down a field Exit/Save : Abort : Type Width Dec. Character Character Character Character Character Numeric (a) Defining fields width for records in a file. From this seven-field data defination, the applications generator produces the template in (b) CURSOR Char : Word : Home End UP DOWN Field Page : Pg Up Pg Dn Help : F1 DELETE Char : Del. Field : ^Y Record : ^U INSERT MODE Ins. Exit/Save : ^End Abort : Esc Memo : ^ Home 123456 CUSTOMER NAME STREET CITY STATE PIN-CODE (b) A blank template. The user creates records by typing data into the shaded areas. CURSOR Char : Word : Home End UP DOWN Field Page : Pg Up Pg Dn Help : F1 DELETE Char : Del. Field : ^Y Record : ^U INSERT MODE Ins. Exit/Save : ^End Abort : Esc Memo : ^ Home 123456 CUSTOMER NAME STREET CITY STATE PIN-CODE 101 Mr. XYZ 22 Straw bridge Mumbai MH 400045 Figure 16 (c) A filled-in template for the first record. When the last data field (PIN CODE) is supplied data, the record is automatically saved and new template appears on-screen.

2.44 Information Systems Control and Audit Ideally, these sections should appear on a page grouped as they are shown in the figure-17 below. Notice that the seven sections cover basic information required on most forms. The top quarter of the form is devoted to three sections: the heading, the identification and access section and the instruction section. The heading section includes the name and address of the business originating the form. The identification and access section includes codes that may be used to fill the report and gain access to it at a later date. The middle of the form is its body, which composes approximately half of the form. This is the part of the form that requires the most detail and development from the person completing it. The bottom quarter of the form is composed of three sections : signature and verification, totals and comments. Seven sections found in well-designed forms HEADING INSTRUCTIONS BODY SIGNATURE AND VERIFICATION COMMENTS Figure 17 IDENTIFICATION AND ACCESS TOTALS c Captioning: Clear captioning is yet another technique that can make easy work of filling up the form. Captions tell the persons completing the forms what to put on a blank line, space or box. 2. Meeting the intended purpose: Forms are created to serve one or more purposes in the recording, processing, storing and retrieving of information for various businesses. Sometimes, it is desirable to provide different information to different departments or users while still sharing some basic information. This is where speciality forms are useful. The analyst can his imagination to design such forms which can provide the information required by different departments while avoiding duplication of information. 3. Ensuring accurate completion : Error rates typically associated with collecting data can drop sharply when forms are designed to assure accurate completion. Design is important in making people to do the right thing with the form. Various controls can be embedded in the form design. For example, the form design can provide an internal double check with column totals and row totals, summing to the same number. If the row and column totals do not sum to

System Development Life Cycle Methodology 2.45 the same number, the employee filling out the form knows that there is a problem and can correct it on the spot. 4. Keeping forms attractive: An aesthetic form draws people into it and encourages proper completion. This means that people who fill out the forms will be more satisfied and that the forms will be completed. Thus, forms should look uncluttered, organised and logical even after they are filled in. Providing enough space for typewriter or for underlining responses will help in this regard. To be attractive, forms should elicit information in the expected order: convention dictates asking for name, address, city, state and pin code in this order. Proper layout and flow contribute to a form's attractiveness. Using different fonts for type within the same form can help in making it attractive for the user. Separate categories and subcategories with thick and thin lines can also encourage interest in the form. Type fonts and lines weights are useful design elements for capturing attention and forcing people to fill in the form correctly. 2.7.2.3 Coding methods : Information systems projects are designed with space, time and cost saving in mind. Hence, coding methods in which conditions, words or relationships are expressed by a code are developed to reduce input, control errors and to speed up the entire process. A code is a brief number, title or symbol used instead of lengthy or ambiguous description. Descriptions are particularly unsuited for computerised applications. They are usually far too long and would require much higher computer time for processing than the codes. Therefore, when an event occurs, the details of the event are summarised by the code. With code, fewer details are necessary in input but it results in no loss of information. The system analyst is responsible for devising an appropriate coding scheme. Although there exist coding schemes in manual systems also, it is usually necessary to modify these to suit computer capabilities, since human beings can manage with bad and disorganised coding schemes but not the computer. Some of the desired characteristics of a good coding scheme are enumerated below: (i) Individuality : The code must identify each object in a set uniquely and with absolute precision. To use one code number for several objects in a set would obviously cause a great deal of confusion. Furthermore, the code should he universally used over the entire organization. (ii) Space: As far as possible a code number must be much briefer than description. (iii) Convenience : The formats of code numbers should facilitate their use by people. This implies that the code number should be short and simple and consist of digits and or upper case alphabets. It is better to avoid the use of such special symbols as hyphens, oblique, dot, etc. (iv) Expandability : As far as possible future growth in the number of objects in a set should be provided for. Therefore, whilst introducing the scheme, longer number of digits/number than necessary at present may be adopted as the code length.

2.46 Information Systems Control and Audit Related items must use fundamentally similar numbers. As an example, the pattern number, the casting number and the finished part number of a component at various stages of processing should have code numbers which mostly resemble but for a digits/letters alteration to suggest whether it is a pattern, casting or finished part. This is quite convenient when, for example, cross indexing which casting has to be ordered on the boundary for a particular part. (v) Suggestiveness : The logic of the coding scheme should be readily understandable. Also, the letter or number should be suggestive of the item characteristics e.g., whether it made from a casting or rolled stock, whether it pertains specifically to such and such model or it is used commonly by more than one end product. But this should not be carried too far in lengthening the code since it would defeat the purpose of brevity. (vi) Permanence : Changing circumstances should not invalidate the scheme or invalidation in the future should be kept to minimal. 2.7.2.4 Designing efficient data entry : Assuring the quality of data input to the information system is critical to assure quality output. The quality of data entered can be improved through attainment of the three major data entry objects: these are, effective and efficient data capture, effective coding and appropriate data-entry methods. As has been discussed earlier, a well designed form to serve as a source document is the first step towards effective data entry. A second way to speed up data entry is through effective use of coding, which puts data in short sequences. Finally, effective data entry can be achieved by giving attention to the input devices being used. Data can be input through many different methods, each with varying speed and reliability. Efficiency improvement on key-to-tape has been realized through the invention of key-to-disk and key-to-floppy diskette systems. Optical Character Recognition (OCR) allows reading of input data through use of a special machine, which eliminates the process of transcription of source data into machine-readable form and also requires simple employee skills. Other data entry methods include magnetic ink character recognition used by banks to encode, customer accounts number, mark-sense form used for high volume data entry etc. Bar codes (applied to products and then scanned) also speed up data entry and improve data accuracy and reliability. Intelligent terminals are input devices with a visual display terminal, keyboard and a communication link to the CPU. They permit transactions to be entered and completed in real time. Along with appropriate coding, data capture and input devices, accurate data entry can be enhanced through the use of input validation. The systems analyst must assume that errors in data will occur and hence he must work with users in designing input validation test to prevent erroneous data from being processed and stored. Input transactions should be checked to assure that the transaction requested is acceptable, authorized and correct. Input data can be validated through inclusion in the software of several types of test that check for missing data, length of data item, range and reasonableness of data and invalid values of data. (These checks/controls are discussed in detail in study paper) The systems analyst must design the

System Development Life Cycle Methodology appropriate checks after consulting the users and managers of the organisations. 2.47 2.7.3 Data Storage: Storing data is often an important decision in the design of an information system. There are two approaches for storing data. The first approach is to store data in individual files, one file for each application. The second approach is to develop a data base that can be shared by many users for a variety of applications as need arises. The conventional file approach may at times be a more efficient approach since the file can be application oriented. On the other hand, the data base approach may be more appropriate because the same data need to be entered, stored and updated once. Examples of conventional files include master files, table files, transaction files, work files, and report files. They can have a sequential organization, random or direct organization, indexed organization, or indexed-sequential organization. These are the most effective ways of organizing and storing data in transaction systems where each transaction is processed to update a record in the master file. However, when the purpose of the information system is to support management decision-making and same data is used in multiple applications, the analyst may find that these methods of file organization are inadequate and he may have to adopt data base approach. Although systems analysts do not design database, a separate database management staff oversees the design and development of the database. However, the analyst must work with data base administrators to determine how data will be stored and what methods will be used for their retrieval and conversion to the format the program requires. Analysts are responsible for identifying and satisfying user requirements by drawing on the data stored in the database, and, where appropriate, by developing independent master and transaction files. 2.7.4 Design of Data Communications :Most information systems in practice involve the transmission of data between different locations. Data communications technology is advancing rapidly. Systems analysts have a variety of tools and technologies-from the office telephone to satellite in space to ensure that the needs of users in each environment can be met. The systems analyst is responsible not only for selecting the right communication equipment, whether it is for large or small systems or whether transmission is over wide or limited areas, but also for the steps that must be taken to design the application, specifying the method for linking the application into the communication network and selecting the most useful and cost effective communication services. Requirements for data communication system: The components included in information system determine how data transmission can occur. If a new system is being developed, selection of the components is the responsibility of the systems analyst. If a system is already working, the analyst must know what communications features to consider when developing a new application that will interact with an existing application. The system analysts must select the following components: 1. For communications channels, he may have to make a decision regarding channel

2.48 Information Systems Control and Audit selection, transmission rate, leased or dial-up line, type of line, for example, simplex or half-duplex etc. 2. Communications control devices: The analyst is required to select devices such as modems, data service units, multiplexer and concentrator, data switches, etc. In addition the analyst may also select the type of network (LAN or WAN), network topology (pointto-point or multi drop) etc. and the network architecture to be utilized for the proposed project. When analysts develop communication-based systems that can process online, they must consider additional file processing details. The validation of users and processing request takes on additional importance, since the user is not visible to the systems operator and therefore, cannot be readily identified as a valid user. Transactions must also be validated to protect against illegal or unexpected processing requests. When transactions are submitted and processed on-line, audit trails become essential for systems reliability and integrity. Even if processing is deferred to a time after initial data capture, protections are needed to safeguard data and system against loss of integrity. 2.7.5 System Manual : The basic output of the system design is a description of the task to be performed, complete with layouts and flowcharts. This is called the job specifications manual or system manual. It contains: (i) (ii) General description of the existing system. Flow of the existing system. (iii) Outputs of the existing system - the documents produced by existing system are listed and briefly described, including distribution of copies. (iv) General description of the new system - its purposes and functions and major differences from the existing system are stated together with a brief justification for the change. (v) Flow of the new system - this shows the flow of the system from and to the computer operation and the flow within the computer department. (vi) Output Layouts. (vii) Output distribution - the distribution of the new output document is indicated and the number of copies, routing and purpose in each department shown. The output distribution is summarized to show what each department will receive as a part of the proposed system. (viii) Input layouts - the inputs to the new system are described and complete layouts of the input documents and input disks or tapes provided. (ix) Input responsibility - the source of each input document is indicated as also the user department responsible for each item on the input documents.

System Development Life Cycle Methodology 2.49 (x) Macro-logic-the overall logic of the internal flows will be briefly described by the systems analyst, wherever useful. (xi) Files to be maintained - the specifications will contain a listing of the tape, disk or other permanent record files to be maintained, and the items of information to be included in each file. There must be complete layouts for intermediate or work file; these may be prepared later by the programmer. (xii) List of programs - a list of the programs to be written shall be a part of the systems specifications. (xiii) Timing estimates - a summary of approximate computer timing is provided by the systems analyst. (xiv) Controls - this shall include type of controls, and the method in which it will be operated. (xv) Audit trail - a separate section of the systems specifications shows the audit trail for all financial information. It indicates the methods with which errors and defalcation will be prevented or eliminated. (xvi) Glossary of terms used. 2.7.6 Reporting to Management : After the system design is finished, users have indicated their satisfaction with the design, and the system's benefits and costs are revised to reflect any major changes, the system development team reports the results of these activities to the management. The report should include: 1. 2. 3. 4. 5. description of the application and users source that led to the system. a summary of the results of the requirement analysis. design recommendation. any changes in the costs and benefits of the new system. a plan for the remaining system development activities. If the management is satisfied with the work the systems developer will proceed to the next phase of the systems development process. 2.8 STAGE IV: SYSTEMS ACQUISITION AND SOFTWARE DEVELOPMENT After a system is designed, either partially or fully, the next phase of the systems development starts which relates to the acquisition of hardware, software and services. In this section, we will explore how this process takes place. ACQUIRING SYSTEMS COMPONENTS FROM VENDORS At the end of the design phase, the organisation has a reasonably good idea of the types of hardware, software, and services it needs for the system being developed. These physical

2.50 Information Systems Control and Audit items are identified after the logical design of the system model is finished. The computer resources that can best meet the specifications established during system design are selected. After the management gives its consent to go ahead with the project, the acquisition process starts. Acquiring the appropriate hardware and software is critical for the success of the whole project. The organisation can discover new hardware and software developments in various ways. Most MIS managers keep themselves up-to-date about current hardware and software through published material. Many large MIS departments subscribe to industry analyst services and assign at least one person to keep in touch with current knowledge on the computer industry. The system development team often prepares a list of specific needs. Management also decides whether the hardware is to be purchased, leased from a third party or to be rented. The system development team then approaches various vendors who, in turn, respond with specific systems and prices. After vendor alternatives are known, one or more methods may he used by the team to select specific resources. Various aspects relating to selection of computer hardware, software and computer vendors are discussed in detail in the next section. 2.8.1 Procuring Computer Hardware : In case of procuring such machinery as machine tools, transportation equipment, air conditioning equipment, etc., the management can normally rely on the time tested selection techniques and the objective selection criteria can be delegated to the technical specialist. But computer is not just another machine. This is not only because of its highly complex internal structure for which myriads of performance measures can be devised, though none of which satisfactorily describes the power and capabilities of the computer, but also because of its openendedness in that it can admit connection of a large number of peripherals with differing capabilities in the near future and later. Also a computer has a profound and long-range effect on a company's operations. The user depends upon the buyer for support services, systems design, education and training etc., and expansion of computer installation for almost an indefinite period; therefore, this is not just buying the machine and paying the vendor for it but it amounts to an enduring alliance with the supplier. The following points may be considered while selecting a computer system : (1) All computer systems offered in the market today have good hardware, competent software and roughly similar facilities. Due to the rapid development of computer technology, the more recent the computer, the better its performance is and the lower its cost. Therefore, as far as possible, the latest possible technology should be acquired. As long as this general principle is adhered to, the choice of a particular computer will not significantly affect the success of the computer effort. (2) Commercial data processing consists mainly of reading-in-data, printing out data and storing and retrieving information from magnetic media. Thus, computer performance for

System Development Life Cycle Methodology 2.51 commercial work is mainly determined by the speeds and capabilities of input/output and storage peripherals. Scientific, engineering and operations problems require good computational facilities. Thus, the efficiency of a computer in handling such problems will depend on the main storage available and the instruction execution speed, and repertoire. A comparison along these lines can be made quickly and quite effectively. (3) The software supplied by the manufacturer may make a significant difference if it contains a package of special applicability to the jobs envisaged. Experts maintain that since hardware speed and facilities are uniformly good, today the selection of computer should be made on software considerations. While all manufacturers supply general software packages for linear programming. PERT, etc., and packages for such commercial applications as inventory control and production planning, a few manufacturers also offer packages specially designed for a particular industry such as packages for airline reservations and packages for applications in banking and insurance. Obviously a manufacturer who has a package for user's special needs will enjoy a significant advantage. In general, most manufacturers' packages are good. There are, of course, individual differences but these are usually not too important. The superiority of software may not be strong enough to influence a computer acquisition decision. (4) Modern computers are marketed as series of compatible machines with increasingly powerful central processors and interchangeable peripherals. This is very useful when, after a few years, work expands to fit in the existing computer storage and a bigger machine is required. A more capable machine of the same series will allow the existing programs to be carried over so that the large investment in programming may be preserved. In case of breakdown, compatibility allows a wider range of machines to be used as back-up. Thus, the choice of a computer really becomes a choice of a model within a series, based on a long-range plan of expansion. This however, means that one is dependent on the manufacturer and subject to his whims and fancies. But dependence is preferable to reprogramming which can be prohibitively expensive. (5) The selection of a computer does not end within the choice of a manufacturer and a model. It continues to the selection of a configuration and a plan for its gradual expansion. This can be as important as the choice of manufacturer and a properly considered model can save a great deal of money. Outside assistance in computer selection can be had from computer manufacturers, independent consultants specialising in computers, or management consulting firms. The distinction between vendor selection and machine selection is to be carefully noted at this stage. Choosing the vendor is essentially a matter of business judgement and prerogative of exercising it must be retained in-house. Once, however, the vendor is selected, he can be counted upon to provide useful guidance for machine selection also.

2.52 Information Systems Control and Audit 2.8.2 Software acquisition : Make or Buy : Once user outputs and input designs are finalised, the nature of the application software requirements must be assessed by the systems analyst. This determination helps the systems development team to decide what type of application software products are needed and consequently, the degree of processing that the system needs to handle. This helps the system developers in deciding about the nature of the systems software and computer hardware that will be most suitable for generating the desired outputs, and also the functions and capabilities that the application software must possess. At this stage, the system developers must determine whether the application software should be created in-house or acquired from a vendor. This decision is often called the make-or-buy decision. In the past several years, pre-packaged application software or application software packages have become increasingly popular for many business functions, including accounting (for example, payroll and personnel accounting), general ledger, manufacturing, financial planning and numerous other applications. Many of these packages consist of several programs and a complete set of documentation tools. Vendors providing these software packages even impart training about how to use the software to its full potential. Advantages of Application Packages : The four most compelling advantages of using prewritten application packages are summarised below : (i) Rapid implementation: Application packages are readily available to implement after they are purchased. In contrast, software developed in-house may take months or even years until it is ready for implementation. (ii) Low risk: Since the application package is available in the finished form, the organisation knows what it is going to get for the price it has paid. With in-house developed software, the long development time breeds uncertainty with regard to both the quality of the final product and its final cost. (iii) Quality: The firms engaged in application package developments are typically specialist in their products' niche area. Generally, they have a lot of experience in their specialised application field and hence can provide better software. In contrast, in-house programs often have to work over a wide range of application areas; they may not be possessing expertise for undertaking proposed software development. (iv) Cost: Software vendors can leverage the cost of developing a product by selling the product to several other firms, thereby realising a lower cost from each application user. Thus, an application package generally costs less than an in-house developed package. In addition, many hidden costs are faced by organisations that want to develop applications in-house. Hence, application packages, sometimes, turn out to be cheaper compared to in-house developed software. 2.8.3 Sources of Packaged Software : Thousands of programs are available in the market today for purchase. Computer manufacturers, large and small software houses and computer

System Development Life Cycle Methodology 2.53 retail stores are some of the sources from where these packages can be purchased. Another source of packaged software is user groups or association of users of a particular computer system. User groups often recognise the need for a specific program, which may be developed by one member organisation and made available to other members. For example, utility programs and extension of existing operating systems are typically developed by a member organisation and distributed through the user group. Buying packaged software is risky. Some are difficult to install. There may he undetected bugs in the software which may create problems at a later stage for the purchaser. Many packages may not be adequately developed and tested. There is a significant 'fringe element' in the software market that does not subscribe to ethical marketing practices. Hence, a buyer has to be very cautious while purchasing the software packages. The best protection is to deal only with those venders who are known to be reputable and who provide after sales support such as training, answering queries and correcting program defects. 2.8.4 Steps involved in Selection of A Computer System : The selection of an appropriate computer system, both hardware and application software package demands a high level of expertise and many organisations use a consultant either to provide guidance to their personnel or to manage this activity. The steps involved in selection of a computer system are : 1. 2. 3. 4. 5. 6. 7. 8. Prepare the design specifications. Prepare and distribute an RFP (Request for proposal) to selected computer vendors. On the basis of an analysis of proposals, eliminate vendors whose proposals are inferior. Have vendors present their proposals. Conduct further analysis of the proposals. Contact present users of the proposed systems. Conduct equipment benchmark tests. Select the equipment. During feasibility study, the EDP manager will list down various requirements of the organisation based on which design specifications of the computer will be laid down. These mandatory specifications would then constitute an over-riding criterion of selection. If a vendor fails to meet them, the manager would simply screen out that vendor without any further consideration. These specifications would establish a desired configuration that might include for example, the required minimum main memory size, the required characteristics of secondary memory, and general types and capacities of input and output equipments needed etc. Usually, design specifications should be developed without reference to any specific models of equipment or to a particular vendor's product line.

2.54 Information Systems Control and Audit After that, a RFP (request for proposal) is prepared by the organisation and given to vendors, asking the vendors to prepare a bid and submit it to the organisation. The RFP contains all details that are necessary for a vendor to prepare a fully detailed proposal. Typically, the RFP also contains a deadline for bidding, the length of which depends on the complexity of the project- for example, just a few weeks for hardware, and longer periods of time for systems requiring custom development tasks. After responses to RFP have been received, they are evaluated by the organisation. Meetings are scheduled with each vendor, whose bid is competitive in terms of price and meeting the requirements of the RFP. The participants at each meeting include representatives from the vendor, representatives from the steering committee, and representatives from the design team. The vendors role is to present its proposal and to answer questions from the other participants. The evaluation committees role is to listen to the vendor proposals, provide input to the steering committee about the pros and cons of each one, and perhaps make a recommendation for a preferred vendor. Frequently, vendors who survive this presentation are nevertheless asked to revise their proposal in significant respects. The after presentation equipment analysis is carried out in even greater details, and it involves the proposals of only those vendors who remain in competition which may be only one or two. At this point, the organisation should be satisfied that the systems still being considered can solve its problems in a cost effective manner. If this is not the case, the drastic steps of rewriting the design specifications and of submitting RFPs to other vendors must be considered. 2.8.5 Validation of vendors proposals : This process consists of evaluating and ranking the proposals submitted by vendors and is quite difficult, expensive and time consuming, but in any case it has to be gone through. This problem is made difficult by the fact that vendors would be offering a variety of configurations. The following factors have to be considered towards rigorous evaluation. 1. The Performance Capability of Each Proposed System in Relation to its Costs: It is imperative that a vendor system be capable of processing the organisations data within the time frames desired by management. Otherwise, delays in providing needed outputs will occur once the computer system is operational. There are many measures of performance, including speed, response time, number of users supported, and system testing. One way to examine the operating efficiency of a particular system is to use a benchmark test. With this approach, the vendors system performs a data processing task that the new system must perform (e.g., payroll processing), and representatives of the organisation then examine the outputs for accuracy, consistency, and efficiency. 2. The Costs and Benefits of Each Proposed System: The accountants on the design team will analyze the costs of every vendors proposed system in relation to the systems anticipated performance benefits i.e., they will perform a cost-benefit analysis for each proposed system. In this effort, the accountants should also investigate the differences between purchasing and leasing each vendors system. If the steering committee elects to

System Development Life Cycle Methodology 2.55 purchase its computer system, the accountants should then advise the committee on a realistic depreciation schedule for the new system. 3. The Maintainability of Each Proposed System: Maintainability refers to the case with which a proposed computer system can be modified. For example, this flexibility enables a firm to alter a portion of a payroll system to reflect new federal tax laws. Because the costs of maintaining a large information system are typically five times as much as the costs of initially acquiring or developing a system, the evaluators should place considerable emphasis on this dimension. 4. The Compatibility of Each Proposed system with Existing Systems: Compatibility refers to the ability to implement and interface the new system with existing computer resources and software. In some instances, this comes down to hardware issues. For example, it may not be possible to run specific software modules of the new system on some of the companys older local area network servers, which will consequently have to be upgraded. But compatibility issues can also involve the operating system, existing application software, or procedural concerns as well for example, the requirement that employees learn a whole new set of procedures for inputting data. 5. Vendor Support : Vendor support includes such things as (1) training classes that familiarize employees with the operating characteristics of the new system, (2) help in implementing and testing the new system, (3) assistance in maintaining the new system through a maintenance contract, and (4) backup systems for temporarily processing company data if required. The availability of business-hours-only versus round-the-clock support is another consideration. Most vendors charge extra for enhanced services. 2.8.6 Methods of Validating the proposal : Mandatory requirements would constitute overriding criteria in that, if a vendor fails to meet them, he would be screened out without any further consideration. The desirable characteristics would surely be more difficult to evaluate because the vendors may ignore them or offer several alternatives. The criteria may be listed in a descending order of importance. After having established and ranked the criteria, next comes the question of validating the vendor's proposals against these. The method selected may be a simple or a sophisticated one. Large organisations would naturally tend to adopt a sophisticated and objective approach. The following are some of the validation methods. (1) Checklists : It is the most simple and rather a subjective method for validation and evaluation. The various criteria are put in check list in the form of suitable questions against which the responses of the various vendors are validated. Obviously, then, the vendor who has most cleverly and rhetorically worded, his response is likely to get the award. Below we give an example of a software checklist and a support services checklist. (a) Example of software validation checklist: The assessment of packaged software considered for purchases is quite difficult. Fortunately, several independent organisations objectively assess programs for sale and report their evaluation. Not only these evaluations

2.56 Information Systems Control and Audit are useful while comparing particular software packages, they also provide indications of the typical capabilities of a software package. However, a user must determine as a first step in assessing a program, whether, on paper, a particular software package meets the requirement specifications established during system analysis. The following features of a package may be ascertained before purchasing the same: (i) (ii) What is the package designed to do? How developed is the software package? (iii) How is the package organised? (iv) Is the package operable? (v) Can the package operate on our hardware configuration? (vi) Can the program provide the needed reports? (vii) Does the program have adequate capacity in terms of the number of transactions it can process, the number and length of fields per record it can process, the total file size permitted and so on? (viii) How many processing runs on the computer are required to complete each data processing job? Some programs will perform several tasks each time they are executed. Others may perform only one task per run and hence a program may have to be executed several times, requiring more operator time and computer processing to complete the job. (ix) How long does the program take to process? The efficiency of program processing varies considerably among the programs that perform the same task. Some may require much more time compared to other programs. (x) Will the package require modifications? (xi) Can the package be modified if necessary? (xii) Who will modify the package? (xiii) What are the overall costs? (xiv) Is comprehensive documentation available ? (xv) Who will maintain the package? (xvi) What are the package constraints? (xvii) Where is the package currently utilised? (xviii) What is the primary language? (xix) What input/output techniques are utilised?

System Development Life Cycle Methodology (xx) What are the required input/output formats? (xxi) How must input be organised? (xxii) What controls are included? (xxiii)What kind of user training is provided? 2.57 Current users of a software package are a valuable source of information about its performance. They usually describe both the unanticipated problems and the unexpected benefits of a particular program. Reputable vendors normally provide the list of various users of the package and hence it is desirable to contact any of these users before purchasing software. An alternative way of evaluating a package is to actually process data with it on the organisations own computer. This process is called software bench mark test and consists of using the organisations transactions to assess the processing speed, userfriendliness of the program and the operation of special features such as report-writing capabilities. Preparation of a software benchmark test is considered to be a difficult task since only experienced persons in actual operation over a long period of time can provide a full test of the advantages and limitations of the software package. (b) Example of Support Service Checklists (i) Performance : What has been the vendors past performance in terms of his past promises? (ii) System development : Are system analysis and programming consultants available? What are their qualities and cost? (iii) Maintenance : Is equipment maintenance provided? What is the quality and cost? (iv) Conversion : What systems development, programming and hardware installation service will they provide during the conversion period? (v) Training : Is the necessary training of personnel provided? What is its quality and cost? (vi) Back-up : Are several similar computer facilities available for emergency back up purposes? (vii) Proximity : Does the vendor have a local office? Are sales, systems development, programming, and hardware maintenance services provided from the office? (viii) Hardware : Do they have a wide selection of compatible hardware? (ix) Software : Do they have a wide variety of useful systems software application programs? Similar checklists may be developed for hardware compatibility etc. This method, however is generally applied only to minor proposals. (2) Point-Scoring Analysis : Another approach for evaluating those accounting packages that meet most of a companys major requirements is a point-scoring analysis such as the one

2.58 Information Systems Control and Audit illustrated in table 1. (This analysis can also be used to evaluate hardware as well.) To illustrate, assume that in the process of selecting an accounts payable system, an organisation finds three independent vendors whose packages appear to satisfy current needs. Table 1 shows the results of the analysis. (Because the cost to purchase or lease each vendors accounts payable software package is about the same, cost is not an issue in this selection process.) When performing a point-scoring analysis, the evaluation committee first assigns potential points to each of the evaluation criteria based on its relative importance. In table 1, for example, the committee feels that adequate controls (10 possible points) is more important than whether other users are satisfied with the software (8 possible points). After developing these selection criteria, the evaluation committee proceeds to rate each vendor or package, awarding points, as it deems fit. The highest point total determines the winner. Thus, in table 4, the evaluation indicates that Vendor Bs accounts payable software package has the highest total score (106 points) and the committee should therefore acquire this vendors system. Although point-scoring analyses provide an objective means of selecting a final system, many experts believe that evaluating accounting software is more of an art than science. There are no absolute rules in the selection process, only guidelines for matching user needs with software capabilities. Thus, even for a small business, the evaluators must consider such issues as the companys data processing needs, its in-house computer skills, vendor reputations, software costs, and so forth. Table-4 Software Evaluation Criteria Does the software specifications? meet all mandatory Possible points 10 10 10 10 8 10 9 Vendor A 7 8 9 7 6 7 8 Vendor B 9 9 9 9 7 8 8 Vendor C 6 7 8 6 5 6 7 Will program modifications, if any, be minimal to meet company needs? Does the software contain adequate controls? Is the performance (speed, accuracy, reliability, etc.) adequate? Are other users satisfied with the software? Is the software user-friendly? Can the software be demonstrated and testdriven?

System Development Life Cycle Methodology Does the software have an adequate warranty? Is the software flexible and easily maintained? Is online inquiry of files and records possible? Will the vendor keep the software up to date? Totals 8 8 10 10 123 6 5 8 8 94 7 7 9 8 106 6 5 7 7 2.59 85 (3) Public evaluation reports : Several consultancy agencies compare and contrast the hardware and software performance for various manufacturers and publish their reports in this regard. This method has been frequently and usefully employed by several buyers in the past. For those criteria, however, where published reports are not available, resort would have to be made to other methods of validation. This method is particularly useful where the buying staff has inadequate knowledge of computer facts. Assuming that one or more proposed configurations are deemed satisfactory, two questions remain: 1. Are the present users of the system being considered satisfied with it and the vendors support? Usually preliminary inquiries are made to present users before the vendor is selected to receive an RFP. Additional inquiries may be made to additional customers of the vendor and to the vendor's user association. The financial condition of the vendor may be investigated through a credit rating agency, or by means of a financial statement analysis. Vendors who are in poor financial conditions are likely to skimp on services to purchasers and are less likely to provide hardware and software enhancements in the future. Also, continuing physical maintenance and spare parts can become major problems if the vendor is forced into bankruptcy. If a vendor's other clients provide favourable reports and if the vendor's financial status is sound, there is reason to believe that the system offered will be satisfactory. Will the system actually perform as the vendor claims it will and as the specifications indicate that it should? It is impossible to detect every possible bottleneck and other system problems by desk checking alone, and there may be unusual aspects of the organisations data processing activities that will cause problems with and degrade the performance of a computer system. Equipment benchmark tests protect the organisation against such dangers. Usually benchmark tests are done on equipment that will be purchased; it is loaned by the vendor and operated by the organisations personnel. Tests may also be done on equipment borrowed from another client of the vendor. Benchmark testing may require adapting certain of the organisations programs to the new system or special benchmark problems may be designed. Because of the large amount of preparation efforts involved, only the organisations most critical or highest 2.

2.60 Information Systems Control and Audit usage application areas are tested. 2.8.7 Bench marking problem for vendors proposals : Benchmarking problems for vendors proposals are sample programs that represent at least a part of the buyers primary computer work load. They include software considerations and can be current applications programs or new programs that have been designed to represent planned processing needs i.e., benchmarking problems are oriented towards testing whether a computer offered by the vendor meets the requirements of the job on hand of the buyer. They are required to be representative of the job mix of the buyer. Obviously, benchmarking problems can be applied only if job mix has been clearly specified. The benchmarking problems, would then comprise long jobs, short jobs, tape jobs, disk jobs, mathematical problems, input and output loads etc, in proportion typical of the job mix. If the job is truly represented by the selected benchmarking problems, then this approach can provide a realistic and tangible basis for comparing all vendors' proposals. Tests should enable buyer to effectively evaluate cross performance of various systems in terms of hardware performance (CPU and input/output units), compiler language and operating system capabilities, diagnostic messages, ability to deal with certain types of data structures ad effectiveness of software utilities. Bench marking problems, however, suffer from a couple of disadvantages. It takes considerable time and effort to select problems representative of the job mix which itself must be precisely defined. It also requires the existence of operational hardware, software and services of systems. Nevertheless, this approach is very popular because it can test the functioning of vendor's proposal. The manager can extrapolate in the light of the results of bench marking problems, the performance of the vendors' proposals on the entire job mix. 2.8.8 Test problems : Test problems disregard the actual job mix and are devised to test the true capabilities of the hardware, software or system. For example, test problems may be developed to evaluate the time required to translate the source code (program in an assembly or a high level language) into the object code (machine language), response time for two or more jobs in multi-programming environment, overhead requirements of the operating system in executing a user program, length of time required to execute an instruction, etc. The results, achieved by the machine can be compared and price performance judgement can be made. It must be borne in mind, however that various capabilities to be tested would have to be assigned relative weightage. Equipment benchmark testing is worth the immense efforts involved only if the cost of the equipment is in the hundreds of thousands of rupees or if the applications to be run on the new system are critical and a mistake in equipment acquisition would lead to high costs for the rganization. If stakes are not high, the rganization may rely on benchmark tests performed by independent companies using general types of transactions. 2.8.9 Hardware Contracts and Software Licenses: Contract: Suppliers should have been issued with draft contracts as an annex to the operational requirements. Draft contracts should be discussed with the suppliers to ensure

System Development Life Cycle Methodology 2.61 that the clauses are acceptable to both supplier and purchaser. This stage ensures that all parties understand their respective responsibilities prior to best and final offers being invited. Draft contracts should include detailed descriptions of the rights and remuneration of both parties. The contract should include clauses which consider what action will be taken should the system fail to meet user requirements . The contract should also stipulate the circumstances under which a product or service can be rejected, e.g. contract termination or remedial action clauses. It is always advisable to visit reference sites where potential suppliers have installed a system that is similar to that being offered. Final evaluation and award of contract : The purchaser should draw up a best and final offer evaluation model. Suppliers should then be invited to submit their final bids. Once all the final bids have been received they should be evaluated against the evaluation model. The contract should be awarded to the suppliers on the basis of best value for money over the lifetime of the project. Software License : A software license is a license that grants permission to do things with computer software. The usual goal is to authorise activities which are prohibited by default by copyright law, patent law, trademark law and any other intellectual property right. The reason for the license, essentially, is that virtually all intellectual property laws were enacted to encourage disclosure of the intellectual property. As software is so easily replicated, disclosure is not an option that most software vendors would prefer to avail themselves to. The result is that the vendors need an alternate method of allowing the licensed user to use the product but still be restricted so as to prevent certain decompiling rights the user might otherwise have as a result of the default intellectual property rights. Typically, then, the software license is a complex document, identifying the specific usage rights that are granted to the licensee, while also stating the license limitations. For example, a software license might give permission to allow a certain number of concurrent users of the software. This means that at any given point in time, a limit exists on the number of people who can use the software. As a specific user stops using the program, then another, different, user can start to use the program. Compare and contrast this with a named user model, whereby the software is licensed to specific individuals. Regardless of whether the named individual is actually using the product or not, another individual is not licensed to use that same copy of the software. A software vendor may offer a software license unilaterally (without giving the licensee the opportunity to negotiate for more favorable terms), or even as part of a software license agreement with another party. Virtually all proprietary software is sold under some form or fashion of software license agreement, including free software and open source software which are usually distributed under the terms of their EULA. Failure to abide by the terms of the license can subject the violator to the default penalties for

2.62 Information Systems Control and Audit violations of intellectual property laws in and if so allowed by the geographic region of the licensor, as well as any contractually agreed-upon damages listed in the software license. 2.9 SOFTWARE DEVELOPMENT If the organisation decides that all the software for the application under consideration is to be developed in-house, then the organisation must put considerable efforts on program development. Inhouse development is a painstaking process. The system developer must instruct the computer how to do everything precisely, without error and in the correct sequence. Hence, the development of application software has to undergo a life cycle similar to the one used to develop the entire system. An in-house creation of programs commonly involves the following six stages : (i) Program analysis: In this stage, the programmer ascertains for a particular application (e.g., up-dating of the stock file) the outputs required (i.e., the up-dated stock file, listing of the replenishment orders, stock movements reports, stock valuation report etc.), the inputs available (i.e. the stock master file, the receipts and issues transactions file) and the processing (i.e., up-dating the physical balance, computing stock value for various items, determination of placement of the replenishment order etc.). The programmer then determines whether the proposed application can be or should be programmed at all. It is not unlikely that the proposal is shelved for modifications on technical grounds. (ii) Program design : In this stage, the programmer develops the general organisation of the program as it relates to the main functions to be performed. Out of several other tools available to him, input, output and file layouts and flowcharts are quite useful at this stage. These layouts, and flowcharts etc. are provided to the programmer by the systems analyst. The flowchart depicts the flow of data, documents etc. very clearly, what are the steps to be repeated or what are the alternatives or branches at a particular step are shown conspicuously. Such details may be difficult to bring out in descriptive language. (iii) Program Coding: The logic of the program outlined in the flowcharts is converted into program statements or instructions at this stage. For each language, there are specific rules concerning format and syntax. Syntax means vocabulary, punctuation and grammatical rules available in the language manuals that the programmer has to follow strictly and pedantically. There are special sheets for writing the program instructions in each language. The format of these sheets facilitates writing errorfree programs. Just as a mathematical problem can be solved in several ways, so is the case with writing a program. Different programmers may write a program using different sets of instructions but each giving the same results. In fact, there is a great scope for elegance in writing the programs but the limitations of time stipulated by management would not encourage the programmers to strive for such practice. Therefore, the programmers broadly pursue three objectives: simplicity, efficient utilisation of storage and least processing time. It is highly desirable that the programs are simple to understand since a program written by one programmer is very difficult for the other to understand. Further, the

System Development Life Cycle Methodology 2.63 programs, upon implementation, may require frequent modifications to suit the changing systems environment. There is a program maintenance group employed on a permanent basis for modifying the programs and this group is different from the one who wrote the programs initially. It is, therefore, emphasized that programs should be written as simple as possible to start with. There is usually a trade off possible between the other two objectives: efficient utilisation of storage and least processing time. Each coded instruction is then entered onto a magnetic media using a key-to-diskette device or a keyboard. This stored file then constitutes the source program i.e., the program in the source language which may be either an assembly language or a procedural language such as BASIC or C. This program is then translated into the machine language of the computer on hand by an interpreter or a compiler. All these have diagnostic capabilities i.e., they can point out several syntax errors like two labels used for the same location and invalid standard label, etc. The programmer, upon getting the print out of the assembly or compiler run, rectifies his program. (iv) Debug the program : The process of debugging a program refers to correcting programming language syntax and diagnostic errors so that the program compiles cleanly. A clean compile means that the program can be successfully converted from the source code written by the programmer into machine language instructions. Once, the programmer achieves a clean compile, the program is ready for structured walk through discussed below. Debugging can be a tedious task. It consists of four steps: inputting the source program to the compiler, letting the compiler find errors in the program, correcting lines of code that are in error, and resubmitting the corrected source program as input to the compiler. Usually, this process must be repeated half a dozen or more times using a batch compiler. The length of time required to debug a program can be shortened considerably by the use of an interactive compiler which checks the source program and displays any errors on a CRT or prints them on a printer. The programmer corrects the indicated errors and initiates the interactive compiler as often as necessary until all errors are corrected. The interactive compiler allows the programmer to debug a program in a few hours, as opposed to a few days using a batch compiler. Use structured walkthroughs: After a program has been compiled and scrutinised for obvious errors, there is need for a structured walkthrough. Basically, a structured walkthrough is a mental execution of the program by the programming team. In order to perform walkthroughs, the programming team must examine the source text (which usually takes a few hours) after which the team meets and collectively performs a mental execution of the program. A list of errors is made as each logical path is followed. The interface with modules either calling or called by the module being examined are carefully checked as well. At the end of the walkthrough, the list of errors is given to the author of the program. Using this approach, most errors are caught before any testing occurs. Also, the team members who review the text become familiar with parts of the system other than their own.

2.64 Information Systems Control and Audit This helps to establish a common base of understanding of all components of the system. Coincidentally, while the team reviews the interface with other modules, errors (usually from miscommunication) are also spotted in other modules. It is not uncommon to have a program execute correctly the first time it is tested. Test the program : A careful and thorough testing of each program is imperative to the successful installation of any system. Approximately 30 to 50 percent of the resources required for program development should be allocated to program testing. The programmer should plan the testing to be performed, including testing all possible exceptions. The test plan should require the execution of all standard processing logic. The program test plan should be discussed with the project manager and/or system users. A log of test results and all conditions successfully tested should be kept. The log will prove invaluable in answering the inevitable question. 'Did you ever test for this condition?' Software packages are available that allow interactive testing of batch-processing programs. They greatly reduce the length of time required for testing. Interactive testing allows the programmer to monitor each step required to process a program input. If a problem in program logic flow is discovered, the programmer can stop the execution of the program, correct the problem, and have the program resume processing at a point just prior to the interruption. Review the program code for adherence to standards : One of the preparatory steps of the system implementation phase is to set standards for program coding. It is necessary to review each program to ensure that standards are being met. Ideally, someone who is not directly connected to the implementation team should review it, so that the quality of the system and adherence to standards are evaluated objectively without concern for project schedule and budget. It is recommended that this evaluation occur long before the programmer has a clean compile. Because less than half of the total program development effort is complete at this stage, the programmer is much more receptive to constructive criticism and more open to changes. A second review should be scheduled sometime during the program testing stage to ensure that suggestions have been followed. (v) Program documentation: The writing of narrative procedures and instructions for people who will use software is done throughout the program life cycle. Managers and users should carefully review documentation in order to ensure that the software and system behave as the documentation indicates. If they do not, documentation should be revised. User documentation should also be reviewed for understandability i.e. the documentation should be prepared in such a way that the user can clearly understand the instructions and it should not be presented in a computer jargon which only sophisticated MIS professionals can comprehend. In many organisations, systems analysts and programmers are responsible for application software development. Systems analysts work more closely with managers and users to determine their needs and to establish application software requirements. From these needs they evolve a program design and a set of technical design specifications . (vi) Program maintenance : The requirements of business data processing applications are

System Development Life Cycle Methodology 2.65 subject to continual change. This calls for modification of the various programs. There are, usually separate categories of programmers called maintenance programmers who are entrusted with this task. There is a difficult task of understanding and then revising the program they did not write. This should bring out the necessity of writing programs in the first place that are simple to understand. These six stages are known as the program development life cycle (or program life cycle). Managers are usually involved with this process during the first (program analysis), second (design) and sixth (maintenance) stages. Systems developers should find out exactly what the user wants and the user should try to clearly communicate his software needs to the designer. As and when the needs of the user change, these should also be communicated to the MIS department so that preparation changes in the software can be incorporated. 2.10 ALTERNATE DEVELOPMENT METHODOLOGY Various alternative approaches are discussed below: (i) Prototyping approaches: The traditional approach sometimes may take years to analyse, design and implement a system. In order to avoid such delays, organisations are increasingly using prototyping techniques to develop smaller systems such as decision support systems, management information systems and expert systems. The goal of prototyping approach is to develop a small or pilot version called a prototype of part or all of a system. A prototype is a usable system or system component that is built quickly and at a lesser cost, and with the intention of being modifying or replacing it by a full-scale and fully operational system. As users work with the prototype, they make suggestions about the ways to improve it. These suggestions are then incorporated into another prototype, which is also used and evaluated and so on. Finally, when a prototype is developed that satisfies all user requirements, either it is refined and turned into the final system or it is scrapped. If it is scrapped, the knowledge gained from building the prototype is used to develop the real system. Experimenting with the prototype helps users to identify additional requirements and needs that they might have overlooked or forgotten to mention. In addition, with prototyping, users have a clearer visual picture of what the final version will look like and they do not have to sign off on a system which is presented to them in the form of diagrams and specification lists. Decision supports semi-structured or unstructured management decision environment, are ideal for the experimentation and trial-and-error development associated with prototyping. Expert systems are other ideal candidates for prototyping approach because expert knowledge usually requires continual refinements. Prototyping can also be used in the development of transaction processing system. It is most commonly used during the system design stage, for instance, to develop the mock screen for input etc. Prototyping can be viewed as a series of four steps:

2.66 Information Systems Control and Audit Step 1: Identify Information System Requirements: In traditional approach, the system requirements have to be identified before the development process start. However, under prototype approach, the design team needs only fundamental system requirements to build the initial prototype, the process of determining them can be less formal and time-consuming than when performing traditional systems analysis. (The team can develop the detailed requirements of the system later after users have had time to interact with the prototype and provide feedback.) Step 2: Develop the Initial Prototype: In this step, the designers create an initial base model for example, using fourth-general programming languages or CASE tools. In this phase, the goals are rapid development and low cost. Thus, the designers give little or no consideration to internal controls, but instead emphasize such system characteristics as simplicity, flexibility, and ease of use. These characteristics enable users to interact with tentative versions of data entry display screens, menus, input prompts, and source documents. The users also need to be able to respond to system prompts, make inquiries of the information system, judge response times of the system, and issue commands. Step 3: Test and Revise: After finishing the initial prototype, the designers first demonstrate the model to users and then give it to them to experiment. At the outset, users must be told that the prototype is incomplete and requires subsequent modifications based on their feedback. Thus, the designers ask users to record their likes and dislikes about the system and recommend changes. Using this feedback, the design team modifies the prototype as necessary and then resubmits the revised model to system users for reevaluation. Thus iterative process of modification and reevaluation continues until the users are satisfied commonly, through four to six interactions. Step 4: Obtain User Signoff of the Approved Prototype: At the end of Step 3, users formally approve the final version of the prototype, which commits them to the current design and establishes a contractual obligation about what the system will, and will not, do or provide. Approximately half of these approved prototypes become fully functional systems. The remaining, throwaway prototypes are not developed typically because the modifications required to make them functional are too costly or in other ways not practical. But this does not mean that type prototyping exercise has been a failure. To the contrary, it signals an impractical system and thus saves an organisation a great deal of time and money! In general, the procedure is useful when one or more of the following conditions exist: 1. 2. 3. 4. 5. End users do not understand their informational needs very well. System requirements are hard to define. The new system is mission-critical or is needed quickly. Past inter actions have resulted in misunderstandings between end users and designers. The risks associated with developing and implementing the wrong system are high.

System Development Life Cycle Methodology 2.67 Prototyping is not always the best systems design approach. For example, the design team can be misled if it relies on a small portion of the user population for developing its models (and thus satisfies the informational needs of non-representative employees). For this reason, prototyping is not normally appropriate for designing large or complex information systems that serve many users with significantly different informational needs. Also, prototyping is not commonly used for developing traditional AIS applications such as accounts receivable, accounts payable, payroll, or inventory management, where the inputs, processing, and outputs are well known and clearly defined. Advantages of Prototyping 1. Prototyping requires intensive involvement by the system users. Therefore, it typically results in a better definition of these users needs and requirements than does the traditional systems development approach. A very short time period (e.g., a week) is normally required to develop and start experimenting with a prototype. This short time period allows system users to immediately evaluate proposed system changes. In contrast, it may take a year or longer before system users can evaluate proposed system changes when the traditional systems development approach is used. Since system users experiment with each version of the prototype through an interactive process, errors are hopefully detected and eliminated early in the developmental process. As a result, the information system ultimately implemented should be more reliable and less costly to develop than when the traditional systems development approach is employed. Prototyping can only be successful if the system users are willing to devote significant time in experimenting with the prototype and provide the system developers with change suggestions. The users may not be able or willing to spend the amount of time required under the prototyping approach. The interactive process of prototyping causes the prototype to be experimented with quite extensively. Because of this, the system developers are frequently tempted to minimize the testing and documentation process of the ultimately approved information system. Inadequate testing can make the approved system errorprone, and inadequate documentation makes this system difficult to maintain. Prototyping may cause behavioral problems with system users. These problems include dissatisfaction by users if system developers are unable to meet all user demands for improvements as well as dissatisfaction and impatience by users when they have to go through too many interactions of the prototype. 2. 3. Disadvantages of Prototyping 1. 2. 3. Inspite of above listed limitations, to some extent, systems analysis and development has

2.68 Information Systems Control and Audit been greatly improved by the introduction of prototyping. Prototyping enables the user to take an active part in the systems design, with the analyst acting in an advisory role. Prototyping makes use of the expertise of both the user and the analyst, thus ensuring better analysis and design, and prototyping is a crucial tool in that process. (ii) End user development approach : With the increasing availability of low-cost technology, end user development is becoming popular in many organisations. In end-user development, it is the end user and not the computer professional who is responsible for systems development activities. Many different kinds of organisations allow end-users to develop systems For example, whenever a manager or a department acquires its own, relatively inexpensive micro computers or office information systems, end-user development often takes place. The number and nature of systems development activities followed by the end-user often differ from those found in formal approaches such as the traditional approach. There are many advantages to end-user computing, but there are also a number of risks involved. These risks include the following: 1. A decline in standards and controls. When an analyst is in-charge of developments, walkthrough will be done and standards and policies will be enforced; these things are unlikely to be carried out to the same degree with end-user computing. Inaccuracy of specification requirements. The end-user will not have the experience of an analyst in completing an accurate specification of system requirements. Due to the lack of adequate specifications, there would be a reduction in the quality assurance and stability of the system. An increase in unrelated and incompatible systems. Departments would choose their own software and hardware and incompatibility of systems would result; this would mean that management would have difficulty in obtaining full corporate data. Difficulties in accessing could arise for users trying to access a central system, such as the corporate database, with a proliferation of different systems and applications. 2. 3. 4. 5. (iii) Systematic approach for development in small organisations : In smaller organisations, fewer MIS professionals are employed and they may have such a variety of responsibilities that they have little time to develop new systems for users. In a very small organisation, no MIS professional may be on the staff. However, this does not mean that it is not possible for them to develop new systems. Many smaller firms have developed good systems by using systematic approach. This systematic approach generally consists of the following steps: (a) Identify requirements. (b) Locate, evaluate and secure suitable software. (c) Locate, evaluate and select suitable hardware on which the above software can be run.

System Development Life Cycle Methodology (d) Implement the system. 2.69 In the systematic approach, after information-processing requirements are determined, a search for suitable software becomes the primary focus. Once it is located, hardware is selected and the system is put together and used. It may be noted that managers in organisations employing a large number of MIS professionals may also use a systematic approach to develop the office information systems used in their own immediate work areas. (iv). Rapid application development (RAD) : As the pace of change has increased the approach to systems analysis and design described above has been criticised on the grounds that it is too slow and too costly. Recent years has seen the introduction of new system design and engineering tools which are intended to speed up the development process; Rapid Application Development or RAD is the term assigned to these new tools and techniques. The principle underlying RAD is that it is possible to satisfy 80% of the functionality required in 20% of the time by concentrating on key business requirements. The danger from the auditors point of view is that system controls might be overlooked or compromised in the interests of expediency. The key features of the approach can be summarised as cheap, quick and adequate. RAD is particularly suited to rapidly changing business areas where there is a danger that the use of traditional analysis and design methods could lead to delivery of a product after the need for it has passed. Prototyping tools enable designers to develop the user interface of applications quickly by screen painting. The advent of fourth generation application building environments enabled developers to adopt the iterative techniques of prototyping to the development of system functions as well as the user interface. RAD tools encourage the tailoring of existing application building blocks instead of designing and coding unique applications. The applications that are produced in this way tend to be inefficient in their use of IT hardware but the falling cost and increasing power of hardware has reduced the importance of efficiency in favour of quick, effective solutions. The RAD philosophy is based on several key assumptions: it is impossible to specify requirements accurately without iteration; the application is its own model; design and testing are iterative processes; the application is always complete, but never finished; empowerment of users is crucial to the development of effective information systems management should concentrate on specifying targets in terms of what should be achieved and let their staff determine how to meet the targets. RAD Methods : RAD can be seen to be a complete approach to information system

2.70 Information Systems Control and Audit development in that it covers the entire information systems development lifecycle, from initiation through to delivery. RAD is more of a philosophy than a precise science. The methods currently available include: the James Martin method (one of the first methods); and the Dynamic Systems Development Method (DSDM), which was put together by a consortium and made openly available. RAD methods typically combine several sub-methods including project management, quality assurance and software testing. RAD does not proposed the adoption of radical development techniques; it adopts components of traditional design and development techniques as and when they are felt to be useful. RAD components : The fluidity and pragmatism of the approach make it difficult to generalise about RAD. The sections which follow outline some common components. (a). Joint Application Development (JAD) : RAD is characterised by small development teams of between four and eight members. These teams include developers and users and are empowered to make design decisions. The teams combine the developers skills with the users knowledge of the business. The teams are usually expected to come up with fully documented business requirements in three to five days. Further workshops may be scheduled to develop particular aspects of the application. (b). Rapidity of development : Most RAD developments are relatively small scale (based on PC and client server technology) and last a short time (3-6 months). The commonly held view is that projects lasting more than 6 months are likely to be overtaken by changes in the business environment. Hence the need to get systems in place and operational as soon as possible. Two months is seen as being the typical length of a RAD project. RAD practitioners believe that no more than six man-years of development work should be devoted to any particular RAD project. (c). Clean rooms : JAD workshops usually take place away from the normal office environment which is free from any routine work interruptions. Once in the clean rooms the teams concentrate on highly focused problem solving. The clean rooms need to be supplied with appropriate support facilities such as flip-charts, pens, OHP, coffee, computers etc. (iv). Timeboxing : RAD project control involves scoping the project by prioritising and defining delivery deadlines or timeboxes. If projects start to fall behind schedule the requirements are reduced instead of increasing or putting back the deadline. (v). Incremental prototyping: RAD applications are put together or built in an iterative way. The process is commonly known as incremental prototyping. System developers build working models after some initial investigation. The model is shown to and discussed with

System Development Life Cycle Methodology users. Amendments and enhancements are agreed and incorporated into the next model. 2.71 The cycle of inspection, discussion and amendment is repeated several times, each time moving closer to an acceptable system. RAD tools : RAD makes use of latest development tools e.g. 4GLs, GUI builders, DBMS, and CASE tools. These allow developers to build prototypes as they progress. High interactivity, low complexity projects Most RAD projects involve the construction of applications that are highly interactive, have clearly defined user groups and are not computationally complex. RAD techniques are rarely used for large distributed systems. The infrastructure for large scale complex projects is best put in place before the RAD applications are built so that RAD teams can then concentrate on the application without worrying about the underlying infrastructure. One of the potential problems with the widespread use of RAD is the duplication of corporate information and inconsistency in the way that it is held. This problem can be avoided if the corporate database is centrally administered as a resource shared by RAD teams. For this approach to be adopted the core database has to be established before the RAD teams can build applications that interact with it. 2.11 STAGE V: SYSTEM TESTING System-level testing must be conducted prior to installation of an information system. It involves: (a) preparation of realistic test data in accordance with the system test plan, (b) processing the test data using the new equipment, (c) thorough checking of the results of all system tests, and (d) reviewing the results with future users, operators and support personnel. System level testing is an excellent time for training employees in the operation of the IS as well as maintaining it. Typically, it requires 25 to 35 per cent of the total implementation effort. One of the most effective ways to perform system-level testing is to perform parallel operations with the existing system. Parallel operations consist of feeding both systems the same input data and comparing data files and output results. Despite the fact that the individual programs were tested, related conditions and combinations of conditions that were not envisioned are likely to occur. Last minute changes to computer programs are necessary to accommodate these new conditions. For an interactive information system project, the process of running dual operations for both new and old system is more difficult than it is for a batch-processing system, because the new system has no true counterpart in the old system. One procedure for testing the new interactive system is to have several remote input terminals connected on line which are operated by supervisory personnel backed up by other personnel operating on the old system. The outputs are checked for compatibility, and appropriate corrections are made to the on-line computer programs. Once this segment of the new system has proved satisfactory, the entire

2.72 Information Systems Control and Audit terminal network can be placed into operation for this one work. Additional sections of the system can be added by testing in this manner until all programs are operational. During parallel operations, the mistakes detected are often not those of the new system, but of the old. These differences should be reconciled as far as it is feasible economically. Those responsible for comparing the two systems should clearly establish that the remaining deficiencies are caused by the old system. A poor checking job at this point can result in complaints later from customers, top management, salespersons, and others. Again, it is the responsibility of the system developers and analysts to satisfy themselves that adequate time for dual operations has been undertaken for each functional area changed. 2.12 SYSTEMS IMPLEMENTATION The process of ensuring that the information system is operational and then allowing users to take over its operation for use and evaluation is called systems implementation. Implementation includes all those activities that take place to convert from the old system to the new. The new system may be totally new, replacing an existing manual or automatic system or it may be a major modification in an existing system. In either case, proper implementation is essential to provide a reliable system to meet organisational requirements. Successful implementation may not guarantee improvement in the organisation using the new system but improper installation will prevent it. In this chapter we will discuss four aspects of implementation: Equipment installation; Training personnel; Conversion procedures; and Post-implementation evaluation. 2.12.1 Equipment Installation : The hardware required to support the new system is selected prior to the implementation phase. The necessary hardware should be ordered in time to allow for installation and testing of equipment during the implementation phase. An installation checklist should be developed at this time with operating advice from the vendor and system development team. In those installations where people are experienced in the installation of the same or similar equipment, adequate time should be scheduled to allow completion of the following activities: 1. Site Preparation: An appropriate location must he found to provide an operating environment for the equipment that will meet the vendor's temperature, humidity and dust control specifications. It is very important to lay down proper procedures for acquiring and planning space layout in the systems implementation. It would be foolish to be stingy on layout expenses and human environment when so much is spent on system analysis, design and development. A bad layout can not only drastically reduce the productivity of the data

System Development Life Cycle Methodology 2.73 processing department but also that of the entire organisation as a whole. If the system is a microcomputer, little layout and site preparation work is needed. However, the electric lines should be checked to ensure that they are free of static or power fluctuation. It will be better to install a 'clean' line that is not shared by other equipments. In case of a mini computer, or a mainframe, the Project Manager should prepare a rough layout, make cost estimates and get budget approved from the management. Layout planning must be done well in advance in order to permit acquisition for long lead-time items like airconditioning equipments, etc. The following factors should be taken into consideration for space planning: Space occupied by the equipments Space occupied by the people; and Movement of equipment and people. The site-layout should allow ample space for moving the equipment in and setting it for normal operation. Vendors will provide clearance requirement for performing service and maintenance and for air circulation. These requirements must be strictly adhered to otherwise warranties may become void and maintenance discontinued until specifications are met. Carpets etc. should be avoided whenever possible in the computer room since they can create static charge which can cause the introduction of errors in the data or, in some case, accidental erase of data. Highly waxed floors produce the same effect. It is best to have the site preparation completed prior to the delivery of the equipment, since vendors are reluctant to deliver equipment when construction work is still in progress. 2. Equipment installation: The equipment must be physically installed by the manufacturer, connected-to the power source and wired to communication lines if required. 3. Equipment check out: The equipment must be turned on for testing under normal operating conditions. Not only the routine 'diagnostic test' should be run by the vendor, but also the implementation team should devise and run extensive tests of its own to ensure that equipments are in proper working condition. 2.12.2 Training Personnel : A system can succeed or fail depending on the way it is operated and used. Therefore, the quality of training received by the personnel involved with the system in various capacities helps or hinders the successful implementation of information system. Thus, training is becoming a major component of systems implementation. When a new system is acquired which often involves new hardware and software, both users and computer professionals generally need some type of training. Often this is imparted through classes, which are organised by vendor, and through hands-on learning techniques. Training Systems Operators: Many systems depend on the computer-centre personnel, who are responsible for keeping the equipment running as well as for providing the necessary support services. Their training must ensure that they are able to handle all possible

2.74 Information Systems Control and Audit operations, both routine and extra-ordinary. Operator training must also involve the data entry personnel. If the system call for the installation of new equipment, such as a new computer system, special terminals or data-entry equipments, the operators training should include such fundamentals as how to turn the equipment on and use it, and knowledge of what constitute normal operation and use. The operators should also be instructed in what common malfunctioning may occur, how to recognise them, and what steps to take when they arise. As part of their training, operators should be given both a trouble shooting list that identifies possible problems and remedies for them, as well as the names and telephone numbers of individuals to contact when unexpected or unusual problem arise. Training also involves familiarisation with run procedures, which involve working through the sequence of activities needed to use a new system on an on-going basis. User training : User training may involve equipment use, particularly in the case where a micro-computer is in use and the individual involved is both operator and user. In these cases, users must he instructed first how to operate the equipment. User training must also instruct individuals involved in trouble shooting of the system, determining whether the problem is caused by the equipment or software or by something they have done in using the system. Most user training deals with the operation of the system itself. Training in data coding emphasises the methods to be followed in capturing data from transactions or preparing data for decision support activities. Users should be trained on data handling activities such as editing data, formulating inquiries (finding specific records or getting responses to questions) and deleting records of data. From time to time, users will have to prepare disks, load paper into printers, or change ribbons on printers. Some training time should be devoted to such system maintenance activities. If a micro computer or data entry system uses disks, users should be instructed in formatting and testing disks. Training is often seen as a necessary evil by managers. While recognising its importance, many managers have to release employees from their regular job activities so that they can be trained. When managers are actively involved in determining training needs, they are usually more supportive of training efforts. It is generally wise to have managers directly involved in evaluating the effectiveness of training activities because training deficiencies can translate into reduced user productivity level. 2.12.3 Conversion and start-up from Manual to Computerised System: Conversion or changeover is the process of changing from the old system (manual system) to the new system. It requires careful planning to establish the basic approach to be used in the actual changeover. There are many conversion strategies available to the analyst who has to take into account several organisational variables in deciding which conversion strategy to use. There is no single best way to proceed with conversion. It may be noted that adequate planning and scheduling of conversion as well as adequate security are more important for a successful changeover. 2.12.3.1 Conversion strategies: There are five strategies for converting from the old system

System Development Life Cycle Methodology to the new one: 2.75 1. Direct changeover: Conversion by direct changeover means that on a specified date, the old system is dropped and the new system is put into use. Direct changeover can only be successful if extensive testing is done beforehand. An advantage of the direct changeover is that users have no possibility of using the old system other than the new. Adaptation is a necessity. Direct changeover is considered a risky approach to conversion, and disadvantages are numerous. For instance, long delays might ensue if errors occur, since there is no other way to accomplish processing. Additionally, users may resent being forced into using an unfamiliar system without recourse. Finally, there is no adequate way to compare new results with old. 2. Parallel conversion: This refers to running the old system and the new system at the same time, in parallel. This is the most frequently used conversion approach, but its popularity may be in decline because it works best when a computerised system replaces a manual one. Both systems are run simultaneously for a specified period of time and the reliability of results is examined. When the same results are gained over time, the new system is put into use and the old one is stopped. The advantage of running both systems in parallel includes the possibility of checking new data against old data in order to catch any errors in processing in the new system. Parallel processing also offers a feeling of security to users, who are not forced to make an abrupt change to the new system. There are many disadvantages to parallel conversion. These include the cost of running two systems at the same time, and the burden on employees of virtually doubling their workload during conversion. Another disadvantage is that unless the system being replaced is a manual one, it is difficult to make comparisons between output of the new system and the old one. Supposedly, the new system was created to improve on the old one. Therefore, outputs from the systems should differ. Finally, it is understandable that employees who are faced with a choice between two systems will continue using the old one because of their familiarity with it. 3 Gradual conversion: Gradual conversion attempts to combine the best features of the earlier two plans, without incurring the risks. In this plan, the volume of transactions is gradually increased as the system is phased in. The advantages include allowing users to get involved with the system gradually and the possibility of detecting and recovering from the errors without a lot of downtime. Disadvantages of gradual conversion include taking too long to get the new system in place and its inappropriateness for conversion of small, uncomplicated systems. 4 Modular prototype conversion: This approach to conversion uses the building of modular, operational prototypes to change from old systems to new in a gradual manner. As each module is modified and accepted, it is put into use. One advantage is that each module is thoroughly tested before being used. Another advantage is that users are familiar with each

2.76 Information Systems Control and Audit module as it becomes operational. The fact that many times prototypes is not feasible automatically rules out this approach for many conversions. Another disadvantage is that special attention must be paid to interfaces so that the modules being built actually work as a system. 5. Distributed conversion: This refers to a situation in which many installations of the same system are contemplated, such as in banking or in franchises such as restaurants or clothing stores. One entire conversion is done (with any of the four approaches considered already) at one site. When that conversion is successfully completed, other conversions are done for other sites. An advantage of distributed conversion is that problems can be detected (and contained) rather than inflicting them, in succession, on all sites. A disadvantage is that even when one conversion is successful, each site will have its own peculiarities to work through and these must be handled. A contingency approach to deciding on a conversion strategy is recommended-that is, the analyst considers many factors (including the wishes of clients) in choosing a conversion strategy. Obviously, a particular conversion approach is not equally suitable for each system implementation. 2.12.3.2 Activities involved in conversion: Conversion includes all those activities which must be completed to successfully convert from the previous system to the new information system. Fundamentally these activities can be classified as follows: 1. 2. 3. 4. 5. Procedure conversion; File conversion; System conversion; Scheduling personnel and equipment; Alternative plans in case of equipment failure. 1. Procedure conversion: Operating procedures should be completely documented for the new system. This applies to both computer-operations and functional area operations. Before any parallel or conversion activities can start, operating procedures must be clearly spelled out for personnel in the functional areas undergoing changes. Information on input, data files, methods, procedures, output, and internal control must be presented in clear, concise and understandable terms for the average reader. Written operating procedures must be supplemented by oral communication during the training sessions on the system change. Despite many hours of training, many questions will have to be answered during conversion activities. Brief meetings must be held when changes are taking place in order to inform all operating employees of any change initiated. Qualified system personnel must be in the conversion area to communicate and coordinate new developments as they occur. Likewise,

System Development Life Cycle Methodology 2.77 revisions to operating procedures should be issued as quickly as possible. These efforts enhance the chances of successful conversion. Once the new system is completely operational, the system implementation group should spend several days checking with all supervisory personnel about their respective areas. As with every new installation, minor adjustments should be expected. Channels of communication should be open between the systems development team members and all supervisory personnel so that necessary changes can be initiated as conditions change. There is no need to get locked into a rigid system when it would be beneficial for the organisation to make necessary changes. Thus, the proper machinery for making changes must be set in place. 2. File conversion: Because large files of information must be converted from one medium to another, this phase should be started long before programming and testing are completed. The cost and related problems of file conversion are significant whether they involve on-line files (common database) or off-line files. Present manual files are likely to be inaccurate and incomplete where deviations from the accepted format are common. These files suffer from the shortcomings of inexperienced - and, at times, indifferent - personnel whose jobs are to maintain them. Computer generated files tend to be more accurate and consistent. If the existing system is operating on a computer but of different configuration, the formats of the present computer files are generally unacceptable for the new system. Besides the need to provide a compatible format, there are several other reasons for file conversion. The files may require character translation that is acceptable to the character set of the new computer system. Data from floppy disks, magnetic tapes, and comparable media will have to be placed on magnetic disk and/or mass storage files in order to construct an online common database. Also, the rearrangement of certain data fields for more efficient programming may be desired. In order for the conversion to be as accurate as possible, file conversion programs must be thoroughly tested. Adequate control, such as record counts and control totals, should be required output of the conversion program. The existing computer files should be kept for a period of time until sufficient files are accumulated for back up. This is necessary in case the files must be reconstructed from scratch after a "bug'' is discovered later in the conversion routine. 3. System conversion: After on-fine and off-line files have been converted and the reliability of the new system has been confirmed for a functional area, daily processing can be shifted from the existing information system to the new one. A cut-off point is established so that database and other data requirements can be updated to the cut-off point. All transactions initiated after this time are processed on the new system. System development team members should be present to assist and to answer any questions that might develop. Consideration should be given to operating the old system for some more time to permit checking and balancing the total results of both systems. All differences must be reconciled. If necessary,

2.78 Information Systems Control and Audit appropriate changes are made to the new system and its computer programs. The old system can be dropped as soon as the data processing group is satisfied with the new system's performance. 4. Scheduling personnel and equipment: Scheduling data processing operations of a new information system for the first time is a difficult task for the system manager. As users become more familiar with the new system, however, the job becomes more routine. Before the new design project is complete, it is often necessary to schedule the new equipment. Some program will be operational while others will be in various stages of compiling and testing. Since production runs tend to push aside new program testing, the system manager must assign ample time for all individuals involved. This generally means second shift for those working on programs. Once all programs are "on the air", scheduling becomes more exacting. Schedules should be set up by the system manager in conjunction with departmental managers of operational units serviced by the equipment. The master schedule for next month should provide sufficient computer time to handle all required processing. Daily schedules should be prepared in accordance with the master schedule and should include time necessary for reruns, program testing, special non-recurring reports and other necessary runs. In all cases, the schedules should be as realistic as possible since scheduling an interactive system is more difficult than scheduling a batch-processing system. The time required to assign remote batch programs under normal operating conditions in real time is a problem, since the number of interruptions that will occur is generally unknown. Often, the solution is to assign a block of time each day for the operation of remote inputoutput devices. If this arrangement is not feasible, the system manager must look to past experience. When total random and sequential demands are not high, the machine will have sufficient capacity to complete all scheduled work even though batch-processing runs will be extended by random system inquiries. The practice of attaching recording clocks to keep track of the machine time in executing instructions and awaiting instructions is quite common. These allow the manager to study the efficiency of each program and identify problem areas and are helpful in determining how the equipment's cost is to be charged to an organisation's functional areas. For a real-time system, however, recording clocks are of no real value since executive programs run continuously whether or not demands are made for service; the total time for a real-time system has no real meaning. However, information can be accumulated internally by determining the input source and allocating this cost to the respective areas on the monthly departmental statements. Just as the equipment must be scheduled for its maximum utilisation, so must be personnel who operate the equipment. It is also imperative that personnel who enter input data and handle output data be included in the data processing schedule. Otherwise, data will not be

System Development Life Cycle Methodology 2.79 available when the equipment needs it for processing. It is essential that each person follow the methods and procedures set forth by the MIS section; non-compliance with established norms will have an adverse effect on the entire system. 5. Alternative plans in case of equipment failure: Alternative processing plans must be implemented in case of equipment failure. Who or what caused the failure is not as important in case of equipment failure as the fact that the system is down. Priorities must be given to those jobs critical to an organisation, such as billing, payroll, and inventory. Critical jobs can be performed manually until the equipment is set right. Documentation of alternative plans is the responsibility of the computer section and should be fully covered by the organisation's systems and procedures manual. It should state explicitly what the critical jobs are, how they are to be handled in case of equipment failure, where compatible equipment is located, who will be responsible for each area during downtime and what dead-lines must be met during the emergency. A written manual of procedures concerning what steps must be undertaken will help expedite the unfavourable situation. Otherwise, panic will result in the least efficient methods when time is of the essence. Postimplementation Review : A Post Implementation review answers the questions did we achieve what we set out to do in business terms? And if not, what should be done? Much of what an IT project sets out to achieve will not become apparent until well after system implementation. Teething problems are inevitable, while the users, system support staff, and external service providers will need time to reach their optimum performance. Some types of problems (latent defects) also take time to appear. A further review, the Post Implementation Review, is therefore carried out between 6 to 12 months after system implementation, unless there are special circumstances. It is much broader in scope than the Project Closure Review and aims to measure the extent to which the objectives of the Business Case have been met and to make recommendations designed to optimise project benefits. The Review does not examine the new system exclusively - its manner of use and supporting environment are also important - although this will form a major element. The specific aims of a Post Implementation Review are to: evaluate the project teams achievements against the original objectives set out in the Business Case; measure and compare actual system performance against that specified; compare actual incurred project costs against the original estimated costs, and make revised cost projections; learn for the future in order to avoid repeating mistakes. As mentioned earlier that post implementation review measures and compares actual system

2.80 Information Systems Control and Audit performance against that specified . There are two basic dimensions of information systems that should be evaluated. The first dimension is concerned with whether the newly developed system is operating properly. The other dimension is concerned with whether the user is satisfied with the information system with regard to the reports supplied by it. Development evaluation: Evaluation of the development process is primarily concerned with whether the system was developed on schedule and within budget. This is a rather straightforward evaluation. However, it requires schedules and budgets to be established in advance and that records of actual performance and cost be maintained. However, it may be noted that very few information systems have been developed on schedule and within budget. In fact, many information systems are developed without clearly defined schedules or budgets. Due to the uncertainty and mystique associated with system development, they are not subjected to traditional management control procedures. 2.12.4.2 Operation evaluation: The evaluation of the information system's operation pertains to whether the hardware, software and personnel are capable to perform their duties and they do actually perform them so. Operation evaluation answers such questions: 1. 2. 3. 4. 5. 6. Are all transactions processed on time? Are all values computed accurately? Is the system easy to work with and understand? Is terminal response time within acceptable limits? Are reports processed on time? Is there adequate storage capacity for data? Operation evaluation is relatively straightforward if evaluation criteria are established in advance. For example, if the systems analyst lays down the criterion that a system which is capable of supporting one hundred terminals should give response time of less than two seconds, evaluation of this aspect of system operation can be done easily after the system becomes operational. Preparation for the Post Implementation Review must begin during project initiation. In order for achievement to be measured it is necessary to set targets and to collect appropriate data before, during and after the project. If this is not done there will be no performance data or and a datum line to measure it against. If the review reveals that benefits are not being achieved to the extent originally planned, it will be necessary to find out why this is so. Can modifications be made to solve the problem, or were the original projections based on unsound assumptions? Have the requirements of system users changed to a degree which renders the original objectives of the system less relevant than they were in the original proposal? These and similar questions should be asked by the review team to determine whether existing plans for the system require modification; or

System Development Life Cycle Methodology 2.81 even, in extreme cases, whether the system should be abandoned for a completely different approach. The prime objective should always be to understand how best to move forward from the current position, rather then merely to understand the historical reasons for failure. The report will be presented to top management who must then decide to: endorse continuation of the system; approve plans to modify the system; terminate the system and make arrangements for a new course of action. 2.12.4.3 Information evaluation: An information system should also be evaluated in terms of information it provides. This aspect of system evaluation is difficult and it cannot be conducted in a quantitative manner, as is the case with development and operation evaluations. The objective of an information system is to provide information to support the organisational decision system. Therefore, the extent to which information provided by the system is supportive to decision making is the area of concern in evaluating the system. However, it is practically impossible to directly evaluate an information system's support for decision making in an organisation. It must be measured indirectly. A viable approach for indirectly measuring and evaluating the information provided by the system has been proposed by Richard L. Nolan and Henery H. Seward. Their approach is based on the concept that the more frequently a decision maker's information needs are met by a system, the more satisfied he tends to be with the system. Conversely, the more frequently necessary information is not available, the greater are the efforts required to obtain the necessary information, and hence, there will be greater dissatisfaction with the information system. Thus, satisfaction can be used as a measure to evaluate the information provided by an information system. Measurement of user satisfaction can be accomplished using the interview and questionnaire technique discussed earlier. If management is generally satisfied with an information system, it is assumed that the system is meeting the requirements of the organisation. If management is not satisfied, modifications ranging from minor adjustments to complete redesign may be required. 2.13 SYSTEMS MAINTENANCE Most information systems require at least some modification after development. The need for modification arises from a failure to anticipate all requirements during system design and/or from changing organisational requirements. The changing organisational requirements continue to impact most information systems as long as they are in operation. Consequently periodic systems maintenance is required for most of the information systems. Systems maintenance involves adding new data elements, modifying reports, adding new reports, changing calculations, etc. Maintenance can be categorised in the following two ways: 1. Scheduled maintenance is anticipated and can be planned for. For example, the

2.82 Information Systems Control and Audit implementation of a new inventory coding scheme can be planned in advance. 2. Rescue maintenance refers to previously undetected malfunctions that were not anticipated but require immediate solution. A system that is properly developed and tested should have few occasions of rescue maintenance. One problem that occurs in systems development and maintenance is that as more and more systems are developed, a greater portion of systems analyst and programmer time is spent on maintenance. An information system may remain in an operational and maintenance mode for several years. The system should be evaluated periodically to ensure that it is operating properly and is still workable for the organisation. When a system becomes obsolete i.e. new opportunities in terms of new technology are available or it no longer satisfies the organisation's needs, the information system may be replaced by a new one generated from a fresh system development process. 2.14 ORGANIZATIONAL STRUCTURE OF IT DEPARTMENT We will now give a brief introduction about the management structure of IT department. 2.14.1 Management Structure Line management Management Project management Line management Structure:The information system management subsystems in an organization attempt to ensure that the development, implementation, operation and maintenance of information systems proceed in a planned and controlled manner. They function to provide a stable environment in which information systems are built and operated on a day-to-day basis. Several levels of management subsystems have been identified corresponding to the organisation hierarchy and major functions performed within a data processing installation.

System Development Life Cycle Methodology 2.83 Top Management IS Management Systems Development Management Programming Management Data Administration Security Administration Operations Management Quality assurance management Figure 18 Top Management: Top management of the organisation must ensure that the data processing installation is well managed. It is responsible primarily for long run policies decisions on how computers will be used in the organization. IS Management : IS management has overall responsibility for planning and control of all computer activities. It also provides inputs to top managements long run policy decision making and translates long run policies into short run goals and objectives. Systems Development Management : Systems Development Management is responsible for

2.84 Information Systems Control and Audit the design, implementation and maintenance of application systems. Programming Management : Programming management is responsible for programming new systems, maintaining old systems and providing general systems support software. Data administration : Data administration is responsible for the control and use of an organisations data including the database and library of application system files. Security administration : Security administration is responsible for the physical security of the data processing and IS programs. Operations Management : Operations Management controls the day-to-day operations of data processing systems. It is responsible for data preparation; the data flow through the installation, production running of systems, maintenance of hardwasre and sometimes maintenance of program and file library facilities. Quality assurance management : Quality assurance management undertakes an in-depth quality assurance review of data processing in each application system. This review involves a detailed check of the authenticity, accuracy and completeness of input, processing and output. 2.14.2 Project Management Structure : In project management, project requests are submitted to and prioritized by the steering committee. The project manager, who may be a non-IS staff member, should be given complete operational control of the project and be allocated the appropriate resources for the successful completion of the project. IS auditors may be included in the project team as control advocates and experts. They also provide an independent, objective review to ensure that the level of commitment of the responsible parties is appropriate. IS Manager Accounting Production Operations Systems Analysis Programming Figure 19

System Development Life Cycle Methodology Duties and Responsibilities : The structure of an IT Department is divided into two main areas of activity: 1. Information processing. 2. System development and enhancement. 2.85 Information Processing or IP is primarily concerned with the operational aspect of the informationprocessing environment and often includes computer operations, systems programming, telecommunications and librarian functions. System development is concerned with the development, acquisition and maintenance of computer application systems and performs systems analysis and programming functions. Data entry : The data entry supervisor is responsible for ensuring whether the data is authorized, accurate and complete when entered into the system. Components in the input subsystem are responsible for bringing information into a system. The information takes two forms: first, it may be raw data to be processed and perhaps applied against the database; second, it may be instructions to direct the system to execute particular processes, updater or interrogate particular data, or prepare particular types of output. Both types of information input must be validated. Any errors detected must be controlled so that the input resubmission is authentic, accurate, complete, unique and timely. File Library : The file librarian is responsible for recording, issuing, receiving and safeguarding all programs and data files that are maintained on computer tapes or disks in an IPF. Managing the organisations library of machine-readable files involves three functions. First, files must be used only for the purposes intended. Control must be exercised over program files, data files and procedure files. Second, the storage media used for files must be maintained in correct working order. Third, a file backup strategy and file retention strategy must be implemented. Within the IT department, responsibility for managing files is vested in a file library section. It is a substantial management problem to ensure correct control and use of these files. A basic prerequisite for effective and efficient management is an orderly filing system. The filing system must encompass procedures for storing and retrieving the files, storage media and maintaining records of events that occur to the files and storage media. Files should be stored in a secure room adjacent to or near the computer room to facilitate the issue of files for processing and their return upon completion of processing. Like the computer room, the file storage room must have a stable environment, constant temperature, no dust, etc. Many types of cabinets are available for secure storage of files. Files should be issued only in accordance with a predetermined application system schedule or on the basis of an authorised requisition. In the case of the authorized daily run schedule,

2.86 Information Systems Control and Audit the file librarian retrieves the files, transports them to the computer room, and collects them periodically after the application systems have been run. In all other cases file librarians must check that a person who requests a file is authorized to use the file; they must then issue the file only if that person has an authorized requisition. Otherwise, improper modifications may be made to programs, data or procedure files. To keep a record of all events that occur to files, a log must be maintained. Control Group: The control group manages the flow of data and is responsible fore the collection, conversion and control of input, and balancing the distribution of output to the user community. The input/output control group should be in a separate area where only authorized personnel are permitted. The supervisor of the control group usually reports to the IPF operations managers. Operations: Operations management is responsible for the daily running of hardware and software facilities so that the production application system can accomplish their work and development staff can design, implement and maintain systems. Though there are some variations across the organisations, the operations group within the IT department undertakes seven major functions. Computer operations. Communication network control. Data preparation Production work flow control File library Documentation library Performance monitoring. In some ways, the functions of operations management appear routine and mundane. If they are not carried out properly, however, some serious consequences can occur. For example, well-designed program controls can be compromised if an operator uses a console terminal to alter the state of the computer internal memory; well-designed program code will execute inefficiently if there is an undesirable job mix in the machine. Security Administration: The security administrator in a data processing organization is responsible for matters of physical security. In other words, the security administrator attempts to ensure that the physical facilities in which the systems are developed, implemented, maintained and operated are safe from threats that affect the continuity of operation. In small organizations that use turnkey systems that is, hardware and software that have been purchased as a package rather than developed in house there may be no data processing staff and as a consequence, no one to assume the role of security administrator.

System Development Life Cycle Methodology 2.87 If an organization has its sown data processing staff but insufficient work exists to justify an ongoing, separate security administrator position, responsibility for security matters may be vested in the operations manager. Since, the operation manager is responsible fore the dayto-day running of hardware and software systems, physical control over these facilities seems a natural extension of these responsibilities. In large organisations there may be sufficient work to justify a separate security administration position. In some cases, the security administrator may report directly to the data processing manager or to the executive in charge of information systems in the organization. In other cases, computer security administrator may report to an executive who assumes overall responsibility for all security matters with the organization. Physical Security :A complete reliable protection scheme must take into account the possibility of physical attacks on the database, ranging from disclosure of a password to theft of the physical storage devices. We can protect well by encrypting data. A high security system needs better identification than a password, such as personal recognition of the user by a guard. Data Security : Database management systems often provide controls over data definition and data manipulation facilities. In environments, which combine database management with online transaction processing, access to the database objects such as tables or views can be controlled through internal database mechanisms, which limit what the transaction or program, can do. Various auditing or journaling are also available. Utility access and submission, as well as monitoring and performance tools, should be restricted to appropriate personnel. More details are available in Chapter 9. Conducting a security program :A security program is a series of ongoing, regular, periodic evaluations conduced to ensure that the physical facilities of an Information System are safeguarded adequately. The first security evaluation conducted may be a major exercise; the security administrator has to consider an extensive list of possible threats to the organisation, prepare an inventory of assets, evaluate the adequacy of controls, implement new controls, etc. Subsequent security evaluations may focus only on changes that have occurred, perhaps in light of the purchase of new hardware or a new threat etc. Nevertheless, even in the absence of visible changes, security evaluations need to be repeated periodically to determine whether covert changes have occurred that necessitate modifications to controls. Various steps involved are : Preparation of a project plan Identification and valuation of assets Threats identification Exposure analysis

2.88 Information Systems Control and Audit Controls adjustment Report preparation. Production Work Flow Control: Production workflow control in an IS, is the responsibility of a control section. The control section manages the flow of data between users and he information system, and between data preparation and the computer room. If a separate control section is set up. It is also more difficult for operators and data preparation personnel to collude and to perpetrate a fraud for example, by alerting input data. Organisation User Data preparation Data processing Control section Computer room Service Bureau Figure 20 Quality Assurance : QA group is responsible for testing and verifying whether the programs, program changes and documentation adhere to standards and naming conventions before the programs are moved into production. The control section facilitates the orderly flow of data. A typical section starts with the receipt of input for some application system from users. The control section checks to see that this input is in order by scanning it for reasonableness and completeness and by checking control totals. If the input passes this quality assurance check, it is entered into a log and dispatched either to the computer room if it is already in machine-readable form or to data preparation if it

System Development Life Cycle Methodology must be keyed to cards, tape or disk. 2.89 Once data preparation is complete, the control section collects the source data and machinereadable data and checks to see if all data for the production have been prepared. It also may be responsible for preparing any job control language parameters needed for the run. While job control language commands that remains constant should be stored on a secure procedures file and involved at application system run time, others have to be prepared prior to processing since they vary from run to run. For example, the parameters specifying the job priority or expected run time may need to be altered. The machine-readable data and job control language commands are then dispatched to the computer room for processing. Systems Analysis: System analysts are responsible for interpreting the needs of the user, determining the programs and the programmers necessary to create the particular application. System analysts design systems based on the needs of the user. For the auditor acting as a participant in the system development process, the information processing system design phase is one of major involvement. From a system effectiveness viewpoint the auditor is concerned with whether the design meets strategic requirements. From efficiency viewpoint the auditor is concerned with the resources that will be needed to run the system. From safeguarding access and data integrity viewpoint the auditor is concerned with the controls designed into the system. During this phase the auditor also evaluates the ongoing auditability of the system. The auditor may deem it necessary to build certain audit capabilities into the system in the form of audit modules. These modules capture data or examine conditions of interest to the auditor concurrently with production running of the system. When evaluating the information processing system design phase, either as a participant in the design process or in an ex post review capacity, the auditor must examine six major activities: Elicitation of detailed requirements Design of the data/information flow Design of the database Design of the user interface Physical design Design of the hardware/software configuration. These activities may vary considerably depending on the type of system being designed and implemented. Applications Programming : Applications programmers are responsible for developing new systems and for monitoring systems in production. They should work in a test only environment and should not move test versions into the production environment. Application programmers should not have access to system program libraries.

2.90 Information Systems Control and Audit Systems programming: System programmers are responsible for maintaining the systems software including the operating systems. Both the nature of system software and systems programming activities present control problems for management. System software is shared system resource; thus, errors or irregularities in the software may be propagated through any application systems that use it. Furthermore, system software often must operate in a privileged mode if it is to be able to perform its functions. This privileged status can be abused. For example, system software might be used to gain unauthorised access to private data that can be sold to competitors or to allow jobs to execute without being charged for resource consumption via the normal job accounting software. In the latter case, for example, system programmers may be carrying out private consulting activities and using the machine as a free resource. Controlling system programmers is a difficult task. They are highly skilled individuals who often work alone or in small groups. Thus, it is difficult to exercise traditional control over their activities, such as separation of duties and independent checks on performance. Moreover, they often work in crisis situations where the need to get a job running overrides the need to maintain established control procedures. For example, the communication software may crash during a peak load period and a system programmer may be required to device a fix so terminals can be reactivated and customers once again can be serviced. Local Area Network (LAN) Administration: LAN administrator is responsible for technical and administrative control over the local area network. This includes ensuring transmission links are functioning correctly, backups of the system are occurring and software/hardware purchases are authorized and properly installed. In smaller installations, this person may be responsible for security administration over the LAN. The LAN administrator should have no application responsibilities, but may have end-user responsibilities. The LAN administrator may report to the director of the IPF and in a decentralized operation, he can report to the end-user manager. Help Desk Administration: The Help Desk Administrator is responsible for monitoring, improving and controlling system performance in mainframe and client/server hardware and software. The Help Desk Administration may be useful when data entry is not based upon a dedicated source document. If users are uncertain about the nature or format of the data to be entered into a particular field, they may ask the system to provide information to assist them. This information might give a more complete explanation of the data item and the format for the entry of a particular value. It may also describe the validation rules that apply to the item. The Help Desk facility is especially important if inexperienced or novice users will submit data to the system. In todays IS environment it is important to have a technical administration help desk function that specializes in operating system enhancement techniques used by systems programming. Self-examination Questions 1. What is systems development process?

System Development Life Cycle Methodology 2. 3. 4. 5. 6. 7. 8. 9. What activities are part of the systems development life cycle (SDLC)? Discuss various approaches to systems development. 2.91 What types of systems are best for development by the traditional approach? What types of systems by prototyping approaches? What types by end user development? Differentiate between the topdown and bottom-up approaches to systems development. How is systems development handled in smaller organisations? What is the purpose of a preliminary investigation? What outcome is expected from it ? Who caries out this investigation? What do you mean by feasibility study? How is it conducted? What systems costs are estimated during feasibility study for various alternative solutions? 10. Discuss various tangible and intangible benefits that can result from the development of a computerised system? 11. What is systems requirement analysis? How are requirements determined? 12. Discuss various fact finding techniques. 13. What role does observation play in system investigation? 14. Discuss, in detail, how the investigation of present system is conducted by the system analyst. 15. What are the major categories of systems development tools? 16. What is a data flow diagram (DFD)? Give an example of a DFD. 17. What do you understand by the term 'CASE tools"? Briefly describe various CASE tools. 18. What is a data dictionary? What are its uses? 19. What objectives guide the systems analyst in designing an information system? 20. Distinguish between logical design and physical design. 21. What are the important factors to be considered while designing an output report from an information system? 22. What are the different formats in which information can be presented? Discuss briefly, various guidelines to be followed while deciding the information contents under these formats. 23. What guidelines should be followed while preparing the layout form of (i) printed output, (ii) visual display unit. 24. What do you understand by the term "window'? In which application areas, use of windowing capability can be considered? 25. Discuss various issues that should be considered while designing systems input? 26. Discuss, in detail, the guidelines that should be observed in designing an input form?

2.92 Information Systems Control and Audit 27. Why coding system is required in an information system? What are the desired characteristics of a good coding scheme? 28. What is a system manual? What information is included in it? 29. What factors should be considered in equipment selection? 30. What are the different sources of acquiring software? 31. Briefly discuss the advantages of using application software. 32. Explain how the following activities relate to system design phase and system acquisition phase : 33. Preparation of RFP 34. Selection of Vendors proposed computer system. 35. What basic features should he ascertained by the systems analyst before purchasing packaged software? 36. Briefly describe the criteria for vendors selection for a computer system. 37. Discuss some of the methods for validating vendors proposal for a computer system. 38. Discuss various stages through which an in-house creation of program has to pass. 39. What is the meaning of the term program debugging? 40. Program debugging is very crucial for the success of a program. Do you agree with this statement? Give reasons. 41. Discuss some of the program design tools available. 42. Briefly describe various steps involved in system testing. 43. Describe the types of activities that make up the system implementation phase of development. 44. Describe various steps that should be taken for the successful installation of the equipment. 45. Why is personnel training important? What type of training should be imparted to systems operators, (ii) users? 46. In what different ways could system conversion take place? Explain. 47. Describe briefly, various activities that should be completed for successful conversion of an existing system to the new information system. 48. What is the purpose of system evaluation? How is it performed? 49. What do you understand by the term systems maintenance? (i)

3 CONTROL OBJECTIVES 3.1 NEED FOR CONTROL Everyone is aware of the need for information security in today's highly networked business environment. Information is arguably among an enterprise's most valuable assets, so its protection from predators from both within and outside has taken center stage as an IT priority. Hence, there is a need to institute strong control environment. Information System Audit and Control Association (ISACA) has long recognized the importance of information security and control and offers a wide range of products and services on the topic. Most significantly, in 2002 ISACA introduced the Certified Information Security Manager (CISM) certification, recognizing the special role played by those who manage an enterprise's information security program. Organizations today face an increasingly complex work environment where security measures that were adequate even two years ago no longer meet regulatory mandates. Changing landscape of security suggests areas where businesses should re-examine their processes and adequate control methods to be introduced. Organizations need to be protected from both known and unknown threats, and all the varieties and forms that sophisticated malicious software (commonly known as computer virus) can take. Every IT service depends on an integrated "Stack" of systems such as applications, databases, middleware, directory services, operating systems and networks. It is important to know how to implement the controls necessary to build an effective change management process, and how to foster a culture of accountability. Businesses today are under intense pressure to open up their networks, comply with increasingly rigorous regulatory requirements, and ensure their IT assets are protected from attacks. 3.2 EFFECT OF COMPUTERS ON INTERNAL AUDIT Since the 1970s, around the world there has been a large increase in the number of organisations using computers to process transactions and prepare their financial statements.

3.2 Information Systems Control and Audit The move towards more automated financial systems has had an impact in the way auditors carry out their work. The impact can be summarised under four main headings: (i). changes in the audit trail and audit evidence; (ii). change in the internal controls environments; (iii). new opportunities and mechanisms for fraud and error; and (iv). new audit procedures. Each of these effects are discussed in these notes. (i). Changes in the audit trail and audit evidence : The existence of an audit trail is a key financial audit requirement, since without an audit trail, the financial auditor may have extreme difficulty in gathering sufficient, appropriate audit evidence to validate the figures in the clients accounts. (a). Data retention and storage : A clients storage capabilities may restrict the amount of historical data that can be retained on-line and readily accessible to the auditor. If the client has insufficient data retention capacities the auditor may not be able to review a whole reporting periods transactions on the computer system. For example, the clients computer system may save on data storage space by summarising transactions into monthly, weekly or period end balances. If the client uses a computerised financial system all, or part of the audit trail may only exist in a machine readable form. Where this is the case, the auditor may have to obtain and use specialised audit tools and techniques which allow the data to be converted and interrogated. Computerised financial data is usually stored in the form of 1s and 0s, i.e. binary, on magnetic tapes or disks. It is not immediately obvious to the auditor what the 1s and 0s mean. The data must be translated into normal text by an additional process before it can be read and understood by the auditor. Since there are various formats for representing electronic data the auditor must find out what format the client has used, e.g. simple binary, hexadecimal, ASCII or EBCDIC, etc. For example, the character A has a decimal have of 65 in ASCII, which can be stored as 1000001 in binary, or 41 in hexadecimal. The representation of client data is covered in the INTOSAI IT audit training module Data downloading. When a client gives the auditor a magnetic tape containing transaction details, the data is not readily accessible. Unlike receiving a printed transaction listing, the auditor cannot just pick up a magnetic tape and read off the transactions. The data on the disk or tape may be in a different format and hence may require conversion and translation. Once the data has been uploaded onto the auditors machine audit software may be required to interrogate the information. (b). Absence of input documents : Transaction data may be entered into the computer directly without the presence of supporting documentation, e.g. input of telephone orders into

Control Objectives 3.3 a telesales system. The increasing use of EDI will result in less paperwork being available for audit examination. (c). Lack of a visible audit trail: The audit trails in some computer systems may exist for only a short period of time. The absence of an audit trail will make the auditors job very difficult and may call for an audit approach which involves auditing around the computer system by seeking other sources of evidence to provide assurance that the computer input has been correctly processed and output. (d). Lack of visible output: The results of transaction processing may not produce a hard copy form of output, i.e. a printed record. In the absence of physical output it may be necessary for the auditor to directly access the electronic data retained on the clients computer. This is normally achieved by having the client provide a computer terminal and being granted read access to the required data files. (See chapter 9 for an explanation of access permissions such as read). (e). Audit evidence. Certain transactions may be generated automatically by the computer system. For example, a fixed asset system may automatically calculate depreciation on assets at the end of each calendar month. The depreciation charge may be automatically transferred (journalised) from the fixed assets register to the depreciation account and hence to the clients income and expenditure account. Where transactions are system generated, the process of formal transaction authorisation may not have been explicitly provided in the same way as in a manual environment, i.e. each transaction is not supported by the signature of a manager, supervisor or budget holder. This may alter the risk that transactions may be irregular or ultra vires. Where human intervention is required to approve transactions the use of judgement is normally required. Judgement is a feature which computers are generally not programmed to demonstrate. (f). Legal issues : The use of computers to carry out trading activities is also increasing. More organisations in both the public and private sector intend to make use of EDI and electronic trading over the Internet. This can create problems with contracts, e.g. when is the contract made, where is it made (legal jurisdiction), what are the terms of the contract and are the parties to the contract. The admissibility of the evidence provided by a clients computer system may need special consideration. The laws regarding the admissibility of computer evidence varies from one country to another. Within a country laws may even vary between one state and another. If the auditor intends to gather evidence for use in a court, s(he) should firstly find out what the local or national laws stipulate on the subject. In addition, the admissibility of evidence may vary from one court to another. What is applicable is a civil court may not be applicable in a criminal court.

3.4 Information Systems Control and Audit (ii). Change in the type and nature of internal controls : The internal controls within a clients financial systems, both manual and computerised, can be divided into several categories. Personnel : Whether or not staff are trustworthy, if they know what they are doing and, if they have the appropriate skills and training to carry out their jobs to a competent standard. Segregation of duties : a key control in any financial system. Segregation basically means that the stages in the processing of a transaction are split between different people, such that one person cannot process a transaction through from start to finish. The various stages in the transaction cycle are spread between two or more individuals. Authorisation procedures : to ensure that transactions are approved. In some on-line transaction systems written evidence of individual data entry authorisation, e.g. a supervisors signature, may be replaced by computerised authorisation controls such as automated controls written into the computer programs (e.g. programmed credit limit approvals). Record keeping: the controls over the protection and storage of documents, transaction details, audit trails etc. Access to assets and records: In the past manual systems could be protected from unauthorised access through the use of locked doors and filing cabinets. Computerised financial systems have not changed the need to protect the data. A clients financial data and computer programs are vulnerable to unauthorised amendment at the computer or from remote locations. The use of wide area networks, including the Internet, has increased the risk of unauthorised access. The nature and types of control available have changed to address these new risks. Management supervision and review: Managements supervision and review helps to deter and detect both errors and fraud. The next issue to consider is how these basic types of controls differ in a computerised environment. For example: (a). Segregation of duties: Segregation of duties in a computerised system is different from segregation of duties in a manual system. In the manual accounting system, the auditor was primarily concerned with segregation of duties in the finance department. However, in a computerised system, the auditor should also be concerned with the segregation of duties within the IT department. Within an IT environment, the staff in the computer department may be the only client staff with a detailed knowledge of the interrelationship between the source of data, how it is processed and distribution and use of output. It is possible that the clients IT personnel will be aware of any control weaknesses which exist. It staff may also be in a position to alter transaction data or even the financial applications which process the transactions. This gives them the knowledge and means to alter data, all they would then require is a motive.

Control Objectives 3.5 (b). Concentration of programs and data : Transaction and master file data (e.g. pay rates, approved suppliers lists etc.) may be stored in a computer readable form on one computer installation or on a number of distributed installations. Computer programs such as file editors are likely to be stored in the same location as the data. Therefore, in the absence of appropriate controls over these programs and utilities, there is an increased risk of unauthorised access to, and alteration of financial data. The computer department may store all financial records centrally. For example, a large multinational company with offices in many locations may store all its computer data in just one centralised computer centre. In the past, the financial information would have been spread throughout a clients organisation in many filing cabinets. If a poorly controlled computer system was compared to a poorly controlled manual system, it would be akin to placing an organisations financial records on a table in the street and placing a pen and a bottle of correction fluid nearby. Without adequate controls anyone could look at the records and make amendments, some of which could remain undetected. (iii). New causes and sources of error (a). System generated transactions : Financial systems may have the ability to initiate, approve and record financial transactions. This is likely to become increasingly common as more organisations begin to install expert systems and electronic data interchange (EDI) trading systems. The main reason clients are starting to use these types of system is because they can increase processing efficiency ( for example, if a computer system can generate transactions automatically there will be no need to employ someone to do it manually, and hence lower staff costs). Automated transaction processing systems can cause the auditor problems. For example when gaining assurance that a transaction was properly authorised or in accordance with delegated authorities. The auditor may need to look at the applications programming to determine if the programmed levels of authority are appropriate. Automated transaction generation systems are frequently used in just in time (JIT) inventory and stock control systems: When a stock level falls below a certain number, the system automatically generates a purchase order and sends it to the supplier (perhaps using EDI technology). (b). Systematic Error : Computers are designed to carry out processing on a consistent basis. Given the same inputs and programming, they invariably produce the same output. This consistency can be viewed in both a positive and a negative manner. If the computer is doing the right thing, then with all other things being equal, it will continue to do the right thing every time. Similarly, if the computer is doing the wrong thing and processing a type of transaction incorrectly, it will continue to handle the same type of transactions incorrectly every time. Therefore, whenever an auditor finds an error in a computer processed

3.6 Information Systems Control and Audit transaction, s(he) should be thorough in determining the underlying reason for the error. If the error is due to a systematic problem, the computer may have processed hundreds or thousands of similar transactions incorrectly (iv). New audit processes : Within a computerised environment the auditor may be required to adopt a different audit approach to gain sufficient audit evidence to provide an opinion on the financial statements. For example, new procedures to cope with different internal controls, new causes of errors or the different nature of audit trails. The new audit processes and procedures may include the use of computer assisted audit techniques (CAATs). 3.3 RESPONSIBILITY OF CONTROLS Management is responsible for establishing and maintaining control to achieve the objectives of effective and efficient operations, and reliable information systems. Management should consistently apply the internal control standards to meet each of the internal control objectives and to assess internal control effectiveness. The information system managers must take systematic and proactive measures to (i). Develop and implement appropriate, cost-effective internal control for resultsoriented management; (ii). Assess the adequacy of internal control in programs and operations; (iii). Separately assess and document internal control over information systems consistent with the information security policy of the organisation (iv) Identify needed improvements; (v) Take corresponding corrective action; and (vi) Report annually on internal control through management assurance statements. 3.4 COST EFFECTIVENESS OF CONTROL PROCEDURE No internal control system can provide foolproof protection against all internal control threats. The cost of a foolproof system would be prohibitive. In addition, because many controls negatively affect operational efficiency, too many controls slow the system and make it inefficient. Therefore, the objective in designing an internal control system is to provide reasonable assurance that control problems do not take place. The benefit of an internal control procedure must exceed its cost. Costs are easier to measure than benefits, however. The primary cost element is personnel, including the time to perform control procedures, the costs of hiring additional employees to achieve effective segregation of duties, and the costs of programming controls into an information system. Internal control benefits stem from reduced losses. One way to calculate benefits involves expected loss, the mathematical product of risk and exposure.

Control Objectives 3.7 The benefit of a control procedure is the difference between the expected loss with the control procedure(s) and the expected loss without it. Determine Cost-Benefit Effectiveness : After estimating benefits and costs, management determines if the control is cost beneficial. For example, at one of the multinational company, data errors occasionally required the entire payroll to be reprocessed, at a cost of $ 10,000. Management determined that a data validation step would reduce error risk from 15 per cent to 1 per cent, at a cost of $600 per pay period. The cost-benefit analysis that management used to determine if the validation step should be employed is shown in Table 1. Table 1 Without Validation Procedure Cost to reprocess entire payroll Risk of payroll data errors Expected reprocessing cost ($ 10,000 risk) Cost of validation procedure Net expected benefit of validation procedure $ 1,500 $0 $ 100 $ 600 $ 1,400 $ (600) $ 800 $ 10,000 15% With Validation Procedure $ 10,000 1% Net Expected Difference If the proposed payroll validation procedure is not utilised, then the expected loss to the company is $1,500. Because the expected loss with the validation step is $100, the control provides an expected benefit of $1,400. After deducting the control costs of $600, the validation step provides a net benefit of $800 and clearly should be implemented. In evaluating the costs and benefits of control procedures, management must consider factors other than those in the expected benefit calculation. For example, if an exposure threatens an organisations existence, it may be worthwhile to spend more than indicated by the costbenefit analysis to minimize the possibility that the organization will perish. This extra cost can be viewed as a catastrophic loss insurance premium. 3.5 CONTROL OBJECTIVES FOR INFORMATION RELATED TECHNOLOGY(COBIT) The Information Systems Audit and control Foundation (ISACF) developed the Control Objectives for Information and related Technology (COBIT). COBIT is a framework of generally applicable information systems security and control practices for IT control. The framework allows

3.8 Information Systems Control and Audit (1) management to benchmark the security and control practices of IT environments, (2) users of IT services to be assured that adequate security and control exist, and (3) auditors to substantiate their opinions on internal control and to advise on IT security and control matters. The framework addresses the issue of control from three vantage points, or dimensions: 1. Business Objectives. To satisfy business objectives, information must conform to certain criteria that COBIT refers to as business requirements for information. The criteria are divided into seven distinct yet overlapping categories that map into the COSO objectives: effectiveness (relevant, pertinent, and timely), efficiency, confidentiality, integrity, availability, compliance with legal requirements, and reliability. IT resources, while include people, application systems, technology, facilities, and data. IT processes, which are broken into four domains: planning and organization, acquisition and implementation, delivery and support, and monitoring. 2. 3. COBIT, which consolidates standards from 36 different sources into a single framework, is having a big impact on the information systems profession. It is helping managers learn how to balance risk and control investment in an information system environment. It provides users with greater assurance that the security and IT controls provided by internal and third parties are adequate. It guides auditors as they substantiate their opinions and as they provide advice to management on internal controls. COBIT is discussed in detail in Chapter 8 of the Study material. 3.6 INFORMATION SYSTEMS CONTROL TECHNIQUES The basic purpose of information system controls in an organization is to ensure that the business objectives are achieved and undesired risk events are prevented or detected and corrected. This is achieved by designing and effective information control framework, which comprise policies, procedures, practices, and organization structure that gives reasonable assurances that the business objectives will be achieved. When reviewing a clients control systems, the auditor will be able to identify three components of internal control. Each component is aimed at achieving different objectives. The information system auditor will be most familiar with: Accounting controls, i.e. those controls which are intended to safeguard the clients assets and ensure the reliability of the financial records; Operational controls: These deal with the day to day operations , functions and activities to ensure that the operational activities are contributing to business objectives; Administrative controls : These are concerned with ensuring efficiency and compliance with management policies, including the operational controls. The other two types of control likely to be encountered are :

Control Objectives 3.9 3.6.1 Auditors categorisation of controls : When we look at financial or accounting controls we examine them to see if they reduce the likelihood of the financial statements containing material errors. We put the controls into categories depending on when they act. We categorise the controls into following four groups: (i). Preventive Controls : Preventive controls are those inputs, which are designed to prevent an error, omission or malicious act occurring. An example of a preventive control is the use of passwords to gain access to a financial system. The broad characteristics of preventive controls are: (i) (ii) A clear-cut understanding about the vulnerabilities of the asset Understanding probable threats (iii) Provision of necessary controls for probable threats from materializing As has been discussed earlier in this section, any control can be implemented in both a manual and computerized environment for the same purpose. Only, the implementation methodology may differ from one environment to the other. Now let us discuss the examples of preventive controls and how the same control is implemented in different environments. Examples of preventive controls Employ qualified personnel Segregation of duties Access control Vaccination against diseases Documentation Prescribing appropriate books for a course Training and retraining of staff Authorization of transaction Validation, edit checks in the application Firewalls Anti-virus software (sometimes this acts like a corrective control also), etc Passwords The above list in no way is exhaustive, but is a mix of manual and computerized, preventive controls. The following table shows how the same purpose is achieved by using manual and computerized controls.

3.10 Information Systems Control and Audit Purpose Restrict unauthorized entry into the premises Restricted unauthorized entry into the software applications Manual Control Build a gate and post a security guard Keep the computer in a secured location and allow only authorized person to use the applications Computerized Control Use access control software, smart card, biometrics, etc. Use access control, viz. User ID, password, smart card, etc. (ii). Detective Control : These controls are designed to detect errors, omissions or malicious acts that occur and report the occurrence. An example of a detective control would be a the use of automatic expenditure profiling where management gets regular reports of spend to date against profiled spend. The main characteristics of such controls are as follows: Clear understanding of lawful activities so that anything which deviates from these is reported as unlawful, malicious, etc. An established mechanism to refer the reported unlawful activities to the appropriate person or group Interaction with the preventive control to prevent such acts from occurring Surprise checks by supervisor Hash totals Check points in production jobs Echo control in telecommunications Error message over tape labels Duplicate checking of calculations Periodic performance reporting with variances Past-due accounts report The internal audit functions Intrusion detection system Cash counts and bank reconciliation Monitoring expenditures against budgeted amount Examples of detective controls include (iii). Corrective Controls : Corrective controls are designed to reduce the impact or correct an error once it has been detected. Corrective controls may include the use of default dates on invoices where an operator has tried to enter the incorrect date. A business continuity plan is considered to be a significant corrective control. The main characteristics of the corrective controls are: Minimize the impact of the threat

Control Objectives Identify the cause of the problem Remedy problems discovered by detective controls Get feedback from preventive and detective controls Correct error arising from a problem Modify the processing systems to minimize future occurrences of the problem Contingency planning Backup procedure Rerun procedures Treatment procedures for a disease Change input value to an application system Investigate budget variance and report violations. 3.11 Examples of Corrective Controls (Iv). Compensatory Controls : Controls are basically designed to reduce the probability of threats, which can exploit the vulnerabilities of an asset and cause a loss to that asset. While designing the appropriate control one thing should be kept in mindthe cost of the lock should not be more than the cost of the assets it protects. Sometimes while designing and implementing controls, organizations because of different constraints like financial, administrative or operational, may not be able to implement appropriate controls. In such a scenario, there should be adequate compensatory measures which may although not be as efficient as the appropriate control, can indubitably reduce the probability of threats to the assets. Such measures are called compensatory controls. Some examples of compensatory control given below will make the concept more clear. 3.6.2 Audit Trails : Audit trails are logs that can be designed to record activity at the system, application, and user level. When properly implemented, audit trails provide an important detective control to help accomplish security policy objectives. Many operating systems allow management to select the level of auditing to be provided by the system. This determines which events will be recorded in the log. An effective audit policy will capture all significant events without cluttering the log with trivial activity. Audit Trail Objectives : Audit trails can be used to support security objectives in three ways: Detecting unauthorized access to the system, Facilitating the reconstruction of events, and Promoting personal accountability. Each of these is described below:

3.12 Information Systems Control and Audit (1) Detecting Unauthorized Access: Detecting unauthorized access can occur in real time or after the fact. The primary objective of real-time detection is to protect the system from outsiders who are attempting to breach system controls. A real-time audit trail can also be used to report on changes in system performance that may indicate infestation by a virus or worm. Depending upon how much activity is being logged and reviewed, real-time detection can impose a significant overhead on the operating system, which can degrade operational performance. After-the-fact detection logs can be stored electronically and reviewed periodically or as needed. When properly designed, they can be used to determine if unauthorized access was accomplished, or attempted and failed. (2) Reconstructing Events: Audit analysis can be used to reconstruct the steps that led to events such as system failures, security violations by individuals, or application processing errors. Knowledge of the conditions that existed at the time of a system failure can be used to assign responsibility and to avoid similar situations in the future. Audit trail analysis also plays an important role in accounting control. For example, by maintaining a record of all changes to account balances, the audit trail can be used to reconstruct accounting data files that were corrupted by a system failure. (3) Personal Accountability: Audit trails can be used to monitor user activity at the lowest level of detail. This capability is a preventive control that can be used to influence behavior . Individual are likely to violate an organisations security policy if they know that their actions are recorded in an audit log. Implementing an Audit Trail : The information contained in audit logs is useful to accountants in