MT0032-Unit-01-System and System Concepts

Unit-01-System and System Concepts Structure: 1.0 Introduction 1.1 System Concepts 1.2 System Limitations 1.3 Systems Approach to Problem Solving 1.4 Characteristics of a System 1.5 Types of Systems are 1.5.1 Open and Close Systems 1.5.2 Deterministic and Probabilistic System 1.6 System Life Cycle 1.7 Types of System 1.7.1 Business Functions in Organizations 1.8 System Development Model 1.8.1 The System Development Methods 1.9 Information 1.9.1 Environmental Information comprises the following: 1.9.2 Competitive Information 1.9.3 Internal Information 1.10 Level of Information 1.10.1 Strategic Information
1

1.10.2 Tactical Information 1.10.3 Operational Information 1.11 Characteristics of Information 1.12 Decision Making 1.12.1 Types of Decisions 1.12.2 Structured Decisions 1.12.3 Unstructured Decisions 1.12.4 Decision Making Process 1.12.5 Decision Support Systems [dss] 1.12.6 Attributes of Decision Support System: [DSS] 1.12.7 Types of Decision support system [DSS] 1.12.8 Facts about DSS 1.0 Introduction SYSTEM is an important factor of management information system. The word system connotes plan, method, order, and arrangement. A system, says the dictionary, is a regularly interacting or inter dependent group of items forming a united whole. A system is thus a set of interacting elements, interacting with each other to achieve a predetermined objective or goal. For example, in a computer system, the computer receives inputs and processes than produces the output.

Conceptual model of a system : a system can be defined any set of objects and ideas, and their interrelationships which are ordered to a common goal or purpose. For example, we can describe the system by its components I, J,K.Q or by its subsystems IJK, LMNO, PQ, whichever serves our purpose better. With complex systems, we can divide the analysis and design of the system into subsystems for control and implementation purpose.

Conceptual model of a system

In the above example various symbols through Q represent the component of the system. The lines connecting the symbols represent the relationships among components. Identical symbols represent a unique relationships among one or more , which can be termed a system into subsystem. The use of the term subsystem facilitates analysis or communication. 1.1 System Concepts System can be underlined the field of information systems. A system can be simply defined as a group of interrelated or interacting elements forming a unified whole. Many examples of systems can be found in the physical and biological science, in modern technology and in human society. A system is a group of interrelated components working together towards a common goal by accepting inputs and producing outputs in an organized transformation process. Such a system some times is called a dynamic systems. It has three basic interacting components . i) INPUT Capturing / accepting and assembling components that enter the system to be processed Example : raw data, raw material etc. Process that series of changes to be done on information, to convert input into output. Example: data processing, manufacturing process etc. Which produced by the transformation process to their ultimate destination. Example: reports, finished products etc. 1.2 System Limitations System makes it is possible focus in a particular system within a hierarchy of systems.

ii) PROCESSING

iii) OUTPUT

A limitation of a system may exit either physically or conceptually. The operational definitions of a system in terms of its limitations are: List all the components that are to make up the system and circumscribe them. Whatever found within this circumscribe space is caused the system, and outside this space is called the environment. Work out the follows across the limitation. Flows from the environment into the system are called input. Flows from inside the limitation to outside are called output. Identify all elements that contribute to the specific goals of the system and include these within the limitation if they are not included. System building blocks for information. Information system made up of the six building blocks that are :

Buildings blocks system can be formed into functioning information systems that meet the needs of organizations and their users understandings these blocks, their relationship and coup tings, and their logical and physical context provides the basic knowledge for describing, developing and designing information systems. 1.3 Systems Approach to Problem Solving In system approach, normally we use the following steps: Define the problem what it is about the system that is not satisfactory. Any changes in input from cost or availability of output unsatisfactory ? what is the objective of the systems analysis effort? Understand the system and define it. Because systems are hierarchical and are inter-related with their environment, so they need to follow the system study. -What are the components of the systems ? -Understand the each components relationship with the -What are the constraints / limitations of the system of interest ? -What attractive exit to achieve our objectives with respect to modifying the system ? What choices are their to improve the system ? What is their cost ? And can they be implemented ?
4

 Select one of their alterations Develop and implement the alternatives If need evaluate the impact of the changes made in the system. 1.4 Characteristics of a System Every system has a certain objectives and goals. Main system has a several subsystems or models. The structure of the system is representation of the interaction and inter-relationships between different components or subsystems that from a system. The lifecycle of the system is expression of the phases in the alive usage life of the system. System operates in the terms of goals and predetermined scope. Systems in real life do not operate in isolation. Components of Information System :

1.5 Types of Systems are i) Physical Systems, such as man, weapons etc. ii) Abstract Systems, such as god, nature etc. iii) Open Systems, such as man. iv) Closed Systems, such as Chemical process. v) Probabilistic Systems, such as arrival pattern, class etc. vi) Man Machine Systems, such as aeroplane. 1.5.1 Open and Close Systems A closed system is one which is self contained. It has no interaction with its environment. No known system can continue to operate for a long period of time without interacting with its environment.
5

An open system continuously, interacts with its environment. This type of system can adapt to changing internal and environmental conditions. A business organization is an excellent example of an open system. Major differences between closed and open systems Open System Closed System a) Open system interacts or a) Whereas a closed system does not communicates with the environment react with the environment constantly b) Whereas a closed system has b) An open system has an infinite limited shape. scope till the organization services. c) Whereas the variables in a closed c) In an open system relevant system are self contained. variables keep on interacting. d) Whereas a closed system is rigid d) An open system is generally and mathematical. flexible and abstract. 1.5.2 Deterministic and Probabilistic System The behavior of a deterministic system is completely known. There is no uncertainty involved in defining the outputs of the system knowing the inputs. This implies that the interaction between various subsystems is known with certainty. Computer program is a good example of deterministic system, here, knowing the inputs, the outputs of the program can be completely defined. In the probabilistic system, the behaviour cannot be predicted with certainty; only probabilistic estimates can be given. In this case, the interactions between various subsystems cannot be defined with certainty. 1.6 System Life Cycle A computer based information system has a life cycle. Starting from the inception to the operating and maintenance stage of the system as enumerated below. A Business MIS passes through six distinct phases during its life cycle. 1) The Study Phase: This phase leads to a feasibility study on i) Identification of the problem. ii) Present existing system and its effectiveness
6

iii) Identifying & evaluating the various alternative courses costs and benefits. iv) Selecting the best alternative course of action. 2) Design Phase: a) Identify the functions to be performed. b) Design the input/output and file design. c) Defining basic parameters for system design. 3) Development phase : At this stage the hardware and software are to be decided. 4) Implementation : The selected system is given particle shape and adopted for use. 5) Evaluation of the System : After a period the system is evaluated to see whether it has fulfilled our requirements. 6) Review of the System : This may result in identification of deficiencies in the system. Also environmental conditions may change so that system may have to be modified. 1.7 Types of System A System is defined and determined by its boundaries and objectives. It is quite likely that a system is an arrangement of smaller system in a logical order. When many smaller systems together make a larger system, The smaller system are called Sub Systems of the large systems. A Large system can be spilt or decomposed into smaller systems up to a certain levels. This decomposition can go down to a level where the input and the output are more or less same. The decomposition of a system into subsystems can be in a serial form or it could be in a matrix form. Example: a) Sub systems in a serial order.

b) Sub System Operating in Matrix Order

 In a serial processing, the entire output of a system is the input to the next sub system. And so on. In the matrix arrangement the different outputs go to the different sub systems. A sub systems receives more than one input from other sub systems. Hierarchical structure : example for bill passing system in a commercial organization can be shown as follows.

1.7.1 Business Functions in Organizations Every business consists of several well defined functions. Often these functions are organized into areas / departments. These areas are known as the functional areas of the business , in each functional area, a well defined business function is performed. For example , the area within a business origination responsible for pricing , coordinating consumer advertising efforts, and distributing the firms products / services is known as the marketing function. The marketing function is usually performed by the marketing department. Similarly the area within a firm responsible for making the product if a product is indeed made is the manufacturing department. Mainly three functional areas believed to be the most critical in business:

Finance Marketing and Manufacturing .

Some other functional areas are Personnel, Engineering and Research and development etc. Computerized Tasks and Reports in various Functional; areas of Business
8

Functional area Finance and Accounting

Computerized Tasks Accounts Payable Accounts Receivable Budgeting Financial Statement Computation Fixed Assets Control

Reports General Accounting Reports, Payroll Accounting Reports Bonus and Reports Financial Analysis reports Cost Analysis Reports

Payroll System Cash Flow Statements Port flow analysis Marketing Market Analysis Order entry Sales Tracking Production and Materials Inventory control Manufacturing scheduling Material resources planning (MRP) Computer-aided manufacturing (EAM) ABC/XYZ analysis reports, etc. Reports Personal informations reports Performance appraisal reports Etc. Sales Forecasting Reports Sales Planning Reports Customer and sales Analysis Reports. etc. Production planning and machine loading reports. Cost analysis and control reports Quantity control reports Goods on order reports Vendor analysis reports Inventory control reports

Functional area Personnel

Computerized Tasks Employee education

Customer resources Employee tracking managements IT calculations [HRM]

Government reports generation

Training and leave records reports Etc.

Research and development (R&D)

Recruiting Compute- Aided Design R & D analysis reports. (CAD) Patent searches Specialized engineering functions

The back bone of an business origination information system is its functional information system, since these process translations and make possible various house keeping and administrative qualities, they also provide most of the information useful for planning. 1.8 System Development Model In order to design a good system, traditionally, the developers have used the Waterfall model as shown in Fig.

Waterfall Model As Management Information Systems As waterfall flows from the .top .to the bottom, the system model shows the development process from the top to the bottom in steps. As water does not rise from a lower level to a higher level, it is presumed that once a step in the model is over, it is not required to go back. This model fits well when the changes into the requirement specifications are not required frequently. The minor changes can be taken care of through a maintenance process or through small design changes. The waterfall model applies well to the basic rule based data and information processing systems in accounting materials, production and personnel.

10

Spiral Model However, some systems are more dynamic and require changes in specifications more oftenj to continue to be useful. These modifications are termed as the versions of the basic model. One of the popular model developed by Boehm is a Spiral model as shown in Fig. A spiral model fits well, when we are developing large systems, where the specifications cannot be ascertained in one stroke completely and correctly. Some of them get surfaced when the system is put to use after its testing: The continuous revision of these steps in the system development is very common and then the designers call them as versions. The new version provides an additional functionality, features, and facilities to the user, and addresses the issues of the users of the system viz. performance, response, security and so on, irrespective of which development model is used in developing the system. The user wants the system to be user friendly, reliable and effective, and one which gives correct results, while the developer wants, the system easy to modify, easy to understand, portable and compatible to other systems. The definition of a good system varies with the systems environment. In some systems the performance is the key measure of a good system while in other cases the ability to change fast is a key measure of a good system. In some cases the user friendliness could be a measure of good system. In all the cases, however, the correctness of the result is a common measure, making them reliable and dependable for the business operations. The speed and response are the performance measures in case of large volume transaction based systems designed for real time applications. The flexible design is a measure of performance where the system needs continuous modifications to meet the revised requirements of the specifications. When it comes to a complex system the user friendliness and the ease of operations become the measures of a good system. In other words, a good system design considers the environment and the users, and incorporates all the needs and expectations so that its utility is the highest. 1.8.1 The System Development Methods The traditional software development methods are the Structured Systems Analysis and Design (SSAD) by Ross; the Requirement Driven Design by Alford and the Structured Analysis and Structure Design (SASD) by Yourdon. All these methods deal with the functions and data separately. The modem methodology is object-oriented, where the functions and the data are viewed together as an object.

11

Traditional methods consider the function and the data independent of each other. The function provides the behaviour or operation which will use the data to perform. The data set so produced will hold information on the latest status of the transaction or function. These methods operate on the data model which has a structure, definition and application. The same data when used in different functions will produce different results and information. A system developed with the SSAD and the similar approaches are difficult to maintain. The reason is that for each function and its behaviour the data structure is defined. The functionality behaves correctly under the conditions of the rigid data definition and structure. However, in real life, the data format changes, calling for a change in the programmes to meet the revised format and its processing. The length of the programme and its complexity increases due to first checking the data condition, and then moving the control to an appropriate command set for its processing. The SSAD is, therefore, easy to understand but difficult to maintain. The user of the system does not think in terms of the data and its definition but thinks in terms of the functionality or process producing a result. In the SSAD approach, therefore, the user must have two views on the system to understand. The first view on the data and the second on its functionality. The two views create a problem of understanding the system correctly. The Object Oriented Technology (OOT) approach differs from the SSAD approach. The difference is that the OOT views the system and then models it in terms of an item called the Object, where the function and the data are defined at its lowest level where changes rarely occur. The OOT views the functions and the data as one integrated entity .It reflects the requirements directly into the objects. In the SSAD approach, the requirement is fulfilled through defining and associating the data for each function. While in the OOT approach the requirement is fulfilled, through the object(s) processing, where the object itself is based on the behaviour. If a new requirement arises the new object(s) view is taken and the model is modified in that portion only leaving the rest of the design and the programme structure as it is. In the OOT approach the changes boil down to the lowest level in most of the cases. A good object model of the system does not require any changes at a Class or Super Class level. They are, generally, at the instance level. For example, in invoice preparation, new functionality is required to calculate the invoice amount. In SSAD this would need a condition definition for recognition, then the changes in the data and process flow, further defining the output of the new requirement. In OOT the same situation would be handled by creating an instance where only the computing behaviour is different from the others. The instance is created by using the principle of inheritance. Hence the change in the system and the programme progress is only at the lowest level and is local, not running across the total model of the system. In short, for a given business functionality the objects are defined in different categories and the system design is built through the objects and it is processed through object processing. Hence, in a business organisation to conduct a business, it requires the customer orders, purchase indents, material indents, work orders, purchase orders, receipts, issues, payments, delivery notes, packing notes, excise gate passes, invoices, bills, vouchers, etc. In the OOT usage the analysis is made of the business operations, and it is modelled into objects. For example, the
12

object class ORDER will handle all kinds of orders, viz., the customer orders, purchase orders, pay orders, appointment orders and so on. The objects are constructed for the documents, transactions and operations. The method which uses the objects in modelling and processing is called as the object oriented methodology. Whether it is a Waterfall model or a Spiral model of system development, or whether it is the SSAD or the SASD approach or whether it is the object oriented technology of system development the following steps of the development are common. Requirement Analysis Requirement Definition System Design - Input Design - Process Design - Output Design System Development - Structuring the modules - Developing Unit Testing Integration of the Modules System Testing Implementation Maintenance The requirement analysis is carried out from the top downwards in the organisation hierarchy, linking the goals and the objectives of the business organisation, with the strategy mix decided to achieve them. In this phase the information needs of the individuals, groups and functions are analysed from a decision making or a support point of view. Such information needs would fully satisfy the operational and management information needs. Once the needs are justified, the next step is to define them in clearer terms for the purpose of development. The requirement definition brings clarity in the content and its application in various ways in the organisation.
13

The third step is to design a physical and a logical system through which the outputs are designed. The processes which would give the outputs are determined, and the data which would be required by these processes is finalised in terms of definition, source, and quality. And further, the collection, creation, validation and storage of the input data is also decided. The fourth step is to break the system design into modules in the hierarchical top-down structure to facilitate the development effort as well as its implementation. Once the modules are developed, the unit testing is carried out to confirm data transaction and outputs validity and accuracy .In this testing, the transaction level processes are checked to confirm the input-process-output relation, and the data storage and the transaction level updating. When the unit testing is over and the module level processing is confirmed, the modules are put together to generate the information as determined in the requirement definition. The process of putting the modules together is a process of integration. It is intended to produce the results of data integration. The system so developed is tested as a whole for several aspects such as information, quality, performance, utility, user acceptance and so on. Once the system testing is complete, the system is implemented at site, on the hardware and software platform. The implementation step has its own procedure starting from the installation of the hardware and the software, training the users, and then shifting to a fully designed system. While implementing the system some minor modifications / adjustments, may be required for the ease of acceptance by the user. Even after complete installation, the system may require modifications or changes in terms of functions and features over a period of time. The process of introducing these new requirements without disturbing the time tested basic system is called maintenance. Such changes are required swiftly and hence they are required to be carried out very easily. The system is designed keeping this natural requirement in post implementation period. A good system design and its implementation has high user acceptance because it helps solve the problems in business performance, and meets the information needs, within a sensible time scale, with an assured quality and security of information. 1.9 Information Second important element in any managerial information system is the information system is the information. Definition: Information can be defined as data that has been processed into a form that is meaningful to the recipient and is of real or perceived value in current or prospective decisions.

14

OR Information refers to an input of data processing which is organized and meaningful to the person who receives it. For example, data concerning a sale may indicate the number of the salesman. When a large number of such data elements is organized and analyzed, it may provide important information to a marketing director who is attempting to evaluate his sales force. Also if a production manager is told that, not only the production is behind schedule but also it is 75% of the schedule target is information to him. In general, the planning information requirements of executives can be categorized into three broad categories viz a) Environmental Information b) Competitive Information c) Internal Information. 1.9.1 Environmental Information comprises the following: i) Government Policies Information about concessions, benefits government policies in respect of tax concessions or for any other aspect, which may be useful to an organization in the future period. ii) Factors of Production: Information related with source, cost, location, availability, accessibility and productivity of the major factors of production viz Capital, Labour, Material etc. iii) Technological Environment: Forecast of any technological changes in the industry and the probable effect of it on the firm. iv) Economic trends: It includes information relating to economic indicators like consumers disposable income, employment, productivity, capital investment etc. 1.9.2 Competitive Information Includes the following information: i) Industry demand: Demand forecast of the industry in respect of the product manufactured and in the area in which the firm used to be operating. ii) Firm Demand Assessment of the firms product demand in the specified market. It also includes an assessment of firms capability to meet firms demand.

15

iii) The competitive data: Data of compelling firm for forecasting and making decision and plans to achieve the forecast. 1.9.3 Internal Information It includes the information concerning concerns are: i) Sales forecast ii) The financial plan/budget iii) Supply factors, and iv) Policies, which are vital for subsidiary planning at all levels in the organization. 1.10 Level of Information Information within an organization can be analyzed into 3 levels.

1.10.1 Strategic Information Is used by senior managers or top management to plan the objectives of their organization, and to assess whether the objectives are being met in practice. Such information includes overall profitability, the profitability of different segments of the business, future market prospects, the availability and cost of raising new funds, total cash needs, total management levels and capital equipment needs, etc. although internally generated information will always be used. Information requirements of top management are met by strategic information tier by arranging information from internal and external sources. 1.10.2 Tactical Information is used by middle management to ensure that the resources of the business are employed to achieve the strategic objectives of the organization. Such information includes productivity measurement output per on an hour or per machine hour, budgetary control or variance analysis reports and cash flow forecasts, managing levels and profit results within a particular department of the organization, labour turnover statistics within a department, short term purchasing requirements etc. A large proportion of this information will be generated from within the organization as a feedback. Tactical information is usually prepared regularly and it is used for the decision making referred to as management control.

16

Another important function of tactical level is to supply information to strategic tier for the use of top management. This tier collects the required information from strategic and operational tiers and thus serves as a bridge between strategic and operational tiers of information. 1.10.3 Operational Information is used by operation level of management (front line manager) such as foremen or head clerks to ensure that specific tasks are planned and carried out properly within a factory or office etc. In the payroll system, for example, operational information relating to day rate labour will include the hours worked each week by each employee, his rate of pay per hour, details of his deductions, and for the purpose of wages analysis, details of the time each man spent on individual jobs during the week. In this example, the information is required weekly. Operational information relates to the level of decision making referred to as operational control. Operational level requires information for implementing and regulating operational plans for the purpose of conversion of inputs into outputs. Also it supplies routine and other information to tactical tier in summarized form. 1.11 Characteristics of Information Important characteristics of useful and effective information are as follows: i) Accuracy: Information, if it is to be value should be accurate and should be truly reflects the situation or behavior of an event as it really is. Otherwise the user will take the incorrect information as correct and may use it for decision making with a disastrous result. ii) Form Information : Is of value if it is provided to the user in the form it is useful and best understood by him. iii) Relevance : It refers to current utility of information in decision making or problem solving. iv) Timeliness : It means that information should be made available when it is needed for a particular purpose and not before and in any case not after. Delayed information has far less value as a resource. v) Completeness : Information is considered as complete if it tells its user all what he wishes to know about a particular situation/problem. The more than completeness of information the higher is its value. vi) Purpose : Information must have purpose at the time it is transmitted to a person or machine, otherwise it is simply data. The basic purpose of information is to inform, evaluate, persuade or organize other information, create new concepts, identify problems, solve problems, decision making, planning, initializing, controlling and searching. vii) Reliability: The information should be reliable and external force relied upon indicated.

17

viii) Validity: It measures the closeness of the information to the purpose which it purports to serve. 1.12 Decision Making Decision Making is an essential part of management. One of the major roles of managers in organizations is processing information and making decision. Information systems to developed to help the managers in their decision systems to developed to help the managers in their decision making process. The decision making process is based on the support of the information systems in the organizations. The managers must be aware of a problem, before a decision can be made. A problem exists when the real situation is different than the expected one. After the problem has been identified, the causes of the existence of the problem must be identified and then the solution to the problem has to be found. The decision making process can be divided into three main phases: 1) Intelligence : Searching the environment for conditions calling for decisions. The phase consists of determining that a problem exists. 2) Choice : In this phase the decision maker selects one of the solutions identified in the design phase. 3) Design : the decision process follows the sequence from intelligence to design and to choice. It is possible to go back from one phase to another and the whole process may be repeated. 1.12.1 Types of Decisions The decisions have been classified into most activity. We present here different on the arranging mainly two types of decisions that are : i) Structured Decisions Or Programmed Decisions ii) Unstructured Decision Or Non Programmed Decisions. 1.12.2 Structured Decisions These decisions are those that can be programmed and well defined. They are essentially repetitive, routine and involve a defined. They are essentially repetitive routine and involve a definite procedure for handling them so that they do not have to be treated each as if they were new. It has been seen that in general at the operational level and the managerial staff, deal mostly with such fairly well structured problems. Structured decisions are also called programmable decisions involve situations where the procedures decisions involve situations where the procedures to follow when a decisions are structured or programmed by the decision procedures or decision rules developed for the them. A
18

structured decision could possibly involve what is known as a deterministic decision or an algorithmic decision. Example : Decision making of students results Decision about the payroll systems etc. Characteristics : - Structured decisions can be delegated. - The cost of taking such decisions is not as high as that of unstructured ones. - These decisions can be made with the help of Computer systems. 1.12.3 Unstructured Decisions These type of decisions are occasional and unique in nature. There are no predefined procedures available to solve these problems and a new analysis is required for each occurrence. In top level managers are usually faced with more such unstructured decision making situations. Thus the strategic decision are non-repetitive, vital and important and aim of determining or changing the ends or means of the enterprise. Unstructured decisions are not simple. They are usually quite Complex in nature, so, There is no tried and true method of handing them. Unstructured decisions are those in which the decision maker must provide judgment, evaluation and insight into the problem definition. The risk involved in taking decisions to solve the problems in this is usually high. Examples : Produces scheduling , Capital budgeting Features of Unstructured decisions : - These decisions cannot be delegated. - The cost of taking such decisions are quite high. Compared to structured decisions. 1.12.4 Decision Making Process Simons decision making model : The decision making process as proposed by Herbert A. Simon. His model is a conceptual framework that divides the decision making process onto the following stages or phases: i) Intelligence Activities : At this stage, a search of the environment takes place to identity events and conditions requiring decisions. Data inputs are obtained, processed and examined for clues that may identify problems or Opportunities.

19

ii) Design facilities : At this stage, alternative courses of action are developed, analyzed and evaluated. This involves process to understand the problem, to generate solutions, and to test solutions for feasibility iii) Choice & Implementation activates : Here one has to select an alternative as course of action from those available. A choice is made implementation and monitored. Through intelligence, design, choice and implementation activitiesare sequential in nature, the decision making process includes the ability to cycle back to a previous stage as shown in figure. Flow Chart of Decision Process Is there a What are the Which should Is the choice Problem ? alternatives? You choose ? working ?

1.12.5 Decision Support Systems [dss] DSS are an application of Herbert A Simon model. As explained earlier, the model has three phases viz intelligence, design and choice and implementation. The DSS basically helps the information system in the intelligence phase where the objective is to identify the problem and then go to the design phase for solution. The choice of selection, criteria varies from problem to problem. It is therefore required to go through these phase again and again till a satisfactory solution is found. These systems are helpful where the decision maker calls for complex manipulation of data and use of several methods to reach an acceptable solution using different analysis approach. The decision support system helps in making a decision and also in its performance evaluation. These systems sensitivity analysis on various parameters of the problem. DSS can be built around the rule in case of programmable decision situation. While in NonProgrammable decisions, the rules are not fixed or predetermined, and requires every time the user to go through the decision making cycle as indicated in the Herbert Simon model. The DSS refers to a class of systems which support in the process of decision making and does not always give a decision itself. 1.12.6 Attributes of Decision Support System: [DSS] 1) Flexibility : The systems are flexible so that any semi structured or unstructured decision making situation can be tackled with case and speed.

20

2) Simple Model : The systems use simple model of decision making. The only change is that a different set of information is sought for the use of different models. The choice of a model depends upon the complexity of decision making. 3) Database : The DSS needs database(s). The system calls for several inputs from database(s) for decision making. The use of information being common input to the system is from the database. 1.12.7 Types of Decision support system [DSS] 1. Status inquires Systems : The number of decision in the operational management and same at the middle management are such that they are based on one or two aspects of a decision making situation. It does not call for any elaborate computations, analysis, choice, etc. for decision making. If the status is known, the decision is automatic, ie the status and solution is unique relation. 2. Data analysis Systems : These decision systems are based on Comparative analysis, and use of a formula or an algorithm. But, these process are not structured and, therefore, vary. The cash flow analysis, the inventory analysis and the personal inventory systems are examples of the analysis systems. The use of simple data processing tools and business rules are required to develop this system. 3. Information analysis Systems : In this system, the data is analyzed and information reports are generated. The reports are generated. The reports might be having exceptions as a feature. The decision makers use these reports for assessment of the situation for decision making. The sales analysis, the accounts receivable systems, the market research analysis, the MRP systems are example of this system. 4. Accounting System : These systems are not necessarily required for decision making but they are desirable to keep track of the major aspects of the business or a function. The contents of these systems is more data processing leading to formal reporting, with exceptions, if necessary. These systems account items such as cash, inventory, personnel and so an and relate it to a norm or norms developed by the management for control and decision. 5. Model Based Systems. These systems are simulation models or optimization models for decision making. These decision, generally, are one time and infrequent and provide general guidelines for operation or Management. The product mix decision, the material mix, the Job scheduling rules, and the resource or asset or facilities planning systems are the examples.

21

Example : In order to illustrate these decision support systems, let us take the example of materials Management function and the variety of the decision and the type of systems used therein to support and examine the decision. - Decision - Selection of Vender - Procurement - Pricing - Selection of vendor based on price, quality performance. - Selection of capital asset - Inventory rationalization - Management of inventory within various financial and stocking constraints 1.12.8 Facts about DSS: 1. The decision support systems are developed by the users and system analysis jointly. 2. DSS uses the principles of economics, science and engineering, and also the tools and techniques of management. 3. The data used in the DSS is draw from the information systems developed in the company. 4. the decision support systems are developed in isolation and form an independent system subset of the management information system. 5. the most common use of the decision support system is to test the decision alternatives and also to test the sensitivity of the result to the change in the system and assumptions. Exercise: 1. Define System? 2. Define System? Explain the limitations of System. 3. What are the steps involved in System approach to solving the problems? 4. Brief the characteristics of a System? 5. Differentiate between open system and closed system?
22

Type of system required Inquiry System Inquiry System Data analysis Information analysis system. Return on investment analysis Valuation of inventory and accounting system Inventory optimization model

MT0032-Unit-02-Overview System Analysis and Design

Unit-02-Overview System Analysis and Design Structure: 2.1 Introduction 2.2 What is system analysis? 2.3 Why system analysis? 2.4 The Need for System Analysis 2.4.1 System Objective 2.4.2 System Boundaries 2.4.3 System Importance 2.4.4 Nature of the System 2.4.5 Role of the System as an Interface 2.4.6 Participation of Users 2.4.7 Understanding of Resource Needs 2.5 System Analysis of the Existing System 2.5.1 Procedure of Analysing the Existing System 2.5.2 System Analysis of a New Requirement 2.6 Specific Phases in System Development 2.6.1 Area Selection and Problem Definition 2.6.2 Problem Definition 2.6.3 Data gathering 2.6.4 Creation of alternatives
23

2.6.5 Feasibility Study 2.6.6 Master Development Plan 2.6.7 Designing Phase 2.6.8 System Design Components 2.6.9 System Documentation 2.7 Systems Communication 2.8 System Implementation 2.9 System Evalution 2.1 Introduction Having got to know all about the basic concepts of hardware and software. we will now examine how to go about using the computer to achieve our objectives of processing a job. The task is achieved through what is called systems analysis and design. System has been defined as an assembly of procedures, processes, methods. routines or techniques united by some form of regulated interaction to form an organised whole. Systems analysis is the term used to describe the process of collecting analysing facts in respect of existing operation of the situation, prevailing so that an effective computerised system may be designed and implemented if proved feasible. Systems Analysis can be viewed as the most recent and perhaps the most comprehensive technique for solving computer problems. System analysis may be considered as an interphase between the actual problem and the computer -a kind of midwife to all computer applications. Before a computer can perform, it is necessary to investigate and analyse the system. The individuals who perform the systems investigation. as distinct from those involved in the detailed . computer programming are called System Analysts. Systems analysis also embraces systems design. which is an activity concerned with the design of a computerised application based on the facts disclosed during the analysis stage. Both activities are carried out by the same person who is known as a Systems Analyst. In the field of data processing. the work system has several different uses. The system can refer to an electronic hardware System (the computer system). a software system (a system of interrelated programs), or a DP System (one that consists of hardware. software. people and

24

procedures). In the context of Systems design and analysis, the third use is tile most common. i.e.. a DP System as opposed to a hardware or software system. When we speak of system development, we mean the development of a DP System. This can be a relatively small task such as modifying a payroll system so that it will handle hourly as well as salaried employees. OR it can be a huge project such as replacing a manual system for billing, inventory, and accounts receivables with a computerised system. 2.2 What is system analysis? Harry goode and Robert machols quoted system analysis as below. For more than a decade, engineers and administrators have witnessed the emergence of a broadening approach to the problem of design equipment. This phenomenon has been poorly understood and loosely described. it has been called system design. system analysis and often the system approach. Analysis of the system means identification, understanding and critically examining the system, and its parts (sub-systems) for the purpose of achieving the goals or objectives set for the system as a whole, through modifications, changed interrelationship of components, deleting or merging or separating, or break up of components. It may also involve upgrading the systems as a whole. System analysis may be considered as an interphase between the actual problem and the computer. 2.3 Why system analysis? The understanding of what system analysis is in itself provides an insight into its importance and why it is needed. System analysis basically is an approach toward viewing the processes activities and complex problems in their totality. Thus specifically: It offers a means to greater understanding of the complex structures. It is a mean to trade off between functional requirements of a subsystem and its immediately related subsystems. It helps in understanding and comparing functional impact of sub systems to the total system. It helps in achieving inter-compatibility and unity of purpose of subsystem. It helps in discovering means to design systems where subsystems may have apparently conflicting objectives. Finally, it helps in placing each subsystem in its proper prospective and context, so that the systems as a whole may best achieve its objectives with minimum available resources. It thus creates synchronization between systems as objectives.

25

2.4 The Need for System Analysis When you are asked to computerise a system, as a requirement of the data processing or the information need, it is necessary to analyse the system from different angles. While satisfying such need, the analysis of the system is the basic necessity for an efficient system design. The need for analysis stems from the following points of view. 2.4.1 System Objective It is necessary to define the system objective(s). Many a times, it is observed that the systems are historically in operation and have lost their main purpose of achievement of the objectives. The users of the system and the personnel involved are not in a position to define the objective(s). Since you are going to develop a computer based system, it is necessary to redefine or reset the objective(s) as a reference point in context of the current business requirement. 2.4.2 System Boundaries It is necessary to establish the system boundaries which would define the scope and the coverage of the system. This helps to sort out and understand the functional boundaries of the system, the department boundaries in the system, and the people involved in the system: It also helps to identify the inputs and the, outputs of the various subsystems, covering the entire system. 2.4.3 System Importance It is necessary to understand the importance of the system in the organisation. This would throw more light on its utility and would help the designer to decide the design features of the system. It would be possible then to position the system in relation to the other systems for deciding the design strategy and development. 2.4.4 Nature of the System The analysis of the system will help the system designer to conclude whether the system is the closed type or an open, and a deterministic or a probabilistic. Such an understanding of the system is necessary, prior to design the process to ensure the necessary design architecture. 2.4.5 Role of the System as an Interface The system, many a times, acts as an interface to the other systems. Hence through such an interface, it activates or promotes some changes in the other systems. It is necessary to understand the existing role of the system, as an interface, to safeguard the interests of the other systems. Any modifications or changes made should not affect the functioning or the objectives of the other systems. 2.4.6 Participation of Users

26

The strategic purpose of the analysis of the system is to seek the acceptance of the people to, a new development. System analysis process provides a sense of participation to the people. This helps in breaking the resistance to the new development and it also ensures the commitment to the new system. 2.4.7 Understanding of Resource Needs The analysis of the system helps in defining the resource requirements in terms of hardware and software. Hence, if any additional resources are required, this would mean an investment. The management likes to evaluate the investment from the point of view of return on such investment. If the return on the investment is not attractive, the management may drop the project. 2.5 System Analysis of the Existing System When the objectives of the information system are finalised, as the first step towards development, it is necessary to analyse the existing system. Such an analysis helps in achieving the following: Understanding the existing system. Understanding the objectives achieved by the existing system. Evaluating the system for computerisation and its placement in the total MIS design. Knowing whether the system is feasible technically and operationally. . Are the information needs fully justified? If so, is the cost of the system design justified to increase the value of the information? 2.5.1 Procedure of Analysing the Existing System System analyst while analysing the existing system should: 1. Carry out the analysis of the system at a place where the system is functioning. This step will ensure that the analyst is accepted as one of those operating the system. 2. Note down the key personnel in the system besides the head of the department. The key personnel are those who contribute towards the system operations. 3. Spend some time with the operating personnel and observe the system to understand the finer details of the system.

27

4. Define the scope of the system and its objective. The scope will cover the boundaries of the system. Further, should identify the problems faced in the system which cause difficulties in achieving the objectives. 5. Collect all the documents which are raised in the system. These documents carry data from one point to another. The documents could be printed or handwritten. While collecting the documents, the analyst should note down who raises the document, the purpose it achieves, and the manner in which it is distributed. 6. Collect separately the outputs such as statements, reports, memos, etc. made in the system to throw more light on the information it generates. If these reports and the statements are sent to other departments, make a note of it. Also find out if any register or notebook is maintained at various points, which act as data storage and reference. Note down against each such document, its use. 7. Make a list of rules, formulae, guidelines, policies, etc., which are used in running the system. 8. Note down the check points and the controls used in the system to ensure that the data- flow is complete, processing of the data is correct and the analysis is precise. 9. Study the flow of data in the system in units, summary and aggregates from document to document and from one stage to the other. 10. Make a small system note as a base document and seek an appointment with each head of the department to discuss the system. In the discussion, ensure that your system view and understanding is the same as that of the head of the department. Ascertain from him whether he has any other objectives which the system should achieve. 11. Examine whether the achievement of the systems objectives is feasible in the present system. This means, examining whether adequate data exists, whether it can be processed by the rules, methods, model, already there to generate information. If so, will the information be correct, precise and complete. Further, can it be processed on time to be useful to the user or the decision maker? 12. If there are problems in the feasibility of implementation, then examine whether the present system can be modified by introduction of documents, controls, procedures and systems. If this is not possible, redefine the scope of the system and objectives in the light of the study. 13. Draw a revised system flow chart to indicate how the system runs the major steps of processing the information. This chart should include all the modifications which had been suggested and accepted. 14. Discuss the flow chart with the personnel operating the system so that they under- stand the system. Impress upon them that they should run the system as per the flow chart, and resist any deviations there from that would cause a disturbance in the system. Explain the modified system in such a way that the user would appreciate the changes.
28

15. Make a list of the outputs (statements, reports) containing information. Get the contents of the reports approved by the head of the department. 16. Analyse the requirements of the information and reports from the utility point of view. More the information, higher is the cost of its generation. Decide the utility based on the value of information. 17. Compare the costs of the old and the new system, and benefits offered. 18. Obtain approval of the new system from the users and the top management. 19. Write a system manual for use of the people in the department and for reference to the other users of the system. 2.5.2 System Analysis of a New Requirement It is not always necessary that the analysts are required to conduct the analysis of the existing system. In a number of cases when legacy systems have outlived their utility or a new business environment requires a totally radical approach, the analyst is called for redesigning the processes, practices and procedures. Todays business world of a company is beyond the four walls of the organisation. The vendors and the customers are being treated as trusted business partners of the organisation. This change in the management philosophy calls for a change in the information management function in the organisation. It cuts across all the facets of processing the data and the information, right from the input to the output and its distribution. The conventional confidential access to the information, and the practice of authorising a person to make decisions has undergone a substantial change. The decision centres in the organisation have been diffused and a substantial delegation of decision making has taken place at the lower level. The characteristic change in the organisation is that it is being looked as a process organisation as against a functional organisation. The work culture is changing from the single hierarchical command control principle to the working through work groups principle. These work groups are empowered to make decisions with an access to support the information. In such changed environment, the information system architecture, the design and processes, and the hardwaresoftware configuration should be restructured to meet this changed requirement of information. The trend is towards building a system which is potentially flexible, adaptable to the new technology, easy to use, and which enables the user to meet his own needs through his knowledge and expertise. The system analyst, in such a virgin situation of policy change, has to think globally, taking into consideration the technology, the user, and the business it serves. He is required to make analysis to evolve the system and the technology strategy, and configuring them to work for executing the business strategy through the information support. The system analyst has to choose between the client server versus the Host-slave processing strategy .He has to make a choice between the different variants of Unix OS, Windows NT and so on. He has to choose the language platform
29

and select a variety of packages, and put them together to achieve the information support goal. He will also be confronted with techno-commercial issues arising out of the multiple vendors dealing with different technologies. Putting all the system components together to achieve the information processing strategy success is quite a complex job requiring a vision and a foresight. Hence, the System Analysis and Design, in such situations, is an exercise at a macro level With a top-down approach in understanding the requirement. The information system development cycle for anew application consists of the five major stages: 1. Definition of the system and its objective 2. Development of the system (Analysis-Design-Programming) 3. Installation of the system 4. Operations of the system 5. Review and evaluation Following the system development cycle approach is the best bet for the successful completion of any system project. The main advantage of the approach is that process helps the analyst to conceive, develop, design and implement the system. Following the procedure provides the basis for management and control of the project as each step in the process is a well defined task. The most important step in the process is the definition and the objectives of the system. Unless the user and the designer agree on this point, it will be risky to proceed further. The systems analysis is the second most important step in the cycle. The designers who spend more time on this step succeed in completing the project effectively. About 30% of the time should be spent in the first two phases and about 10% of the time in the post implementation review and evaluation. The prototyping step is a critical step where the user understands the system in the initial stage and helps to try out the ideas in the system leading to the process design of the information system. The life cycle procedure is a tool for the system designer. Its meticulous following is a safe method to accomplish the system objectives. 2.6 Specific Phases in System Development Any system goes through a process of birth. Growth, maturity, and decline. The System Development Process is a method for studying and changing systems as they go through these changes. That is the topic of this chapter. Other terms often used for the same processes are "system life cycle" and system development life cycle." The system development process has six stages. In chronological order these are:

30

2.6.1 Area Selection and Problem Definition This exercise is usually performed by systems analyst under a preliminary investigation, they examine the functioning of each unit/department before deciding specific areas in which the computerisation may be most. useful. Besides this they also ascertain the weakness of the present system, and also assess, the attitude of trade union leaders about the use of computer system. 2.6.2 Problem Definition The objective of this phase is to obtain a System definition, which will then be implemented, if accepted, in the subsequent analysis and design phases. The basic activities are: 1. Determine objectives of current system. 2. Study current system to see how far it meets its objectives. 3. Analyse users and companys requirements to develop new objectives. 4. Identify constraints imposed by users environment. 5. Identify users responsibility of data inputs and outputs to other systems. 6. Examine interaction of proposed system with other systems. 7. Prepare details of requirements users-data elements, volumes, response times etc. 8. Prepare design specifications. 9. Prepare plan for design and implementation phases. 10. Produce a report for the user and systems management.

31

Systems objectives can be defined at several levels and it is in fact desirable to do Just that. First, there are the overall objectives of the total information system. The essential point about these objectives is that they contribute towards the company objectives. Examples of overall system objectives are: (a) To maintain the companys share of the market. (b) To increase the net profits of the company. (c) To maintain the current efficiency of operations during expansion of the business. (d) To provide an information system of a guaranteed level of sophistication -at a cost which does not exceed 1% of annual turnover. The overall system objectives should be broken down to sub-system level. In doing so, it is important to observe the following principles: (i) The sub-system objectives must be consistent with the overall goals of the information. (ii) Whenever possible the objectives should be quantifiable so that progress may be measured. (iii) The objectives must be achievable. (iv) Each sub-system objective must be capable of itself broken down into sub-objectives. Based on the identification of objectives. Input, output and file content, the vital document called the "System Definition" can be developed. This should contain 1. Definition of objectives of the System. 2. Definition of constraints on the System (for example, company departments may not be included). 3. Narrative of System function. 4. Overall information flow. 5. Specification of input data and means of creation. 6. Specification of output data and its distribution. 7. Definition of content of file and methods of updating. 8. Definition of responsibilities (Including data input, updating, error control etc.)

32

9. Definition of time constraints (for example, latest time at which information is to be received by each user). 2.6.3 Data gathering Data gathering refers to the collection of information pertinent to systems project. To get information, the analyst may read books or reports. go through records. collect forms for later analysis. or interview people. Interviewing is an important skill for the analyst who may interview managers. workers. sometimes even customers. Often, some of the most important information comes from the low-level, employees (the workers). As information is collected, the Analyst will document the important aspects so it can be referred to later on. For this purpose he or she may use forms charts or tables. The principal methods of obtaining facts include: (a) Interviewing personnel. (b) Observing activities which can be performed in a number of ways including visual and photographic methods. (c) Use of questionnaires or by inspection and examination. In general the stages of investment are as follows: (i) Define the problem. (ii) Plan the project. (iii) Collect the facts. (iv) Record the facts. (v) Verify the facts. (vi) Examine the facts. Specific Aspects of System Analysis: Apart from collecting facts as indicated above. there are other specific points to be considered in a systems analysis, as follows : (a) Collect specimens of all documents Used in the system. (b) From the documents collected prepare (i) GRID or X Chart

33

(ii) Document analysis form INPUT. (iii) Document analysis form OUTPUT. (iv) File analysis form. (v) Output analysis chart. (vi) Clerical procedure chart. (vii) Procedure Narrative. (c) Analyse the system and separate essential from non-essential elements. 2.6.4 Creation of alternatives Once the analyst has a clear idea of the problem, he or she begins to create some possible solutions. In actual practice, these solutions usually begin to form while the initial research (data gathering) is going on. Then, after completing the research, the analyst chooses the most promising alternatives and develops them. In order to create sound alternatives, the analyst must have a broad background, must be familiar with the many different types of equipment that can be applied to the problem, and must be familiar with the various types of procedures that can be used. From this background he or she can develop an alternative similar to one that some other company or group is using or can create a special or unique solution to his or her companys problem. It is important to realize that the solutions at this stage are not developed in detail. The procedures developed here are not specific. Although a general logic flow is created for each alternative, specific steps will be determined during the Systems Design Phase. Unless the problem is quite limited, analysts should try to develop more than one alternative. This will give them the freedom to explore imaginative solutions rather than talking only the quick and obvious one. It will also give management a broader perspective on the range of available solutions. SYSTEM ANALYSIS SUMMARY GENERAL BACKGROUND Context and environment of both the system and the report The lines of authority and the areas of responsibility The duties and necessary qualifications

ORGANIZATION CHART

JOB DESCRIPTIONS

34

DOCUMENTS

for each lob position Forms and reports used or generated by the system Description and flowchart of system processing steps Errors or areas where improvement could be made Suggestions on the steps to be taken to correct the deficiencies

PROCEDURES

DEFICIENCIES

RECOMMENDATIONS

2.6.5 Feasibility Study Once the existing system has been studied. It is the task of the analyst finalise the feasibility report. An outline of a typical feasible study is as follows: 1. Statement about the objective of the problems. 2. Terms of reference. 3. Analysis of existing systems Data gathering. (i) Interviewing and note taking (ii) Organisation of data Data presentation (i) Simple documentary forms List of files and records required (i) Functions (ii) Size (iii) Access requirements Communication requirements (i) Within organisational units
35

(ii) Between organisational flow units Preparation of flow charts Cost estimates (i) operating Costs (ii) Overhead Costs (iii) Equipment Costs 4. Analysis of alternatives meeting similar requirements. For each alternative proposed: Overview-percentage of goals achieved. Benefits decisions Information flows technical details (rues. 1/0 processing) operational aspect impact on the organisation -total costs and benefits 5. Determine the main output requirements. 6. Effects on company operations Nature timing and extent of the changes that would occur in procedures, practices and staffing. 7. Financial effect A summary of tangible costs and benefits that would flow from tile adoption of the system. 8. Achievement of company objects A summary of the Intangible losses and benefits that would flow from the adoption of the system. 9. Conclusion A recommendation to proceed or otherwise with the system envisaged.

36

Remark. The main Ingredient of the report documenting the feasibility study Is the coat-benefit analysts. This is a fundamental piece of information or the management of both the systems department and the user area and as such be accurate and clearly understandable. The cost-benefit analysis. System costs can be sub-divided into development. operating and intangible costs. Development costs for a computer-based information system include the costs of the system development process such as (i) the salaries of the system analysts and computer programmers who design and program the system. (ii) cost of converting and preparing data rues 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 startup costs, (v) cost of stationary system maintenance etc. Operating costs of a computer-based information system include (i) hardware/software rental or depreciation charges. (ii) the salaries of computer operator and other data processing personnel who will operate the new system. (iii) the salaries of system analysts and computer programmers who perform the system maintenance function. (iv) the cost of input data preparation and control, (v) the cost of data processing supplies, (vi) the cost of maintaining the proper physical facilities including power, light. heat, air-conditioning. building rental or other facility charges and equipment and building maintenance charges. (vii) overhead charges of the business firm. (viii) costs of storing the data in machine-codes form etc., (ix) launching costs like staff training, file conversions, system testing. Intangible cost are costs that cannot be easily measured. For example, the development of anew 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. Installation costs like preparation costs of the site, delivery charges and other costs arising from any new equipment or computer required. Other costs: The introduction of new hardware implies the provision of space and special features for It (air-conditioning. electrical power etc.). Such costs are part of the system cost. In addition .new forms and other materials may be needed. It is very Important to consider how costs vary over time. The rate of investment is always an important factor for management, especially in relation to the rate of return. System Benefits: The benefits which result from developing new or improved information systems that utilise EDP can be subdivided into tangible and intelligible benefits: Tangible benefits are those that can be accurately measured and are directly related to the introduction of a new system such as a decrease in data processing cost. Intelligible benefits are more difficult to estimate and justify, usually requiring the skill of the particular management concern. Truly speaking. computer can be used for lots of activities whose benefits are intangible. For example greater accuracy. resulting from elimination of routine tedious tasks and more intensive checking, is difficult to evaluate. The computer can make time available to
37

managers for more useful activities instead of record keeping or control but it is difficult to assess the financial benefits or the likely utilisation of this extra time. Benefits that can result from the development of a computerised system are summarised below: 1. Increase in Sales or Profits (Improvement in product or service quality). 2. Decrease in Data Processing Costs (Elimination of unnecessary procedures and documents). 3. Decrease in Operating Costs. 4. Decrease in Required Investment. 5. Increased Operational ability and efficiency. 6. New or improved information availability. 7. Improved abilities in computation and analysis. 8. Reduction in clerical personnel. 9. Elimination of some specific costs. e.g., postage, Stationary, office machinery, etc. 10. Reduction in costs due to improved procedure, e.g.. data capture at source may eliminate some checking of data. Intangible Benefits. In almost every application there are clearly desirable effects. which are difficult to evaluate in monetary terms. Very often the benefit seems best described as "better information." But sometimes it is not possible, to analyse what is meant in anyone case by "better information" and to derive a monetary value. It is always worth the effort. because benefits in this area are usually great. By better information decisions will be improved. Thus how can we measure better decisions. The approach to follow is to take each decision in turn and to study in quantitative terms the effect of improved information on the decision. An improvement in the accuracy of information can be stated as an increase in the probability that the information is correct. The benefits to the company with an improved credit information system are potentially two fold: 1. Increased volume of sales. 2. Reduction in bad debts. They are obviously closely related to the companys previous performance in this area. If they have and on "easy" credit policy, then apparent sales may be reduced by an improved credit
38

information system but the bad debts level will go down. So the real income to the company will tend to increase as bad debts are reduced and credit as awarded to customers, who may previously have been wrongly thought to be bad risks. In this way a monetary figure can be established for the value of improved information. Return on Investment. Once the analysis of costs and benefits has been completed, the crucial test then arises whether the combination of the two factors makes the System a worthwhile proposition to the company. The term "WORTHWHILE has. of course, to be defined. If the criteria are to be strictly financial, then clear basis for decision can be established. The usual way to do this is to state the required payback period. The payback period is simply the span of time which elapses from the time the first part of the new system goes operational to the point when all invested and running costs have been recovered through the benefits of the new system. Hence It may require that all investment has been recovered within 18 months of system installation, as per a major computer user. This same company also required that the break-even condition (that is monthly benefits equal monthly running cost) is reached within 9 months. This is to guard against systems from which benefits may be large but which do not realise them until a relatively late stage. Remarks: 1. After the feasibility of each alternative has been studied the analyst Is likely to focus on the most promising solution. It may then be studied in greater detail (more data gathering) to make sure its basic assumptions are correct; Once the analyst feels comfortable with the conclusion. he or she is likely to make a written feasibility report. The feasibility report includes information about the primary solution as well as the alternatives. The report can be used as a basis for discussing the proposed solution with management-both systems management and the management of the department that Initiated the system study. Based on these discussions. the solutions may be modified or some of the conclusions changed. Once there is general agreement between all levels of management, the analyst is ready to begin the system proposal. 2. System Proposal. The systems proposal is a written presentation of the proposed system selected by the feasibility study. It usually indicates a summary of the problem and the proposed solution. In addition, it will give a schedule for completion of the project, a statement of what personnel are required to complete It and how the results of the project are to be evaluated. It may also state at what point the systems department will turn over the system to the user departments. In short, the systems proposal is an agreement between the systems department and all affected departments. After all parties review the initial draft of the proposal, modifications may be made to it. When all parties agree to it the proposal becomes a guide line for the rest of the systems project. . 2.6.6 Master Development Plan
39

It is a sort of blueprint of the System Development Effort. In a dynamic organisation, there are more opportunities for computer processing applications that can be handled at one time, necessitating an allocation process. Thus. Master Development Plan Is required. It Is a schedule of various applications to be computerised. Such a plan consists of following four stages: (i) The objectives of the proposed systems development efforts are elicited by the analyst. (ii) Current capabilities of the organisation are appraised by the analyst. This appraisal will cover the existing equipment. software applications and personal expenses, facility utilisation. (iii) The analyst reviews the possible technological developments In the computer hardware. (iv) Finally the analyst compiles the specific plan which comprises a hardware and software schedule, application development schedule, schedule of software maintenance and conversion efforts, personnel resources plan and financial resources plan. Master development plan basically is a schedule of various applications to be computerised, i.e., it consists of start and finish dates of systems analysis, design implementation and maintenance activities. This schedule is to be supported by manpower, hardware and financial schedules. Thus the master development plan for manufacturing organisations may comprise the following sequence of actions: (i) Identification of the objectives of applications (ii) a short description of applications to be computerised, their users and an Indication whether applications are new or a modification of existing ones. (iii) a statement on application priority and reasons for priority. For a manufacturing organisation, priorities for applications may be as follows : (a) Forecasting (b) Materials Planning (c) Inventory Control (d) Manufacturing operations scheduling (e) Shop order release (f) Despatching (g) Collection of production data. (iv) a statement on the time and financial resources which various applications will require.

40

(v) a description of how a particular application will be developed. The master development plan is based on the objectives of: 1. Avoiding the development of systems that would duplicate other systems already in use in the organisation. 2. Providing for integration of current systems or current and proposed application so that the resources are used wisely and efficiently. 3. Ensuring that systems are developed according "to an assessment of their development and operating costs and their value in achieving the objectives. 4. Ensuring that all systems are tied to the overall master plan. 5. Providing for continued development and evolvability of the information system while ensuring shareability of data and other resources. 6. Ensuring that users want and/or need all the systems and ensuring the systems will be used when implemented. Various components of a master development plan are discussed briefly below: (a) Organisation goals and objectives. This part of the plan contains the following sections: (i) Organisational objective (ii) External environment (iii) Internal organisational constraints (iv) Overall objectives for the computerised system (v) Overall structure for the computerised system. (b) Inventory of current capabilities. This part contains a summary of the current status of the Information system. It includes the following Items: (i) Inventory of equipments, generalised, software, application systems and personnel. (ii) Analysis of expense, facilities utilisation, status of projects in process and assessment of strengths and weaknesses. (c) Forecast of developments affecting the plan: Computer data processing is a striding field. It is highly desirable to be well versed with the computer market and technological developments. The hardware is known to have a great deal of Influence on the MIS centralisation and
41

decentralisation issue. The first generation computers were high in cost and large in size, hence the Information systems were sought to be centralised to derive benefits of hardware economies. The second generation computers were cheaper and the trend was towards MIS decentralisation. The third generation computers offered communication capabilities and the use of remote terminals. Hence the trend was reversed to centralisation again. Thus technological developments should be carefully studied before deciding on any kind of processing mode. (d) The specific plan consists of a schedule of the following: (i) a hardware and purchased software schedule. (ii) application development schedule (iii) schedule of software maintenance and conversion efforts. (iv) a personnel resource plan. Remark. At the end of the feasibility study a master plan is prepared in order to Inform management and Internal auditing department about the result of the Study. The main requirements to be specified by the master plan are that the conclusion and recommendations should be easy to understand, i.e.. it should give all Information required for decision making. A master plan which does not give clear statement of the organisational consequences, cost plan, and benefits of a system effort or not. It is highly desirable that it should cover all important features In such a way as to guarantee that management as well as auditors are adequately Informed. 2.6.7 Designing Phase Equipment Evaluation and Selection. Up to this point. the solution .has been stated In some that general terms. For example some type of equipment may have been indicated by the proposal. but specific purchases are not decided on until after the systems proposal is accepted. At this stage, then, the systems department may contact equipment vendors for information and prices concerning specific machines. When a systems proposal involves major equipment purchases, this phase of the system development can be a major project in itself. If the machines can be purchased, leased or rental at a price that stays within the limits stated in the systems proposal, the project continues as proposed. Otherwise the analyst may be forced to return to the feasibility and systems proposal phases with the unexpected cost data. A good analyst. however, will check prices and capabilities with several vendors during the feasibility analysis to make sure that the cost projections are reasonable.. He or she will not only consider the cost at the time of the study but most likely price as well. Systems Design. Up to the time of the systems proposal. analysts have concerned themselves with the local design of the system. Although they have decided that specific machines should be purchased. Furthermore, they havent decided what specific procedures should be followed. Instead, they concentrate on general systems flow, the cost of the system, and overall feasibility.
42

After the Systems proposal is agreed to; analysts or Systems Designers concern themselves with the physical design of the system. Here they create detailed specifications for every aspect of-the system. This Includes form designers, the organisations, procedural steps and so on. If a computer system is to be used. they will chart the steps required for all phases of processing. The following are the major steps in system design: 1. Specification of data element. records and file. 2. Specification of input forms, data preparation formats and identification of personnel who will complete them. 3. Specification of system output. 4. Development of system flowchart. 5. Development of feedback and control procedures. 6. Development of program specifications. 7. Development of operating specifications 8. Resource planning. 9. Implementation/plan/schedule phasing out the existing system training user /personnel system review and parallel operation. 2.6.8 System Design Components SCOPE AND BOUNDARIES Brief description of what the system will and will not try to do SPECIFIC REQUIREMENTS List of the output, data files, and Input necessary for the system CONCEPTUAL DESIGN Basic module and functional design which will satisfy the system requirements RESOURCE REQUIREMENTS The people, equipment, and dollars necessary to get each module working. TANGIBLE BENEFITS Reduction In direct operating expenses anticipated from the new system INTANGIBLE BENEFITS Other anticipated benefits of the new
43

COST /BENEFIT ANALYSIS

system, such as improved Information Comparison of the costs versus the benefits of the proposed new system

System requirements. The well-designed system must be: (i) practical: The three Ss (specialisation; simplification and standardisation), if applied, should ensure that the system is easy to use and maintain, (ii) economical: Seeking minimum cost of not fulfilling operational requirements is a mistake. However, running costs (as well as capital costs) should be assessed and compared, if possible, with the costs of the existing system, (iii) efficient: Good work flow will make good use of all staff 2nd equipment. For example, efficient data transmission to and from the computer, efficient use of the computer, good file organisation, good linking with clerical procedures etc. Computer equipment setup and speed are a further important design consideration. (iv) flexible: It is important to allow for system upgrading (of both hardware and software) and to design the system to cope with peak loads (or use a bureau). It may also be possible to integrate previously separate procedures immediately or in the future. (v) reliable: The system hardware and software must be reliable, preferably proven in use, and arrangements should be made for its maintenance, (vi) secure: It is important to have good Back-up arrangements for the hardware (e.g.. standby generators), software (e.g.. copy programs) and a sound system of internal control. The auditors must be satisfied with the practical controls and audit trail and with the administrative and physical controls. Depending on department standards, Systems designers may also prepare detailed program specifications for each program required by the new system. These specifications can be passed to the programming department for program development. Systems designers will also prepare a detailed implementation schedule and plan for all stages of implementation. In short, the main objective of this phase Is to obtain a detailed System design for implementation. The means that the entire system has to be defined in terms of information flow, files, volume. print designs. procedures, forms. program specifications. etc. In addition to these a revised estimate of the operational cost of the system is calculated after the design has been completed and a revised plan for implementation produced. The activities which are undertaken in this phase are: 1. Finalize Information flow, data elements, output requirement, data relationships, etc.

44

2. Identify master files, working files, data volumes, frequency of updating, length of retention. speed of response required from files. 3. Determine the file organization, and layouts. 4. Specify input layouts, frequency, etc. 5. Define reporting requirements, volume, frequency, distribution. 6. Develop overall System logic. 7. Determine controls and audit procedures. 8. Identify computer programs and manual procedures required. 9. Prepared program specifications. 10. Develop general test requirements (type of data, sources, control checks. etc.) 11. Revise estimate of operational costs of system. 12. Produce detailed plan of implementation. 13. Document the Design phase in a report for user and systems management. 14. Decide which storage devices should be used. 15. Decide on division of the computer-based parts of the system into individual computer runs. An important tool for use at this stage is decision tables. They are invaluable in defining the relationships between data. programs and users. Decision tables have a range of uses, and are particularly effective at the system design stage. In conjunction with flowcharting, they are major means of developing a systems design. It is at this stage that systems and audit controls should be bunt into the system. This implies consultations with company auditors. An important task for the systems analyst at this stage is the identification of computer programs and the development of program specifications. Criteria for dividing the processing procedure into programs: 1. Size of each processing step (the installation should have advisory standard for the maximum and preferred size program. depending on the computer and configuration). 2. Logical units (Inputs validation, printing runs. sorts etc. are clearly identifiable as performing basically different functions).
45

3. Ease of amendment (the steps can be classified according to their likelihood of change. the areas of probable stability can then be separated from the ones of probable change). 4. Time relationships (there will be natural breaks in processing funs due to waiting for user actions etc.) 5. Suitability for controlling (discussions with the auditors will pinpoint certain stages and check points). 6. Suitability for testing (it is important to bear in mind Implementation factors at this design stage; the possibilities for testing programs and portions of the system in terms of data sources volumes etc., should be considered). A very important strategy to follow in dividing the system into units is that of modularity. This is a basic philosophy applicable to any kind of problem solving. Divide the overall problem into sub-division which can be more easily handled separately. The Implications, however, go much further. For example: (a) The job is separated into skilled and less skilled parts, so the personnel resources available can be used to best advantage. (b) Modular systems make documentation easier to create. (c) Modification is much easier. (d) The system is easier to test when it has a modular structure. (e) The design of modules forces a thorough analysis and understanding of the problem. (f) Integration with other systems is easier with modular systems. (g) General-purpose modules (for example, Input control) can be used in other systems. The systems design phase culminates in a document which is then approved or modified by user and DP management. The whole project may be dropped if it is impossible to achieve a system design which satisfies both. In the more likely event, however, that it is accepted, after modifications, this document acts as the specifications for the implementation phase. The contents of the design specification are: 1. Narrative of system functions. 2. General flowchart showing major system of function (both manual and computer). 3. Identification and relationship of input, output and rues.
46

4. Identification and relationship of programs. 5. Detailed flowcharts showing Interaction of input, output and files. 6. Program specifications. 7. File classifications. In addition to the design specifications a revised estimate of project, costs and implementation activities should be submitted to management at this stage. If these are acceptable, then the project is ready to move Into the estimating implementation phase, when the results of the workInvested In the project begin to show in concrete form. 2.6.9 System Documentation System documentation means coordinated effort, to communicate the information of the system in written form. Its purpose is to ensure that the details of the system are understood by all the persons concerned during the development process and subsequent operation. Objectives of Documentation : 1. To narrow down the communication gaps among users, designers, and management. 2. To provide the necessary Information to develop training programme for operators and users. 3. To create a vehicle of information to provide evidence of progress in the development process and to monitor the process. 4. To provide a means to determine m advance what will occur and when. 5. To make system modifications and implementation easier. 6. To make conversion of a system from one machine to another machine easier. Characteristics of a Good Documentation : 1. Availability. It should be accessible to those for whom it is intended. 2. Objectivity. It must be clearly stated in the language that is easily understood. 3. Considerable. It should be possible to refer to other documents. 4. Easy to maintain when the system gets modified it should be easy to update the documentation.

47

5. Completeness. It should contain everything needed, so that those who are reading it carefully understand the system. Levels of documentation. There are 3 levels of documentation. (a) Documentation for Management. This includes systems proposals covering the following: (i) Concepts -architectural design (ii) Functional design -functional requirements (iii) Resources required (iv) Development schedule (v) Cost-benefit analysis The management should review the proposal to ascertain whether the project will be further continued or abandoned. (b) Documentation for user. For the smooth operation of the system. it is essential that the user understands the system fully, and is aware of what is expected of him to make it work successfully. 1. The documentation for user should explain in non-technical all aspects of the system from users point of view. 2. It should also explain how the system will operate o installed. 3. The documentation should include a sample of each in and instructions for using it. 4. It should include a sample of each output report with explanations. 5. It should also indicate operating schedules. 6. Users documentation should cover files layout and details. 7. Limitations of systems should also be highlighted. 8. It should state the input document coding procedure, coding structure for various fields and related tables. (c) Documentation for data processing department. This divided into following 3 categories: (i) Documentation for systems designers:

48

The documentation for system designers consist of the following 1. System flowchart 2. Input from layouts 3. Output report layout 4. Layouts of Master files 5. Layouts of intermediate files 6. Implementation plan 7. Controls 8. Copy of program specifications 9. 1/0 Schedules. (ii) Documentation for programmers -For each program there should be a program older following -Program specifications, I/O layouts -Changes in specifications during program -Development or system test run -Source program listings -Test data listing -Test results -JCL listing -Program logic flowchart -Usage of any special technique (iii) Documentation for operations personnel. This has 3 subgroups. 1. Data preparations: The documentations should provide samples of all Input documents, card layouts, record layouts, special instruments for data preparations. retention schedules for data.
49

2. Machine operations: This should include: (i) System flow (ii) Detailed instructions for each step (iii) J.C.L. Listings for each step (iv) File retention schedules (v) Interrupt/Restart procedures 3. I/0 Control: (i) Processing schedules (ii) Document receipt details (iii) Quality control checking procedures for each step (iv) Despatching (reports) details. 2.7 Systems Communication Having investigated, analysed and designed the new system. It is necessary to communicate to the people concerned about all Its Implications. For example. the senior management must be made aware of all the Implications. advantages and benefits that will accrue, Its effect on existing procedures and personnel. and the time scale in which it will be implemented. The heads of departments concerned will have to be advised of the effect of their departments and of revised procedures. The question of training and retraining of the staff or its redevelopment will have to be posed to department chiefs. Finally. the data processing department will have to be communicated detailed descriptions of the proposed system to enable Implementation. By this time the documentation of the new system should have been completed. This Involves a report giving aims of the system. its detailed description. changeover procedures, equipment to be utilised, input and output layouts. program description and the critical schedule dates for implementing the system by using such techniques as GANIT or PERT charts. 2.8 System Implementation It consists of those tasks which are necessary to bring a developed system or sub-system Into operational use and turning It over to the user. It involves programmers, users and operational management, but its planning and timing is a price function of systems analysts. It also includes the final testing of the complete system to users satisfaction and supervision of the initial operations of the new system. Thus activities carried out in this phase are as follows:

50

(i) Conducting training program. This activity is concerned with the introduction and training of the management and personnel of the user organisation and of the application programmers and operators. The purpose of this training is to ensure that all personnel concerned possess all the knowledge and skills required for implementation of the new system. (ii) Install equipment. The result of this activity is on-site tested equipment ready for system testing, conversion and other activities in the Implementation. The activity should stand early in the system effort, usually at the end of feasibility study. It consists of the following steps: (a) site preparation (b) installation of data processing equipment (c) hardware and software check. (iii) Prepare operating schedules. The purpose of this step is to devise operating schedules which ensure that all system outputs are produced at the correct times and that the best possible use is made of the available resources such as computer time, personnel, etc. (iv) Convert programs and files. This activity deals with the performance of the actual conversion of programs and files. File conversion is necessary wherever existing programs are to be run on a new configuration. This activity consists of the following steps : (a) perform program conversion (b) gather roe conversion data (c) perform file conversion (d) check out converted roes. (v) Begin new operations. This activity is sub-divided into following steps: (a) start operation of new system (b) evaluate early results (c) turn-over system to users (d) maintain implemented system. (vi) Maintain the system. Since, in practice, flow systems are, perfectly designed and developed, implementation also includes the correction of shortcomings. which result in partial repetition of previous activities.

51

(vii) Parallel operation. Use the new system at same time as the old system to compare the results. IMPLEMENTATION COMPONENTS PERSONNEL ORIENTATION Introduce people to the new system and their relationship to the system. TRAINING Give employees the tools and Techniques to operate and use the system. HARDWARE Schedule for, prepare for, and then actually INSTALLATION install new equipment. PROCEDURE WRITING Develop procedure manual to follow in operating new system. TESTING Ensure that the computer programs properly process the data. FILE CONVERSIN Load the information in the present files on to the new systems files. PARALLEL OPERATION Use the new system at the same time as the old to make such results are corrects. 2.9 System Evalution System Evaluation Components DOCUMENTATION REVIEW COST ANALYSIS BENEFIT ANALYSIS Look over the documentation and determine if it is adequate Compare the actual costs of the system with the anticipate costs in the system Design. Compare the actual benefits of the system with the anticipated banefits In the system design. Analysis whether the system is being used and whether the users like the system. Evaluate internal controls to see if They are adequate and if policies are being followed Detail any deficiencies in the system As it is actually operating Suggest improvements to the design or ways the system could operate more efficiently

ACCEPTANCE BY USERS INTERNAL CONTROLS

DEFICIENCIES

RECOMMENDATION

When the system begins operating, a formal evaluation procedure is put into effect to monitor the results of the operation. The Systems Evaluation Phase continues for the life of the System
52

materially aiding in the discovery of both system weaknesses and trends in processing activity. The results of these formal evaluations are used in the Long-Range Planning for the subsequent system. In brief the purpose of evaluation is to find out whether the system has achieved what it was intended to do. Consideration errors and exceptions, flow of work, efficiency of file storage, machine utilisation actual and planned, savings actual and planned and value of Information produced. User Involvement. Finally, it may be stated that to achieve best result, the user Involvement must be ensured. Today many organizations are spending substantial sums of money for data processing equipment and for the systems analysis. design arid programming that go along with this equipment. What usually happens when an organization decides that it wants a work to be computerised, it writes the computer programs, makes the conversion, and then begins the automated operation. Usually, the development of the applications is quite hectic. There are many changes during the programming. A last minute decision as to whether to change the conversion data computer Installation etc., the final result is usually a system that falls short of what the functional department thought they were going to get. This possibly could have been avoided if a proper system development effort is put in before a system goes on the air. We realise very late in the day that "too little time was spent at the beginning and too much time at the ends." Usually, one more reason why this happens. This is that data processing specialists are too equipment and programming-oriented and the functional people dont actively and meaningfully take part in the development of the systems. In order to successfully launch a system development effort, it must be ensured that a system team consisting of Head of the user Department and systems Analyst should be formed. The system development effort should be a joint effort and there should be no understanding gap" between the data processing and functional specialists. This active involvement of functional specialists is necessary because they know the present system and its nuances having worked in it for a period of time. This type of knowledge cannot be acquired by systems analyst in a short time. Also the system design is completed. it can be reviewed by them for reasonableness and accuracy. Finally, when the effort is complete, it will belong to the Functional Specialists because they have been associated throughout the systems development effort and the system is meant for them. For implementing EDP system in a complex organisation, there are in general three major phases of study; namely (i) Technical (ii) Operational and (iii) Economical (i) Technical. It is divided into the following: (a) Hardware-Input/output, communication, and storage. (b) Software-Data Base, Operating System and Languages.

53

(c) Applications-System Packages, Management System and Models. (ii) Operational. It is divided into the following: (a) Management- Top Management, Middle Management, and Operating Management. (b) Non-Management-Non-cooperative Clerical Department. Cooperative Clerical department Workers. (c) General-Regulatory, Agencies, Customers. (iii) Economical. It is subdivided into three categories; namely (a) Benefits- Tangible and Intangible. (b) Savings-Supplies / operating Expenses (clerical). (c) Cost-Systems/Programmers, Operators. Hardware/Software. Exercise: 1. What is system analysis ? 2. Why system analysis ? 3. Explain the Need for system analysis. 4. Discuss the procedure of Analysing the Existing system. 5. Write a short note on: a) Problem Definition b) Data gathering c) Feasibility study d) Design phase Explain the objectives and characteristics of a good documentation. Copyright 2011 SMU Powered by Sikkim Manipal University
. 54

MT0032-Unit-03-System Development Life Cycle [SDLC]

Unit-03-System Development Life Cycle [SDLC] Structure: 3.0 Models of Information System 3.1 System Development Life Cycle [SDLC] 3.1.1 Problem Definition 3.1.2 Feasibility Study 3.1.3 System Analysis 3.1.4 System Design 3.1.5 System Development 3.1.6 System Implementation 3.1.7 Post-Implementation Maintenance & Review 3.2 Organization of Electronic Data Processing Department (EDP) 3.2.1 Organisation chart of EDP Department 3.2.2 The role of personnel involved in DP organization and their responsibilities / Duties 3.2.3 System Analyst 3.2.4 Chief System Analyst Responsibilities / Duties Are 3.2.5 Systems Analyst Responsibilities / Duties Are 3.3 Why System Projects? 3.3.1 Capability 3.3.2 Control 3.3.3 Communication
55

3.3.4 Cost 3.3.5 Competitiveness 3.4 Sources of Project Requests 3.4.1 Requests from Department Managers 3.4.2 Requests from Senior Executives 3.4.3 Requests from System Analysts 3.4.4 Requests from Outside Groups 3.5 Managing Project Review and Selection 3.5.1 Steering Committee 3.5.2 User-Group Committee 3.5.3 The Project Request 3.0 Models of Information System The information systems are considered to be evolved through three different levels of the system .these are: a) Conceptual system: every information processing system is evolved by way of a concept when somebody imagines that the organization should have such and such a system to accomplish such and such objectives. A system so conceived may or may not be attained in reality. A conceptual model is no more than an idea. b) Logical system: when the conceived system model is further worked out to design new ways to accomplish the objective set out in the conceptual system, it becomes the logical system design. A logical system design necessarily includes understanding of the flow of information, logical of processing and input-output relationship. The Data Flow Diagram [DFD], Flow chart etc are the basic component of the logical models. c) Physical system: When the logical models are developed to actually deliver the desired results, it is referred to as a physical system models. The physical system model can be tested and implemented. It consists of programs, data files and documentation. 3.1 System Development Life Cycle [SDLC] System development is an iterative process and it consists of the following stages:

56

a) Problem Definition b) Feasibility Study c) System Analysis d) System Design e) System Development f) Implementation g) Post Implementation Maintenance & Review Every stage of the system development life cycle is marked by an identifiable end result as well as sub activity. SDLC Stage Problem Definition Feasibility Study End Result [Activities] Statement of scope and objectives. Opportunities and performance criteria. Scope & Objectives of Economic/ Technical/ Political/ Feasibility Report. Financial viability and Modification of system Analysing the Logical Model of the system consisting of details such as data flow diagrams, data dictionary etc. Alternative solutions along with revised cost benefit analysis, Hardware specifications manpower requirements, plan for implementation user sign off, test plans, formal system test procedures, security, audit and operating procedures. Actual programming as per the user sign off, compilation and testing of the programmes. Training of the user staff, system documentation, implementation Refined and Tuned System along with revised documentation, satisfied users.

System Analysis

System Design

System Development

System Implementation Post implementation Maintenance & Review 3.1.1 Problem Definition

Organisations face problems during their operations and come across opportunities which could be converted into profitable solutions. Whenever there is an opportunity and/or problem in the

57

existing system or when a system is being developed for the first time the organization considers designing a new system for information processing. The organization may face a problem or get an opportunity due to: -A new product/plant/branch/market/process -A failure of an existing system -Inefficiency of an existing system -Programming errors in the existing system and therefore, a thorough analysis of the situation is required. For identifying problems and/or opportunities, we scan: -The performance of the system -The information being supplied and its form -The economy of processing -The control on the information processing -The efficiency of the existing system -The security of the data, software, equipment, personnel etc. After identifying the problem, it is defined and a general direction for solving its problem is also determined. The project boundaries are also defined. The management also establishes the terms of reference as well as the resources to be provided for the project. Final output of this stage is Terms of Reference 3.1.2 Feasibility Study After the user has identified the need for a new system, his requirements are determined and the terms of reference are established. The proposed system has to be viewed from the practical utility and acceptability dimension. A few questions which are usually asked during this stage are: a) Is the proposed system worth developing? b) Will the proposed system contribute by way of improved efficiency, productivity or organizational effectiveness?
58

c) Will the system improve information availability and be cost effective? d) What will be the system development costs and will these be justifiable? e) How will the user departments take this system and what will be the overall impact of this system on the organization? The key considerations involved in the feasibility analysis are: - Economic - Technical - Behavioural The economic feasibility will only consider the cost/benefit analysis of the proposed project. The benefits are always expected to be overweighing the costs. The technical feasibility always focuses on the existing computer hardware and software. This also includes the need for more hardware or software and the possibility of procuring/installing such facility. The behavioral feasibility includes a study of the organizational behavior. An estimate of how strong the user reaction will be to the new system will have to make at this stage. The final output of this step is a Feasibility Report having discussions on Financial Feasibility, Economic Viability, Technical Feasibility and Social Acceptability of the proposed system. 3.1.3 System Analysis The system analysis includes review of the existing procedures and information flow. Decision making and individual information needs at various levels in different functional areas are also reviewed. The system analysis phase primarily focuses on isolation of deficiencies from the existing system. The fundamental activities involved in the system analysis are: - Definition of the overall system - Separation of the system into smaller and manageable parts. - Understanding the nature, function and interrelationships of various subsystems. The analysis of the information systems could be done with the help of various tools of system analysis. Some of the tools which are available with the system analysts are:

59

 Review of Documentation: Documentation on the existing system could be reviewed and analysed to study the objectives, reports, procedures being followed and equipment being used. The only limitation with this technique is that the documentation on any existing system is never complete and up-to-date. Observation of the Situation: The system under study can always be observed by getting involved in the system. The system analyst can work in the system or can be a mere observer. The exercise is time consuming and costly. Also it has an inherent limitation of the fact that the analyst may never be able to observe the intricacies of the system. Conducting Interviews: The system analyst can conduct interviews with the user managers and ask questions related to their job responsibilities. The interviews could be formal or informal ones and may span over a period of time. The limitation of this tool is that the user manager may not be able to explain the problem in detail. Questionnaire Administration: A printed structured or unstructured questionnaire may be administered to find out the information needs of individual mangers. The questionnaire survey does help in saving time as compared to interviews as well as gets more committed data, but it is impossible to design an exhaustive questionnaire to cover various aspects of the system under study. The analysis uses a combination of all these tools to analyse an existing system. The analysis phase is a time consuming phase and yet a very crucial phase. The final output of this phase is a functional specification report of the existing system. 3.1.4 System Design If the system analysis phase defines the way things are, the system development phase defines the way things should be for the same problem. The system development phase includes mapping of the business requirements of the managers on to the proposed system. The conceptual design of the model which has been developed in the problem definition stage is enlarged to understand the actual flow of data and the logical model is developed. The logical model is worked out to finally develop and test the physical system in the system development phase. The system design should be as hardware and software environment independent as possible. The system development team should always keep in mind the cost effectiveness. This phase includes development of the following: Output Definitions Input Definitions Data Element Dictionary
60

 Program Specifications System Specifications During the system development, the analysts also undertake the codification and compression of the data to: - Use lesser magnetic storage space - Commit lesser mistakes while entering data - Maintain uniformity of data - Incur lesser cost in entering, updating, processing and storage of data. Output Definitions: Are there detailed reports, screen and file layouts which will be outputted by the programs throughout the system? The system analyst is required to consult the user in finalising the system outputs. Input Definitions: The data coming into the system has to come through some input formats and these formats are defined by the design of input documents. Data Element Dictionary: A document which contains bonafide details of each and every data item used in the system is called a data dictionary. The data dictionary contains the following details regarding the data items: Name Description Source Usage Maintenance Storage Organisation

Program Specifications: The actual logic built up for individual programs is defined in the Program specifications by way of decision tables, decision tress and program flow charts. The program flow charts could be drawn for individual programs or parts of the programs. These tools are necessarily used for storing the logic of processing in individual programs for future reference. The logic could also be stored by using English language which is also referred to as pseudocode.
61

System Specifications: The system specifications include description of the relationships of various modules of the system among each other and relationships between different programs within a subsystem? Though the system specifications do not give the details of logic being followed, it gives the flow processing among the programs, files and reports. Apart from using descriptive English, the system developer also use System Flow Charts for depicting system specifications.

The end result of this phase is a design specification report which includes the existing system, the proposed system, system flow charts, modular design of the system, print layout charts, data file designs etc. 3.1.5 System Development Following the modular design of the proposed system, the system analysts assign specific responsibilities to the programmers who develop and test the programs. The development and testing of the systems take place in a phased manner: Development and testing of the individual programs Development and testing of the individual programs as a part of the system modules. Development and testing of the system modules as a part of the major subsystems. Development and testing of the major subsystems as a part of the proposed system. The development of the system includes writing of the actual programs to handle data. Excellent programming skills and experience are required for this phase of the system development life cycle. The basic activities involved in this phase are: Checking of the program specifications received from the system development stage and expanding these specifications. Breaking the system modules into smaller programs and allocating these programs to the members of the system development team. Producing the program code in the chosen computer programming language. Defining the interfaces between various programs and designing tests for checking their interfaces. Ensuring the data availability for individual and integrated testing. Checking the quality of the code and its adherence to the established standards. Prepare the documentation for each one of the programs. Receiving the user data for acceptance testing
62

 Getting the user sign-off after the acceptance testing. For development of the proposed system, it is important that all possible support should be provided to the development team. This support includes availability of: Office space Relevant Data Secretarial Assistance Access to key functionaries throughout the system development effort. The final output of this phase is a fully developed and tested software system along with complete documentation and testing results. 3.1.6 System Implementation Once the system has been declared fully developed and tested by the development team, it is ready for implementation with the user department. The involvement of the user is necessary throughout the project duration, but the user involvement is critical during this phase. The implementation includes the following activities: Planning for implementation Preparing the schedule for implementation Procurement of hardware Installation of software Operation and testing of software on hardware Recruitment of operating personnel Motivation and training of the selected personnel and users Conversion of data files from old system Final changeover Operation and procedures Once the system has been implemented, the system group provides outside support to the user group and trains the user group to handle production and operations of the system.
63

3.1.7 Post-Implementation Maintenance & Review Though the system is thoroughly tested before the implementation, yet the system is never full proof and errors always continue to exist. Therefore, there is a need to have a systems person to look after the system and maintain it even during the operation and production. The system maintenance could be because of any of the following reasons: Minor changes in the processing logic Errors detected during the processing Revision of the formats of the reports Revision of the formats of the data inputs Also the management is keen to know the quality of the system developed and the standards which have been followed. There is usually a review team which evaluates the implemented systems and suggests changes, if required. It also leads to integrated and standardized system development. 3.2 Organization of Electronic Data Processing Department (EDP) The Electronic Data Processing Department has specific functions to be performed which includes: - System department and programming - Computer system operation - Control over data , reports and files. - Data preparation Business organisation for large computers services department in a multi-unit organisation should be loaded by a person equivalent to the rank of director. Assisted by a team of managers for system analysis and design, programming , computer control. 3.2.1 Organisation chart of EDP Department.

64

3.2.2 The role of personnel involved in DP organization and their responsibilities / Duties Management Services Director: He has responsibilities for all aspects of data processing, operation research, organization and method, system analysis and design investment etc. Only very large organizations are likely to have management services departments. Data processing Manager [computer manager] He is responsible for the efficient running of the department and must therefore to be a good administrator as well as having some knowledge His main duties are: I. Planning and controlling the department. II. Supervising on department avoidities, staff selection and training. III. Preparing department budgets. IV. Liaising technical between general management [non computer] and the technical members of his staff. V. Reports to senior management / board of directors / management services directors on systems development and operations. VI. Assessing the effectiveness of file maintenance procedures and suitability of file security procedures,. VII. Providing a guidance on data processing problems
65

VIII. Development and implementation of processing standards IX. Ensuring that staff attend suitable training courses for their development. 3.2.3 System Analyst System analyst are progress through three levels during their career the begin as analyst become Senior Systems Analyst after they have gained the requisite experience, and finally are appointed as chief system analyst. 3.2.4 Chief System Analyst Responsibilities / Duties Are I. Carries out feasibility studies on exiting and proposed systems to determine the economic viability of computer processing within them. II. When system economically viable proportions , which found , prepares outline systems specifications, which show the computer would operate, and estimate the time required for develop and implement the proposed system . III. Assess the resources required for and total cost of preparing and installing the computer procedures and supporting manual systems. Developed in the outline specifications. IV. Submits a formal report to gain management acceptance of the proposals, and conducts any necessary verbal presentations. V. When job is accepted, monitors development progress through regular reviews meetings. VI. Assists in recruiting and training of systems staff and reviews their performances. VII. Lays down standards and techniques to be observed in systems work. And ensures conformity within them. VIII. Receiving the performance of the implemented systems and assessing the need for amendments. 3.2.5 Systems Analyst Responsibilities / Duties Are : I. Liasion with user departments to ensure that their requirements and problems are fully discussed before systems design and implementation. II. Investigating of the existing system by means of interviews, questionaires and observations. III. Conducting the technical, operational and economic feasibility study and participating in the development of the master plan. IV. Comparing the Cost and performance of alternative procedures and techniques.
66

V. Presenting recommendations to data processing and user department management with regard to possible defined objectives. VI. Designing a new system which is practical and efficient for inputs, outputs and files and documenting it with flow charts, decision tables, file layouts etc. VII. Designing implementation and integration of new applications. VIII. Coordinate the implementation of new or modified systems, and its maintenance thereafter. IX. Assesses the levels of control required and maintains liaison with auditors to ensure that the design meets their needs. X. Organizing and reviewing system documentation to ensure that it complies with data processing standards. XI. Defines the input, output, files and processing requirements at the computer system and specifies these in detail in the standard manner required for notification to the programming staff. XII. Provides test data to validate the system, arrange trials, and controls the implementation program. Until the project is accepted as fully operational. XIII. Reports regularly on the progress of the assignment to his immediate supervisor and brings implementation problems to his attention. XIV. Makes periodic checks to ensure that the operational system continues to meet the specifications. 3.3 Why System Projects? Systems projects are initiated for different reasons. The most important reasons are: 3.3.1 Capability Business activities are influenced by an organisations ability to process transactions quickly and efficiently. Information systems add capability in three ways: (i) Improved processing speed: The inherent speed with which computers process data .is one reason why organisations seek the development of systems projects. (ii) Increased volume: Provide capacity to process a greater amount of activity, perhaps to take advantage of new business opportunities. (iii) Faster retrieval of information: Locating and retrieving information from storage. The ability in conducting complex searches.
67

3.3.2 Control (i) Greater accuracy and consistency: Carrying out computing steps, including arithmetic, correctly and consistently. (ii) Better security: Safeguarding sensitive and important data in a form that is accessible only to authorised personnel. 3.3.3 Communication (i) Enhanced communication: Speeding the flow of information and messages between remote locations as well as within offices. This includes the transmission of documents within offices. (ii) Integration of business areas: Coordinating business activities taking place in separate areas of an organisation, through capture and distribution of information. 3.3.4 Cost (i) Monitor costs: Tracking the costs of labour, goods and overhead is essential to determine whether a firm is performing in line with expectations -within budget. (ii) Reduce costs: Using computing capability to process data at a lower cost than possible with other methods, while maintaining accuracy and performance levels. 3.3.5 Competitiveness (i) Lock in customers: Changing the relationship with and services provided to customers in such a way that they will not think of changing suppliers. (ii) Lock out competitors: Reducing the chances of entering the competitors in the same market because of good information systems being used in the organisation. (iii) Improve arrangements with suppliers: Changing the pricing, service or delivery arrangements, or relationship between suppliers and the organisation to benefit the firm. (iv) New product development: Introducing new products with characteristics that use or are influenced by information technology. 3.4 Sources of Project Requests There are mainly four primary sources of project requests. The requesters inside the organisation are: Department Managers, Senior Executives and Systems Analysts. In addition, government agencies outside the organisation may also ask for information systems projects. 3.4.1 Requests from Department Managers

68

Frequently, department managers who deal with day-to-day business activities, are looking for assistance within their departments. They are often not satisfied with the amount of time that the staff takes to complete the job. Sometimes, they feel that the staff members are involved in duplication of work also. In this case, the manager will discuss this problem with other administrators regarding their clerical as well as processing work and persuade higher authority to approve the development of a computer based system for office administration. 3.4.2 Requests from Senior Executives Senior executives like presidents, vice-presidents usually have more information about the organisation as compared to department managers. Since these executives manage the entire organisation, so naturally they have broader responsibilities. Obviously, systems project requests submitted by them carry more weightage and are generally broader in scope also. 3.4.3 Requests from System. Analysts Sometimes systems analysts find areas where it is possible to develop projects. In such cases, they may prefer either writing systems proposal themselves or encouraging a manager to allow the writing of a proposal on their behalf. For instance, in an organisation, an analyst sees that the library information system takes more time in processing and is inefficient, may prepare a project proposal for a new library information system. By the direction of the analyst who is fully aware about the new technology that improves the existing library information system, the librarian may initiate the development of information system to the higher authority for approval. . 3.4.4 Requests from Outside Groups Developments outside the organisation also lead to project requests. For example, government contractors are required to use special cost accounting systems with government stipulated features. Generally, it has been observed that new demands from external groups bring about project requests, either for new systems or changes in current ones. Project requests originated from this source are also quite important 3.5 Managing Project Review and Selection It is true that a number of requests for systems development are generated in the organisation. Someone in the organisation must decide which requests to pursue and which to reject. The criteria to accept or reject a request can be decided in a number of ways. One of the suitable methods commonly in use is by committee. Mainly three committees formats are commonly used: (i) Steering Committee (ii) Information Systems Committee (iii) User-Group Committee
69

3.5.1 Steering Committee This is one of the most common methods of reviewing and selecting projects for development. Such a committee, consisting of key managers from various departments of the organisation as well as members of information systems group, is responsible for supervising the review of project proposals. This committee receives requests for proposal and evaluates them. The main responsibility of the committee is to take decision, which often requires more information than the proposal provides. It is, therefore, desired to have preliminary investigation to gather more details. The steering committee approach is generally favoured because systems projects are considered as business investments. Management, not systems analysts or designers, selects projects for development. Decisions are made on the basis of the cost of the project, its benefit to the organisation and the feasibility of accomplishing the development within the limits of information systems technology. Information Systems Committee In some organisations, the responsibility for reviewing project requests is entrusted to a committee of managers and analysts in the information systems department. Under this method, all requests for service and development are submitted directly to a review committee within the information systems department. This committee approves or disapproves projects and sets priorities, indicating which projects are most important and should receive immediate attention. This method can be used when many requests are for routine services or maintenance on existing applications. When major equipment decisions are required or when long- term development commitments are needed to undertake a project, the decision authority is shared with senior executives who decide finally whether a project should proceed or not. 3.5.2 User-Group Committee In some organisations, the responsibility for project decisions is entrusted to the users themselves. Individual departments hire their own analysts and designers who handle project selection and carry out development Although the practice of having user committees both choose and develop systems does take some of the burden from the systems development group, it can have disadvantages for the users. Some user groups may find themselves with defective or Poorly designed systems that require additional time and effort to undo any damage caused by the mis-information that such systems could generate. Although user groups may find the decisions of steering committees and information systems committees disappointing at times, the success rate for users who undertake development job is not very encouraging. 3.5.3 The Project Request The project proposals submitted by the users or the analysts to the project selection commit- tee is a critical element in launching the systems study. There is a general agreement that a project request form should contain the following: What is the problem?

70

 What are the details of the problem? How significant is the problem? What does user feel is the solution? How will the information systems help? Who else knows about this and could be contacted? The project selection committee is responsible to review the proposals carefully and finally selects those projects which are most beneficial to the organisation. Therefore, a preliminary investigation is often requested to gather details which are asked in the project request forms. Exercise: 1. Explain briefly SDLC stages. 2. Write a note on System Implementation ? 3. Draw a EDP organization chart for large computer based organization. 4. Discuss the responsibilities/Duties of system Analyst. 5.Why system project ? Discuss the important reasons for system project. Copyright 2011 SMU Powered by Sikkim Manipal University .

71

MT0032-Unit-04-System Development Tools

Unit-04-System Development Tools Structure: 4.1 Introduction 4.2 To approach system design follows tools are used to organize their system projects 4.2.1 System flowchart 4.2.2 System flowchart symbols 4.2.3 System flowchart mainly consists of following three steps 4.3 Decision Tables 4.3.1 Formation of decision table 4.3.2 Advantages of Decision Table 4.3.3 Drawbacks of Decision Tables 4.4 Types of Decision Tables 4.4.1 Limited Entry decision table 4.4.2 Extended entry decision table 4.4.3 Mixed entry decision table 4.5 Decision Trees 4.6 Data Flow Diagrams 4.6.1 Charting tools used for DFDs 4.6.2 Data Flow Diagram Charting Forms 4.7 Data Dictionaries 4.7.1 Major Symbols 4.7.2 Four Rules
72

4.7.3 Data Dictionary functions 4.7.4 Passive Data Dictionaries 4.7.5 Active Data Dictionaries 4.7.6 In-line Data Dictionaries 4.8 HIPO 4.9 Warnier-ORR Diagrams 4.10 NS Charts 4.1 Introduction System design consists of preliminary investigation and feasibility study. Detailed investigation consisting of Fact- finding Data analysis and evaluation Estimating the cost and benefits. Preparation of system proposal By maintaining the objectivity of fact-finding the analyst can separate habitual or traditional acts from acts resulting from octal requirements and thus ultimately evolve a suitable system design in the data analysis and evolution phase. Data analysis and evaluation consist of recording, arranging evaluating collected facts. Information system personnel begin to extract significant factors that help them identify the users system requirements from this wealth of data. Increasingly analyst are using computerassisted software engineering [CASE] tools to organize and analyze data. The term CASE has been coined to refer to the automation of tools, methods and processors used in system developments. The products that accomplish the automation are computer programmer. Referred to collectively as CASE tools. They are grouped within two broad categories: 1) These tools assist in the analysis of user requirements, description of data elements, description of operations, a high level system design computes, inputs and file formats, highlevel internal program structure and so on. 2) Back end CASE tools : these are the tools used to convert specifications into machine executable codes, assist in debugging and testing and / or restructuring exiting database and programs.
73

4.2 To approach system design follows tools are used to organize their system projects 1) System flowchart 2) Decision Tables 3) Decision Trees 4) Organization chart 4.2.1 System flowchart System flowchart gives defining the flow of the data through an organisation or a company or series of tasks that may or may not represent computerized processing. Or system flowchart is a graphical model that illustrates each basic step of data processing routines or system. Which indicates the flow of work / system, document and operations in a data processing application 4.2.2 System flowchart symbols Symbol Description PROCESSING : A major processions functions Example: INPUT / OUTPUT : ACCEPTING DETAILS FROM SOURCES. Indicates the screen output Example: ON LINE STORAGE Data storage on magnetic media as a file . Example: DOCUMENT: Hard copy of the report

74

( paper document ) Example: OFFLINE STORAGE [old system] Data storage on paper cards. KEYING OPERATION : An operation utilize a key drive device. Example: MERGE: Combining two or more steps of its into one set MAGNETIC TAPE SYMBOL: It shows input / output of data using magnetic tape drive. MAGETIC DISK symbol: It shows input / output of data using magnetic disk drive FLOW LINES : Flow lines indicates the flow of the system logic. SORT SYMBOL : It indicates that data will be put into a new order or sequence CONNECTOR : It is used to connects the separated portions of a flow-chart . 4.2.3 System flowchart mainly consists of following three steps : 1) The source from which input data is prepared and the medium or devices used. 2) The processing steps or sequence of operations involved. 3) The intermediary and final outputs prepared and the medium and devices used for their storage. Advantages of system flowcharts:
75

1) Communication : system flowcharts are a good visual aid for communicating the logic of a system. To all concerned. (the communications the facts of a business problems) 2) Queasier group of relationships: if identified the relationships that exists among the problem which helps in understands and group the logic queasier. 3) Effective analysis : system flowcharts become a model , that can be broken down into subparts or sub systems for study. 4) System flowcharts are well documented. Knowledge belongs to an organization and does not disappear with the departure of analyst. 5) If systems are modified in feature , these flowcharts will brief the system analysis what was originally done. 6) For new system analysts , these flowcharts are serve as a training function in understanding the exiting system. 7) Efficient system maintenance: these flowcharts are helps in on maintaining the system more efficiently. Examples : system flowchart for pay roll system :

4.3 Decision Tables Decision tables: is a tabular method for describing the logic of the decisions to be taken. Decision table which any accompany with a flowcharts, defining the possible contingencies that may be considered within the program and the appropriate course of action for each contingency. Decision tables can be divided into four parts as shown below:

76

1) Condition stub : consisting a list of all the conditions that are to be taken account. 2) Condition entries : entries that complete the condition statements. They are a tabular representation of the combination of the conditions that are to be satisfied , for each of particular action , that is given a Y or N or ___ mark is placed to indicate weather a particular condition is to be considered or not or to be ignored. 3) Action stub : it consist a list of all the possible actions that are to be taken. 4) Action entries : entries that complete the action statements. They indicates the appropriate actions that are to be taken, when a condition is satisfied. A X marks in placed to indicate which action is to be expected. 4.3.1 Formation of decision table : Table Name :

4.3.2 Advantages of Decision Table Alternatives are shown side- by side to facilitate analysis of combinations. The table shows cause and effect relationships. They are of standardized format Summarize all the outcomes of a situations and suggest the suitable actions. Complex tables can easily be split into simpler tables. The drawing of flow charts is greatly facilitated by use of decision tables.

77

 Decision tables are better documentation for users, tabular representation may be more compact and easy to understand. 4.3.3 Drawbacks of Decision Tables It do not depict the flow of logic of a problem solution. Decision tables are quite far away from programming high level languages If there is a large number of alternatives, it may be impractical to list them all in a decision tables 4.4 Types of Decision Tables There are three types of decision tables i) Limited Entry decision table ii) Extended Entry decision table iii) Mixed Entry decision table 4.4.1 Limited Entry decision table In this table the conditions and actions statements are complete. The conditions and action entries merely define whether or not a not a conditions exist (indicated by Y,N or -) or an action should be taken. The symbols used in the condition entries: Symbol Y N - or blank Meaning Yes , the condition exists . No, the condition not exists. Irrelevant, I.e the condition does not apply to it makes no difference weather the condition exists or not.

The symbols used in action entries are : Symbol X - or blank Meaning Execute the operation specified by the action statement. Do not execute.

Example: draw decision table for following problem. Allow the discount depending on order value as follows;
78

i) Is order value is between Rs 0 Rs 25,000 approve the order. ii) Is order value above Rs 25,000 and is customers credit limit satisfactory ? approve the order and allow 5% discount. Other wise refer to manager. iii) Irrespective of order value is customers credit limit satisfactory ? allow 10% discount. Solution : Example of limited entry table : Rules 1 Y X

Conditions Is order value between Rs 0 25,000 ? Is order value above Rs 25,000 ? Is customer credit limit satisfaction ? Actions Approve order Allow discount 5% Allow discount 10% Refer to manager 4.4.2 Extended entry decision table

2 N Y Y X X

3 N Y N

4 N N Y X X

5 N N N

The condition and the action statements in an extended entry table are not complete, but are completed by the condition and action entries (statement made in the stub positions are in completed). Example of an extended entry table Rules 1 25,000 Cash 15% 5%

Conditions Order value more then Payment made is Actions Allowed trade discount Allow the cash discount

2 3 4 5 25,000 10,000 10,000 0 Credit Cash 15% 10% 3%

6 0

Credit Cash Credit 10% 5% 2% 5% -

4.4.3 Mixed entry decision table

79

In this condition of both the limited and extended entry forms, while the limited and extended entry forms can be mixed within a condition statement / entry or an action statement entry. Example : mixed entry decision table condition for granting exam permission on the basis of attendance and fees paid.

Example : Develop a decision table to select the largest of three distinct number A,B, and C. Solution :Step 1: (i) conditions involved Actions 1) A>B A is largest 2) A>C B is largest 3) B>A C is largest 4) B>C 5) C>A 6) C>B Step2 : Conditions (1) and (3) can be combined Conditions (2) and (5) can be combined Conditions (4) and (6) can be combined Therefore there are only three conditions ; 1) A>B 2) A>C 3) B>C
80

Step3 : Number of rules = 2 n N is number of conditions Therefore 2 3 = 8 . Select the largest of three Rules numbers 1 2 A>B Y A>C Y B>C Y Actions A is largest X B is largest C is largest

3 Y Y N X

4 X N Y

5 Y N N

6 N Y Y

7 N Y N

8 N N Y

N N N

X X

X X

Note : Rule (3) and (5) contain impossible combination of condition entries. Using dash rule : Select the largest of three number 1 A>B A>C B>C Actions A is largest B is largest C is largest

2 Y Y X

3 Y N -

4 N Y

N N

X X X

Example : Prepare a decision table for the following case ; A wholesaler has three commodities to sell and has three types of customers. Discount is given as per the following procedure : (a) for DGS and D orders, 10% discount is given irrespective of the value of the order . (b) for orders more then Rs 50.000 agent gets a discount of 10%. (c) For orders of Rs 20,000 or more and upto Rs 50,000 agent gets 12% and gets 8% discount.

81

(d) For orders of the value less than Rs 20,000 agent gets 8% and retailer gets 5% discount. The above rules do not apply to the furniture items wherein a flat rate of 10% discount is admissible to all customers irrespective of the order. Decision table [limited entry]

4.5 Decision Trees Which are graphical representation of decision table, are also available and aid in the construction of decision tables. A decision tree helps to show the paths that are possible in a decision following an action or decision by the user. Decision tree helps prefer the easier to follow mapping of a complex design. This mapping should show branch point forks, but not the details of the user dialogue .

Decision trees helps the designer visualize how the user will move through the design to reach a desired location. Thus a decision tree provides an aver-view of the flow of control to be built into computer programs. 4.6 Data Flow Diagrams What is DFD?
82

Graphical description of a systems data and how the processes transform the data is known as Data Flow diagram (or DFD). Unlike detail flowcharts, DFDs do not supply detailed descriptions of modules but graphically describe a systems data and how the data interact with the system. To construct data flow diagrams, we use: (i) arrows, (ii) circles, (iii) open-ended boxes, and (iv) squares An arrow identifies data flow -data in motion. It is a pipeline through which information flows. Like the rectangle in flowcharts, circles stand for a process that converts data/into information. An open-ended box represents a data/store-data at rest, or a temporary repository of data. A square defines a source (originator) or destination of system data. The following seven rules govern construction of data flow diagrams (DFD): 1. Arrows should not cross each other. 2. Squares, circles, and rules must bear names. 3. Decomposed data flows must be balanced (all data flows on the decomposed diagram must (reflect flows in the original diagram). 4. No two data flows, squares, or circles can have the same name. 5. Draw all data flows around the outside of the diagram. 6. Choose meaningful names for data flows; processes, and data stores. Use strong verbs followed by nouns. 7. Control information such as record counts, passwords, and validation requirements are not pertinent to a data-flow diagram. If too many events seem to be occurring at a given point, an analyst can decompose a data conversion (circle). The new data conversions form a parent-child relationship with the original data conversion: the child circle in belongs to the parent in Figure.

83

Devotees of data-flow diagrams insist that no other analysts tool expresses so fully the flow of data. After all, dont computer people begin with data flow rather than the processing of the data? Another strong advantage is the balancing feature that builds in an error-detection system other tools lack. For example, if a parent data-flow diagram shows three inputs and two outputs, the leveled child diagrams taken together must have three inputs and two outputs. If there is an imbalance between parent and child data-flow diagrams, an error exists in either the parent or child diagram.

4.6.1 Charting tools used for DFDs

84

The data flow diagram(DFD) is the core specification in this method. Following Figure shows the very few charting forms that are necessary. 4.6.2 Data Flow Diagram Charting Forms Shown in above Figure (a) as a square box is the external source or receiver of data. Shown in above Figure (b) is the transform bubble. Two variations of this have been put forth. The circle or real bubble is the better-known and is used by both Victor Weinberg and Tom De-Marco. The rectangular bubble shown beneath the circle is the form used by Chris Gane and Trish Sarson. The reason for the rectangular bubble is the perceived need to enter more information than can be contained in the bubble. Tom DeMarco, who is the purist in this group of four writers and educators in the structured method, holds that the data content of the bubble must be just the bare bones of one verb and a noun, since our objective is not to explain the process but to partition into leveled transforms. In fact the rectangular bubble is hard to draw freehand and the template containing this special form is not one you are likely to have around the shop, it must be specially ordered. The line arrow is much more important in this method because it carries the data flow: the data into the transform and the data out of the transform. All lines must be identified by their data. In above Figure (c) shows the line arrows. The variations on the use of the line arrow are significant, because again the answer needs that different proponents of this method have perceived. Three different points of view are advanced by the practitioners mentioned above regarding line arrows. 1. When multiple lines go into or leave a transform, Weinberg offers the ability to use Boolean logic describing symbols to represent AND, INCLUSIVE OR, and EXCLUSIVE OR. This clearly indicates a felt need for decision logic above the base level. DeMarco advises against using Boolean decision logic. Our examples will not use Boolean logic beyond showing examples in above Figure (e), since this seems to the author to represent a consensus view of those who use the DFD approach. 2. DeMarco shows the line arrow as a curved line giving a different "feeling" than the straight lines and right angles of Weinberg and Gane-Sarson. In the DeMarco approach there is more. 3. Regarding the data flow along the line arrow, this would be a serious problem, like the problem of expressing the process within the confines of the bubble. The answer here is to take advantage of the fact that the method allows multiple lines in and out of a bubble and to break up the wordy data flow into several briefly named data flows. It is either that or lengthen the line.
85

This concentration on detail of form," worrying about whether to use a circle or a square or a curved or straight line, may read as petty to the nonchartist. To those who mean to use this method to specify systems it is just as serious a matter as the concern of the professional tennis player with the type of racket to be used in a tournament. What we are trying to do with these forms is to invent solutions to r problems as we move from the fluid to the concrete and from the tentative to the certain. We need a method for all seasons, but especially to communicate the fluid and the tentative new idea. The final diagramming element shown in above Figure (d) is the open rectangle or two parallel lines, which indicates the data store (such as a database, file, Kardex or phone book). Gane and Sarson, unlike the others, show the data store as the two parallel lines joined at one side to make an open rectangle. These are all the charting forms we need to use this methodology. Again, as in the flowcharting forms much can be developed out of a few tools. Essentially a system of any complexity whatever is shown with the bubble, line, data store rectangle, and external box. It can re seen that although some practitioners prefer to use variation in their notation, the broad style is similar. 4.7 Data Dictionaries Why Data Dictionary? A data dictionary defines each term (called data element) encountered during the analysis and design of a new system. Data elements can describe files, data flows, or processes. For example, suppose you want to print the vendors name and address at the bottom of a cheque. The data dictionary might define vendors name and address as follows: Vendor name and address = Vendor name + Street + City + State + Pin+ Phone + Fax+ e-mail

86

This definition becomes a part of the data dictionary that ultimately will list all key terms used to describe various data flows and files. 4.7.1 Major Symbols A data dictionary uses the following major symbols: (i) = Equivalent to (ii) + And (iii) [ ] Either/or (iv) ( ) Optional entry 4.7.2 Four Rules Four rules govern the construction of data dictionary entries: 1. Words should re defined to stand for what they mean and not the variable names by which they may re described in the program; use CLIENT_NAME not ABCPQ or 2. Each word must be unique; we cannot have two definitions of the same client name. 3. Aliases, or synonyms, are allowed when two or more entries show the same meaning; a vendor number may also be called a customer number. However, aliases should be used only when absolutely necessary. 4. Self-defining words should not be decomposed. We can even decompose a dictionary definition. For instance, we might write Vendor name = Company name, Individuals name which we might further decompose to: Company name = (Contact) + Business name Individuals name = Last name + First name

87

+ (Middle initial) After defining a term, say VENDOR NUMBER, we list any aliases or synonyms, describe the term verbally, specify its length arid data type, and list the data stores where the term is found (figure 4.4). Some terms/may have no aliases, may be found in many riles, or may be limited to specific values. Some self -defining or obvious words and terms may not require inclusion in the data dictionary. For example, we all know what a PIN code and a middle initial are. Data dictionaries seldom include information such as the number of records in file, the frequency a process will run, or security factors such as passwords users must enter to gain access to sensitive data. Rather, data dictionaries offer definitions of words and terms relevant to a system, not statistical facts about the system. Data dictionaries allow analysts to define precisely what they mean by a particular file, data flow, or process. Some commercial software packages, usually called Data Dictionary Systems (or DDS), help analysts maintain their dictionaries with the help of the computer. These systems keep track of each term, its definition, which systems or programs use the term, aliases, the number of times a particular term is used and the size of the term can be tied to commercial data managers.

Following Figure illustrates the different types of data dictionaries and the functions of each addresses.

Data-Dictionary Types and Functions There are two kinds of data dictionaries:
88

(i) integrated and (ii) stand-alone. The integrated dictionary is related to one database management system. To the extent the organisation data is under this DBMS it is global or organisation wide. However, very few enterprises have all their data eggs in one basket, so the dictionary documentation (metadata) can be considered as local and fragmented The stand-alone dictionary is not tied to anyone DBMS, although it may have special advantages for one DBMS, such as the IBM DB-DC Data Dictionary, which has special features related to the IBM IMS DBMS but is still a stand-alone variety of dictionary. 4.7.3 Data Dictionary functions Both these types of dictionaries can be identified by functions as either passive, active, or inline. Viewed either way, by type or function, the differences are striking. Passive, active, and inline dictionaries differ functionally as follows: 4.7.4 Passive Data Dictionaries The functionally passive dictionary performs documentation only. This variety of dictionary could be maintained as a manual rather than an automated database. For more than limited documentation use, the automated passive dictionary has clear advantages. From the organisational view the documentation function is the most important dictionary service with the most potential benefits, so the passive dictionary should not be thought of negatively. It has more limited functionality but may perform its critical function of global documentation best of all. 4.7.5 Active Data Dictionaries Besides supporting documentation to one degree or another, the active data dictionary sup- ports program and operations development by exporting database definitions and program data storage definitions for languages such as COBOL and Job Control Language (JCL) for execution performance. The IBM DB/DC Data Dictionary already mentioned is such a stand-alone, active data dictionary. A dictionary such as this is not an in-line data dictionary as delivered, which is not to say that it could not be put in-line by a determined effort of major proporations. 4.7.6 In-line Data Dictionaries An in-line data dictionary is active during program execution, performing such feats as transaction validation and editing. Such a dictionary would always have some documentation value, but documentation across the organisation about the organisation functions and activities and all the organisation information data stores is not likely. In-line dictionaries associated with DBMS products such as Cullinet Software Corporations IDMS-R or Cin-com Systems TOTAL, to name just two.

89

4.8 HIPO HIPO stands for Hierarchy plus Input Process Output. It consists of two types of diagrams: (i) Visual Table Of Contents (VTOC) (ii) Input Process Output (IPO) Following the structured approach that begins with generalities and descends to details, VTOC diagrams break a system or program down into increasingly detailed levels. There- fore, the name of the system appears at the top of the VTOC, the names of the major functions within the system lie on the second level and even smaller subfunctions lie on the third and succeeding levels. When used to diagram a program, the VTOC arranges the program modules in order of priority, and it reads from the top down and from left to right Each module of the program appears as a rectangle which contains a brief description of the modules purpose (two to four words, beginning with a verb followed by an object i.e. "compute net pay"). The VTOC for the correct assembly of a bicycle might include five major tasks: (i) open the carton, (ii) remove the parts (that is separate them), (iii) group similar parts, (iv) assemble the wheels (v) finish assembling the bicycle (figure shown below )

VTOC for the modules to assembly a bicyle. 4.9 Warnier-ORR Diagrams Warnier-Orr diagrams are another tool aimed at producing working and correct programs; The Warnier-Orr diagram takes its name from its codevelopers. Jean-Dominique Warnier and Kenneth Orr. Unlike VTOCs, pseudocode, or flowcharts, which read from the top down and then
90

from left to right, the Warnier-Orr diagram reads from left to right, then from the top to down. Whereas a flowchart requires many symbols, Warnier-Orr diagrams employ brackets, circles, parentheses, dots and bars. Diagrams can depict data-dictionary-type definitions or detailed program logic. The Warnier-Orr uses brackets to group related elements following the sequence control structure. Technically the symbol for a bracket is "[" and a brace is "{" but Warnier-Orr calls "{" a bracket Thus we see that three elements in Figure make up the single element "Systems Process". Two elements, preliminary and detailed, make up Analysis. Iteration structure (called repetition in the Warnier-Orr notation) is depicted by a parenthesis to the left of the series of elements to be repeated (Figure). A. Number inside the parentheses indicates the amount of times the iteration should be performed. This we will repeat the four bracketed elements until there are no more bicycles to assemble.

(c) Warnier-Orr diagram for the accounts payable stub-over-cheque module. This diagram shows the three control structures or sequence selection, and repetition

A plus sign enclosed in a circle indicates an alternation or selection structure. A bar separates the decision into true.

91

For our AP cheque-printing logic, the Warnier-Orr diagram has brackets surrounding the repetitive operations and a decision point inside the process section to determine whether a discount will be taken. This diagram also has beginning and ending logic that our bicycle example does not require. Warnier-Orr diagrams show the beginning processing, and ending parts of the detailed logic quite explicitly. In keeping with the structured methodology, they have a single entry and a single exit, they support the three control structures, and compared with other tools, they employ few symbols. Disadvantages of the Warnier-Orr system include its left-to-right, top-down construction (the opposite of all other tools which are topdown; left to right) and its focus on processing versus data flow. Introduced by Warnier and later modified by Orr. Warnier-Orr diagrams are thus used to decompose and partition the contents of a data store. much like DFDs are used to decompose functions of a system. The following example illustrates how a Warnier-Orr diagram would be drawn for the employee master file. As before the employee master file is defined as a set of employee records, thus leading the equation: Example: Employee_ master_ file = 1 {employee_ records ) n However, the Warnier-Orr diagram tells us how to define an employee record. We can write (as before): Employee_ record = Employee number+ employee_name_and_ address + personnel_ information + wage_ and_ salary _information + leave_ and_ pension _history + current-payroll_ history Let us suppose next that we want to know which attributes make up the category employee name and address. The Warnier-Orr diagram informs us that Employee_name_and_address = Employee_ name + employee_ home_ address + employee_ plant_ address +telephone_ extension_ number
92

Warnier-Orr Diagram Showing Decomposition of the Employee Record

If we wanted to know which attributes make up employee home address, further decomposition would be necessary. The Warnier-Orr diagram tells us that Employee_ home_ address = ({PO_ box_/apartment_ number}) + street_ address + city _address+ state_ address + Pin_ code where the post office box or the apartment number is optional. A unique feature of Warnier-Orr diagrams is that they show sequences, either or conditions, and repetitions of a process. As illustrated by Figure 4.30 most Warnier-Orr diagram statements imply a sequential order. For example: Employee- name_ and_ address is equal to the employee_ name plus the employee- home_ address. plus the employee_ plant_ address, plus the telephone_ extension_ number. Finally, repetition of a process is indicated. Current_ Payroll_ history is shown as a variable for each employee. The Warnier_orr diagram continues to be pushed to the right until all right-hand attributes can be defined by their field length, or physical storagerequirements. City address might be defined as City _address = 2 { character } 12 or as requiring from two to twelve characters. Telephone extension might be defined as Telephone_ extension = 4 digits, where an extension always consists of a four-digit number. As this example suggests, there are several good reasons for using Warnier-Orr diagrams to describe the contents of data stores. First Warnier-Orr diagrams are easy to construct, read and interpret. Second, they permit larger, complex terms to be decomposed into constituent parts. Third, Warnier-Orr diagrams describe the three logical constructs used in programming. Fourth, they can be used to analyse both actions and things. Fifth, they simplify the definition and order
93

of terms to be entered into the data dictionary. The main disadvantage of a Warnier_Orr diagram is that it does not show relationships which exist within and between data stores. 4.10 Nassi-Shneidermann Charts Nassi- Shneidermann (N-S) charts offer an alternative to either pseudocode or program flowcharts. Named after their authors, N-S charts are much more compact than program flow-charts, include pseudocode-like statements, and feature sequence, decision and repetition constructs. Following Figure illustrates an N-S chart designed for processing payroll cheques. Nassi- Shneidermann Chart

Nassi-Shneidermann charts are also sometimes called the Chapin charts. This system was developed by and named for I. Nassi and B. Shneidennann in the early 1970s and differs markedly from those we have examined thus far. It uses rectangles divided into halves with an angular line for selection, a horizontal rectangle for sequence, and the word DOWHILE for iteration. The bicycle-assembly chart appears in following Figure, and the AP check-printing system with discounting in. Nassi-Shneidermann charts are winning wider acceptance in the computer industry because they so simply illustrate complex logic. Perhaps as analyst, evaluate the various tools at their disposal, these charts will gain even more followers. As with other structured tools, they are single entry and single exit, and efficiently accommodate modules. However, the } are not as useful for conveying system flow as they are for detailing logic development and they are difficult to maintain. Nassi-Shneidermann chart for bicycle assembly

94

Nassi-Shneidermann chart for AP cheque-printing logic

Exercise: 1. Define System flow-chart with its symbols. 2. Explain the three steps involved in the system flow-chart. 3. Define decision table? Explain the parts of Decision table. 4. Write the Advantages and Drawbacks of Decision table. 5. Explain the types of Decision table with example of each. 6. Define Decision tree. 7. What is DFD ? Discuss the DFD charting forms. 8. Define Data Dictionary. Discuss the four rules to govern the construction of DD. 9. Write short note on: a) HIPO b) Warnier-ORR Diagram
95

c) NS Chart Copyright 2011 SMU Powered by Sikkim Manipal University

.

96