Sad- Basic Notes 5v102p

SYSTEM ANALYSIS AND DESIGN The Systems Concepts Scholars in various disciplines who are concerned about the tendency toward the tragmentation of knowledge and the increasing complexity of phenomena have sought a unifying approach to knowledge. Luduring von Bertalanlfy, a biologist, developed a general systems thereby that applied to any arrangement of elements such as cells, people, societies or even planets. Norbert Wiener, a mathematician observed that information and communications provides connecting links for unifying fragments or elements, His systems concept of information theory, which shows the parallel between the functioning of human beings and electronic systems, laid the foundation for today’s computer systems. Herbert A. Simon, a political scientist, related the systems concept to the study of organizations by viewing an ongoing system as a processor of information for making decisions. Systems analysis and information systems were founded in general systems theory, which emphasizes a close look at all parts of a system. Too often analysts focus on only one component and over look other equally important component. General systems theory is concerned with “developing a systematic, the oretieal framework upon which to make decisions’. It discourages thinking in a vacuum and encourages consideration of all the activities of the organization and its external environment. Pionerring work in general systems theory emphasized that organizations be viewed as total systems. The idea of systems has become most practical and necessary in conceptualizing the interrelationships and integration of operations, especially when using computers. Thus a system is a way of thinking about organizations and their problems. It also involves a set of techniques that helps in solving problems.

Definition of a System The term system is derived from the Greek word systema, which means an organized relationship among functioning units or components. A system exists because it is designed to achieve one or more objectives. We come into daily with the transportation system, the telephone system etc. Similarly we talk of the business system and of the organization as a system consisting of interrelated departments such as production, sales, personnel. There are more than a hundred definitions of the word system but most seem to have a common thread that suggests that a system is an orderly grouping of interdependent components linked together according to a plan to achieve a specific objective. The word component may refer to physical parts or a subsystem in a multilevel structure. The components may be simple or complex, basic or advanced. They may be a single computer with a keyboard, memory and printer or a series of intelligent terminals linked to a mainframe. In either case each component is part of the total system and has to do its share to work for the system to achieve the intended goal. This orientation requires an orderly grouping of the components for design for a successful system. The study of systems concept, has three basic implications: 1. A system must be designed to achieve a predetermined objective.

2. Interrelationship and interdependence must exist among the components. 3. The objectives of the organization as a whole have higher priority that the objectives of its subsystems.

Characteristics of a System Our definition of a system suggests some characteristics that are present in all systems: organization, interaction, inter dependences, interaction and a central objective.

Organization Organization implies structure and order. It is the arrangement of components that helps to achieve objectives. In the design of a business system, for example, the hierarchical relationship starting with president on top and leading downward to the blue-collar workers represents the organization structure. Such an arrangement portrays a system subsystem relationship, defines the authority structure, specifies the formal flow of communication and formalizes the chain of command (see figure 1.1). Likewise a computer system is designed around an input device, a central processing unit, and output device and one or more storage units.

Interaction Interaction refers to the manner in which each component functions with other components of the system. In an organization, for example, purchasing must interact with production, advertising with sales, and payroll with personnel. In a computer system the central processing unit must intract with input device to solve a problem. In turn, the main memory holds programs and data that the arithmetic unit uses for computation. The interrelationship between these components enables the computer to perform.

Interdependence Interdependence means that parts of the organization or computer system depend on one another. They are coordinated and linked together according to a plan. Our subsystem depends on the input of another subsystem for proper functioning i.e. the Formal organization position

President

Vice president sales

Vice president production

Vice president ing

Dept. head assembly

Dept. head painting

Workers

Workers

Lines of Authority

output of one subsystem is the required input for another subsystem. This interdependence is crucial in systems work. Figure 1.1: Organisation Structure

Production Research & Development. Marketing Major Higher-level subsystem Purchasing

Financing & istration

Personnel

Distribution system

Intermediate (Middle-level subsystem

Employme nt section

Benefits & Figure 1.2: Major subsystems of Production Firm services section

Unemployme nt reports

Labourlevels To illustrate these system characteristics, figure 1.2 shows three of distribution Labour reports section and subsystems. Each of the topHealth inner circles represent a major subsystem of a safety Voluntary section production firm. The personnel subsystem, in turn, may be viewed as a system that deduction reports Fringe benefits consists of subsystemsTraining such as a benefits and safety, and employment. Health and section reports safety as a key personnel subsystem consists of lower level Insuranceelements that are benefits reports considered vital in personnel operation.

Input data and Control

Payroll

Computer programs Budget

Remote terminals for data acquisition

Data base Skills inventory job positions, recruitment, personnel budget, benefits, health, employment record.

Operatio n

Finance

Feedbac k and control

Action report

s

Demograph ic data Other s

authorized

Personnel staff

Figure 1.3: A Human Resources Information System

Above figure is an integrated information system designed to serve the needs of authorized s for quick access and retrieval through remote terminals. The interdependence between the personnel subsystem and the organization’s s is obvious. In summary, no subsystem can function in isolation because it is dependent on the data it receives from other sub systems to perform its required tasks. Interdependence is further illustrated by activities and of systems analysts, programmers and the operations staff in a computer center. A decision to computerize an application is initiated by the , analyzed and designed by the analyst, programmed and tested by the programmer and run by the computer operator. As shown in figure below, none of these persons can perform properly without the required input from others in the computer based subsystem.

Systems Analysis

area

Programming

Operations

Figure 1.4: Task Interdependence in a Computer-Based System

Integration Integration refers to the holism of systems. Synthesis follows analysis to achieve the central objective of the organization. Integration is concerned with how a system is tied together. It is more than sharing a physical part or location. It means that parts of the system work together within the system even though each part performs a unique function.

Central Objective The last characteristics of a system is its central objective. Objective may be real or stated. Although a stated objective may be the real objective, it is not uncommon for an organization to state one objective and operate to achieve another. The important point is that s must known the central objective of a computer application early in the analysis for a successful design and conversion.

Elements of a System 1. Output and Inputs 2. Processor(s) 3. Control 4. 5. Environment 6. Boundaries and Interface

Outputs and Inputs

A major objective of a system is to produce an output that has value to its . Whatever the nature of the output, it must be within the line with the explanations of the intended . Inputs are the elements that enter the system for processing. Output is the outcome of processing. A system feeds on input to produce output in much the same way that a business brings in human financial, and material resources to produce goods and services. It is important to point out here that determining the output is a first step in specifying the nature, amount and regularity of the input needed to operate a system. For example in systems analysis, the first concern is to determine the ’s requirements of a proposed commuter system – that is specification of the output that the computer is expected to provide for meeting requirements. Input and processing design follow:

Compare output against performance standards

Action

Management (Control)

Informational

Policy decision Human resources, material, energy, information

Input

Transformation

Goods of services

Processing

Standard of performance Output

Figure 1.5: Inputs and Outputs in a Business Operation

Processor(s) The processor is the element of a system that involves the actual transformation of input into output. It is the operational component of the system. Processor may modify the input totally or personally, depending on the specifications of the output. This means that as the output specifications change so does the processing. In some cases, input is also modified to enable the processor to handle the transformation.

Control The control element guides the system. It is the decision – making sub-system that controls the pattern of activities governing input, processing and output. In an organizational context, management as a decision making body controls the inflow

handling and outflow of activities that affects the welfare of the business. Output specification determine, what and how much input is needed to keep the system in balance. In system analysis, knowing the attitudes of the individuals who control the area for which a computer is being considered can make a difference between the success and the failure of the installation. Management is required for securing control and ing the objective of the proposed change.

Control in a dynamic system is achieved by . measures output against standard in some form. After the output is compared against performance standards, changes can result in the input or processing and consequently, the output. may be positive or negative, routine or informational. Positive reinforces the performance provides the controller with information for action. In system analysis, is important in different ways. During analysis, the may specify that the problems in a given application, and justify the need for change. Another form of comes after the system is implemented. The informs the analyst about the performance of the new installation. This often results in enhancements to meet the ’s requirements.

Environment The environment is the “suprasystem” within which an organization operates. It is the source of external elements that unhinge on the system. In fact, it often determines how a system must function. The organization’s environment, consisting of vendors, competitions and others, may provide constraints and consequently influence the actual performance of the business.

Boundaries and Interface A system should be defined by its boundaries – the limits that identify its components, processes and interrelationships and interfaces with another system. For example, a teller system in a commercial bank is restricted to the deposits, withdrawals and related activities of customers checking and savings s. It may exclude mortgage foreclosures, trust activities and the like. Each system has boundaries that determine its sphere of influence and control. Although in an integrated banking computer system design, a customer who has a mortgage and a checking with the same bank may write a check through the “teller system” to pay the that is latter processed by the “mortgage loan system”. Recently system design has been successful in allowing the automatic transfer of funds from the bank to pay bills and other obligations to creditors, regardless of distance or location. This means that in systems analysis, knowledge of the boundaries of given system is crucial in determining the nature of its interface with other system for successful design.

Types of Systems Systems have been classified in different ways. Common classifications are:

(i)

Physical or abstract systems

(ii)

Open or closed systems

(iii)

Deterministic or probabilistic systems

(iv)

Man-made information systems

(i)

Physical or Abstract Systems: Physical systems are tangible entities that may be static or dynamic in operation. Abstract systems are conceptual or nonphysical entities which may be as straightforward as formulas of relationships among sets of variables or models - the abstract conceptualization of physical situations.

(ii)

Open or Closed Systems: An open system continually interacts with its environments. It receives inputs from and delivers output to the outside. An information system belongs to this category, since it must adapt to the changing demands of the . In contrast, a closed system is isolated from environmental influences. In reality completely closed systems are rare.

(iii)

Deterministic or Probabilistic Systems: A deterministic system is one in which the occurrence of all events is perfectly predictable. If we get the description of the system state at a particular time, the next state can be easily predicted. An example of such a system is a numerically controlled machine tool. Probabilistic system is one in which the occurrence of events cannot be perfectly predicted. An example of such a system is a warehouse and its contents.

(iv)

Man-made Information Systems: It is generally believed that information reduces uncertainty about a state or event. For example, information that the wind is calm reduces the uncertainty that a trip by boat will be enjoyable. An information system is the basis for interaction between the and the analyst. It determines the nature of relationship among decision makers. In fact, it may be viewed as a decision centre for personnel at all levels. From this basis, an information system may be defined as a set of devices, procedures and operating systems designed around -based criteria to produce information and communicate it to the for planning, control and performance. Many practitioners fail to recognise that a business has several information systems; each is designed for a specific purpose. The major information systems are: 

formal information systems



informal information systems



computer based information system

A Formal information system is based on the organisation represented by the organization chart. The chart is a map of positions and their authority relationships, indicated by boxes and connected by straight lines. It is concerned with the pattern of authority, communication and work flow. An Informal information system is an employee-based system designed to meet personnel and vocational needs and to help in the solution of work-related problems. It also funnels information upward through indirect channels. In this way, it is

considered to be a useful system because it works within the framework of the business and its stated policies. Third category of information system depends mainly on the computer for handling business applications. Systems analysts develop several different types of information systems to meet a variety of business needs. There is a class of systems known collectively as Computer Based Information Systems. As we have different types of transportation systems such as highway systems, railway systems and airline systems, computer based information systems are of too many types. They are classified as: 

Transaction Processing Systems (TPS)



Management Information Systems (MIS)



Decision Systems (DSS)



Office Automation Systems (OAS).

The next figure shows the organisation chart of computer based information system (CBIS) and figure shows the hierarchical view of CBIS.

Figure 1.6: CBIS in an Organisation Context

Figure 1.7: Hierarchical View of CBIS

Transaction Processing Systems

The most fundamental computer based system in an organisation pertains to the processing of business transactions. A transaction processing system can be defined as a computer based system that captures, classifies, stores, maintains, updates and retrieves transaction data for record keeping and for input to other types of CBIS. Transaction Processing Systems are aimed at improving the routine business activities on which all organizations depend. A transaction is any event or activity that affects the whole organisation. Placing orders, billing customers, hiring of employees and depositing cheques are some of the common transactions. The types of transactions that occur vary from organisation to organisation. But this is true that all organisations process transactions as a major part of their daily business activities. The most successful organisations perform this work of transaction processing in a very systematic way. Transaction processing systems provide speed and accuracy and can be programmed to follow routines without any variance.

Management Information System Data processing by computers has been extremely effective because of several reasons. The main reason being that huge amount of data relating to s and other transactions can be processed very quickly. Earlier most of the computer applications were concerned with record keeping and the automation of routine clerical processes. However, in recent years, increasing attention has been focussed on computer applications providing information for policy making, management planning and control purposes. MIS are more concerned with management function. MIS can be described as information system that can provide all levels of management with information essential to the running of smooth business. This information must be as relevant, timely, accurate, complete and concise and economically feasible

Decision Systems It is an information system that offers the kind of information that may not be predictable, the kind that business professionals may need only once. These systems do not produce regularly scheduled management reports. Instead, they are designed to respond to a wide range of requests. It is true that all the decisions in an organisation are not of a recurring nature. Decision systems assist managers who must make decisions that are not highly structured, often called unstructured or semi-structured decisions. A decision is considered unstructured if there are no clear procedures for making the decision and if not all the factors to be considered in the decision can be readily identified in advance. Judgement of the manager plays a vital role in decision making where the problem is not structured. The decision system s, but does not replace, judgement of manager.

Office Automation Systems Office automation systems are among the newest and most rapidly expanding computer based information systems. They are being developed with the hopes and expectations that they will increase the efficiency and productivity of office workerstypists, secretaries, istrative assistants, staff professionals, managers and the like. Many organisations have taken the First step toward automating their offices. Often this step involves the use of word processing equipment to facilitate the typing,

storing, revising and printing of textual materials. Another development is a computer based communications system such as electronic mail which allows people to communicate in an electronic mode through computer terminals. An office automation system can be described as a multi-function, integrated computer based system that allows many office activities to be performed in an electronic mode. Categories of different information systems with their characteristics have been described briefly in table below. Categories of Information Systems Category of Information System

Characteristics

Transaction Processing System

Substitutes computer-based processing for manual processes. Includes record-keeping applications.

Management Information System

Provides input to be used in the managerial decision process. Deals with ing well structured decision situations. Typical information requirements can be anticipated

Decision System

Provides information to managers who make judgements about particular situations. s decision makes in situations that are not well structured.

Office Automation System

It is a multi-function, integrated computer based system, that allows many office activities to be performed in an electronic mode.

System Development Life Cycle To understand system development, we need to recognize that a candidate system has a life cycle, much like a living system or a new product. Systems analysis and design are based to the system life cycle. The stages are described below. The analyst must progress from one stage to another methodically, answering key questions and achieving results in each stage. A word of caution regarding life cycle activities. We isolate and sequence these activities for learning purposes, but in real life they overlap and highly interrelated, for example, when the analyst is evaluating an existing operation he/she is probably thinking about an alternative way that would improve the system or wondering whether a given piece of hardware would be a critical cost item to consider for a candidate system. Therefore, there can easily be overlap during any phase of the cycle. In fact, it may act as a basis for modifying earlier steps taken. We now describe each of these steps.

Recognition of Need – What is the Problem? One must know what the problem is before it can be solved. The basis for a candidate system is recognition of a need for improving an information system or a procedure.

For example, a supervisor may want to investigate the system flow in purchasing. Or a bank president has been getting complaints about the long lines in the drive – in. This need leads to a preliminary survey or an initial investigation to determine whether an alternative system can solve the problem. It entails looking into the duplication of effort bottlenecks, inefficient existing procedures, or whether parts of the existing system would be candidates for computerization. If the problem is serious enough, management may want to have an analyst look at it, such an assignment emplies a commitment, especially if the analyst hired from the outside. In larger environments, where formal procedures are the norm, the analyst’s first task is to prepare a statement specifying the scope and objective of the problem. He/she then reviews it with the for accuracy at this stage, only a rough “ball parle” estimate of the development cost of the project may be reached. However, an accurate cost of the next phase – the feasibility study – can be produced.

Stage 1.

2.

3.

4.

Recognition of need Preliminaryy survey/ Initial investigation Feasibility study Evaluation of existing System and procedures Analysis alternative Candidate system Cost estimates Analysis Detailed evaluation of Present system Data collection Design General design specifications Detailed design specifications Output Input Fiels Procedures System? Program constrcution Testing Unit testing Combined module Testing acceptance Testing

5.

Implementation training File/System conversion Are there delays in lading

Key Question

Result

What is the problem or opportunity?

Statement of scope and Objectives Performance criteria

What are the ’s demonstrabel needs? Is the problem worth solving? How can the problem be Redefined?

Technical/behavioral Feasibility Cost/benefit analysis System scope and objectives Statement of new scope and Objectives

What must be done to solve Logical model of system— the problem? e.g., data dictionary, data What are the facts? flow diagram Pertient data In general, how must the problem be solved? Specifically, how must the problem be solved? What is the system (processing) flow?

Design of alternative solutions Final cost/benefit analysis Hardware specifications Cost estimates Implementation specifications

Does the approve the Implementation schedule Approval of system by Programs

How well do individual programs/modules test out? How ready are programs for acceptance test?

Security, audit, and operating Procedures Actual hardware use Formal system test

What is the actual operation? Training program Are manuals ready? -friendly documentation

Files? 6.

Post-implementation and Maintenance Evaluation Maintenance Enchancements

Is the key system running? Should the system be modified?

requirements met standards met Satisfied

Figure 1.9: System Development Life Cycle

Project Selection The project has to be identified before it can be solved. The basis for an alternative system is the recognition of a need for improving an information system or a procedure. The idea for change originates in the environment or within the firm due to any of the following reasons : speed of processing needed to be improved increased workload to cut down on cost of processing requirement of increased accuracy/reliability of output reports generated security of processing Environment based ideas originate from customers, vendors, government sources etc. e.g., new unemployment compensation regulations may make it necessary to change the reporting procedure, format, and content of various reports, as well as the file structures. Customer complaints about the delivery of orders may prompt an investigation of the delivery schedule, the experience of the truck drivers, or the volume of the orders to be delivered. Ideas for change may also come from within the organisation's top management or from the s. When investigated, each of these ideas may lead to a problem definition which leads to the first step in the system life cycle process. The objective of this phase is to answer the following questions : 1.

What is the problem (or opportunity) perceived ?

2.

What are the goals to be achieved by the solution ?

3.

What are the benefits which will result from achieving the solution ?

These details may be recorded in an informal note or in a formal document. This document would be called the Project Request Form. A request to receive assistance from an information system can be made for many reasons, but in each case someone-a manager, an employee, or a systems specialist - initiates the request. The project proposal submitted by the s to the project selection committee is a critical element while launching a systems study. The form of such a request varies from firm to firm, but there agreement on the kind of information that should be provided.

is a

general

A sample of the project request form is shown below. THE PROJECT REQUEST FORM Job Title Investigation of an on-line safe deposit system.

Nature of Job _____ New _____ Revision

Request Data 27/07/2001

To be completed not later than 12/05/2002

Job Objectives: Provide customer service, reduce paper work, better billing system, and possible reduction in staffing requirements. Expected Benefits 1. Shorten or eliminate customer lines in lobby 2. Provide quick up-to-date information regarding box availability 3. More accurate billing procedure Output Specifications

Input Specifications

Report Title Customer monthly statement Quantity 2-5 No. of pages/report 4 No. of copies/report

Document Title Billing notices Quantity 100-400

Frequency _____ daily ______ weekly

Frequency _____ daily ______ weekly

Remarks: letter quality printing

Remarks: number of notices vary with the season. In January the range may be between 200 – 1,000

Report Title

Document title

Quantity

____ No. of pages/report _____ No. of copies/report Frequency ____ daily ____ weekly Remarks

Quantity

___

Frequency ____ daily ____ weekly

As seen from the above table, the ’s request form specifies the following: 1.

-assigned title of work requested.

2.

Nature of work requested (problem definition).

3.

Date on which the request was submitted.

4.

Date by which the job should be completed.

5.

Job objective(s) - purpose of job requested.

6.

Expected benefits to be derived from the proposed change.

7.

Input/output description-quantity (number of copies or pages) and frequency (daily, weekly, etc.) of inputs and outputs of the proposed change.

8.

Requester's signature, title, department, and phone number.

9.

Signature, title and department of the person(s) approving the request.

Preliminary Investigation of Project Selection When a request to change, improve or enhance an existing system is made, the next systems activity, that is, the preliminary investigation, begins. Because there is a possibility for a stream of requests, standard procedures must be established to deal with them. The 'initial investigation' is one way to handle this. The objective is to determine whether the request is 'valid' and 'feasible' before a recommendation is made to either do nothing, or improve or modify the existing system or build a new one.

Scope of Study The purpose of the preliminary investigation is to evaluate the project requests. It is not a design study. It is collecting the information that permits the committee to Evaluate the merits of the project request Make an informal judgement about the feasibility of the proposed project. The following activities should be accomplished during the preliminary investigation. 1.

Clarify and understand the project request. What is being done? What is required? Why? Is there an underlying reason different from the one the requester identifies? E.g. the justifies a request for developing of an s receivable system based on the requirement of faster processing. However, the preliminary investigation may reveal that the need for better control of cash handling outweighs the need for speed. Lost checks and not speed of processing, are the real problems, but the requester has not described the specific need clearly.

2.

Determine the size of the project. e.g. Does a request for a course-registration project call for new development or for modification of the existing system? The investigation conducted for a solution will also gather the details useful in estimating the amount of time and number of people required to develop the project. Since many enhancements of existing system are costly, they are treated in the same way as a new project by the project selection committee.

3.

Assess costs and benefits of alternative approaches

e.g. What are the estimated costs for developing a patient information system, as requested by the hospital's chief of staff? What expenses will be incurred to train the medical and nursing personnel and install the system ? Will the proposed system reduce the operating costs? Is it likely that the cost of error will decrease? 4.

Determine the technical and operational feasibility of alternative approaches. e.g. Does the necessary technology to link office word processing systems to the main computer exist or can it be acquired ? How workable is the request to enable istrative assistants to retrieve sales information from the main system and insert it directly into type written reports prepared on a word processor ?

5.

Report the findings to the management, with recommendations outlining the acceptance or rejection of the proposal. e.g. A proposal for the installation of an order entry system should be modified to allow all salespersons to submit their orders through ordinary telephone connections directly into the computer. The modifications will improve the usefulness of the system and increase the financial benefits of the organization.

Feasibility Study Depending on the results of the initial investigation, the survey is expanded to a more detailed feasibility study. As we shall learn, a feasibility study is a test of a system proposal according to its workability impact on the organization, ability to meet needs, and effective use of resources. It focuses on there major questions: i.

What are the ’s demonstrable needs and how does a candidate system meet them?

ii.

What resources are available for given candidate systems? Is the problem worth solving?

iii.

What are the likely impact of the candidate system on the organization? How will it fit within the organization’s master MIS plan?

Each of these questions must be answered carefully. They revolve around investigation and evaluation of the problem, identification and description of candidate systems, specification of performance and the cost of each system, and final selection of the best system. The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. During the study, the problem definition is crystallized and aspects of the problem to be included in the system are determined. Consequently, costs and benefits are estimated with greater accuracy at this stage. The result of the feasibility study is a formal proposal. This is simply a report - a formal document detailing the nature and scope of the proposed solution. The proposal summarizes what is known and what is going to be done. It consists of the following.

1.

Statement of the Problem – a carefully worded statement of the problem that led to analysis.

2.

Summary of Findings and Recommendations – a list of the major findings and recommendations of the study. It is ideal for the who required quick access to the results of the analysis of the system under study. Conclusions are stated, followed by a list of the recommendations and a justification for them.

3.

Details of Findings – An outline of the methods and procedures undertaken by the existing system, followed by coverage of objectives & procedures of the candidate system. Included are also discussions of output reports, file structures, and costs and benefits of the candidate system.

4.

Recommendations and Conclusions – special recommendations regarding the candidate system, including the personal assignments costs, project schedules, and target dates.

In the feasibility study offering system design, we have to consider the following:

Feasibility Considerations Three key considerations are involved in the feasibility analysis: economic, technical, behavioural. Let’s briefly review each consideration and how it relates to the systems effort.

Economic Feasibility Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in the proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle.

Technical Feasibility Technical feasibility centers around the existing computer system (hardware, software etc.) and to what extent it can the proposed addition. For example, if the current computer is operating at 80 per cent capacity – an arbitrary ceiling – then running another application could overload the system or require additional hardware. This involves financial considerations to accommodate technical enhancements. If the budget is a serious constraint, then the project is judged not feasible.

Behavioural Feasibility People are inherently resistant to change, and computers have been known to facilitate change. An estimate should be made of how strong a reaction the staff is likely to have towards the development of a computerized system. It is common knowledge that computer installations have something to do with turnover, transfers,

retraining, and changes in employee job status. Therefore, it is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business. After the proposal is viewed by management it becomes a formal agreement that paves the way for actual design and implementation. This is a crucial decision point in the life cycle. Many projects die here, whereas the more promising ones continue through implementation. Changes in the proposal are made in writing, depending on the complexity, size, and cost of the project. It is simply common sense to changes before committing the project to design.

Analysis It is a detailed study of the various operations performed by the system and their relationship within and outside of the system. A key question is – what must be done to solve the problem? One aspect of analysis is defining the boundaries of the system and determining whether or not a candidate system should consider other related systems. During analysis, data are collected on available files, decision points, and transactions handled by the present system. We shall learn about some logical system models and tools that are used in analysis. It requires special skills and sensitivity to the subjects being interviewed. Bias in data collection and interpretation can be problem. Training, experience and common sense are required for collection of the information needed to do the analysis. Once analysis is completed the analyst has a firm understanding of what is to be done. The next step is to decide how the problem might be solved. Thus, in the systems design, we move from the logical to the physical aspects of the life cycle.

Design The most creative and challenging phase of the system life cycle is system design. The term design describes both a final system and a process by which it is developed. It refers to the technical specifications (analogous to the engineer’s blueprints) that will be applied in implementing the candidate system. It also includes the constructions of programs and programme testing. The key question here is – How should the problem be solved? The major steps in design are shown below.

1

Form analysis

Output design Detailed system documentation

Input design

Cost justification and candidate system design Design submitted to management for approval

File design

No

Processing design Output design

Design accepted?

Abandon project

Yes

Test programs

Go to implementation

Go to implementation

Figure 1.10: Steps in System Design

The first step is to determine how the output is to be produced and in what format. Samples of the output (and input) are also available. Second, input data and master files (data base) have to be designed to meet the requirements of the proposed output. The operational (processing) phase are handled through programe construction and testing, including a list of the programmes needed to meet the system’s objectives and complete documentation. Finally, details related to justification of the system and an estimate of the impact of the candidate system on the and the organization are documented and evaluated by management as a step toward implementation. The final report prior to the implementation phase includes procedural flowcharts, record layouts, report layouts, and a workable plan for

implementing the candidate system. Information on personnel, money, hardware, facilities and their estimated cost must also be available. At this point, projected costs must be close to actual costs of implementation. In some firms, separate groups of programmer do the programming whereas other firms employ analyst programmers who do analysis and design as well as code programmes. For this discussion, we assume that analysis and programming is carried out by two separate persons. There are certain functions, though, that the analyst must perform while programes are being written operating procedures and documentation must be completed. Security and auditing procedures must also be developed.

Testing No system design is ever perfect. Communication problems, programmers negligence or time constraints create errors that most be eliminated before the system is ready for acceptance testing. A system is tested for online response, volume of transactions, stress, recovery form failure and usability. Then comes system testing, which verifies that the whole set of programs hangs together, following system testing is acceptance testing or running the system with live data by the actual use. System testing requires a test plan that consists of several key activities and steps for programs, string, system and acceptance testing. The system performance criteria deal with turaround time, backup, file protection, and the human factor.

Implementation This phase is less creative than system design. It is primarily concerned with training, site preparation, and file conversion. When the candidate system is linked to terminals and remote sites the telecommunication network and tests of the network along with the system are also included under implementation. During the final testing, acceptance is tested, followed by training. Depending on the nature of the system, extensive training may be required, conversion usually takes place at about the same time the is being trained or later. In the extreme, the programmer is falsely viewed as someone who ought to be isolated from other aspects of system development. Programming is itself design work, however. The initial parameter of the candidate system should be modified as a result of programming efforts. Programming provides a “reality test” for the assumptions made by the analyst. It is therefore a mistake to exclude programmers from the initial system design. System testing checks the readiness and accuracy of the system to access, update and retrieve data from new files. Once the programmes become available, test data are read into the computer and processed against the file(s) provided for testing. If successful, the programe(s) is then run with “live” data. Otherwise, a diagnostic procedure is used to local and correct errors in the program. In most programes, a parallel run is conducted where the new system runs simultaneously with the ‘old’ systems. This method, though costly, provides added assurance against errors in the candidate system and also gives the -staff an opportunity

to gain experience through operation. In some cases, however, parallel processing is not practical. For example, it is not plausible to run two parallel online point-to-sale (POS) systems for a retail chain. In any case, after the candidate system proves itself, the old system is phased out.

Evaluation During systems testing, the system is used experimentally to ensure that the software does not fail. In other words, we can say that it will run according to its specifications and in the way s expect. Special test data are input for processing, and the results examined. A limited number of s may be allowed to use the system so that analyst can see whether to use it in unforeseen ways. It is desirable to discover any surprises before the organization implements the system and depends on it. Implementation is the process of having systems personnel check out and put new equipment into use, train s, install the new application and construct any files of data needed to use it. This phase is less creative than system design. Depending on the size of the organisation that will be involved in using the application and the risk involved in its use, systems developers may choose to test the operation in only one area of the Firm with only one or two persons. Sometimes, they will run both old and new system in parallel way to compare the results. In still other situations, system developers stop using the old system one day and start using the new one the next. Evaluation of the system is performed to identify its strengths and weaknesses. The actual evaluation can occur along any one of the following dimensions: (i)

Operational Evaluation: Assessment of the manner in which the system functions, impact.

(ii)

Organisational Impact: Identification and measurement of benefits to the organisation in such areas as financial concerns, operational efficiency and competitive impact.

(iii)

Manager Assessment: Evaluation of the attitudes of senior and manager within the organisation, as well as end-s.

(iv)

Development Performance: Evaluation of the development process in accordance with such yardsticks as overall development time and effort, conformance to budgets and standards and other project management criteria.

Maintenance is necessary to eliminate errors in the working system during its working life and to tune the system to any variations in its working environment. Often small system deficiencies are found as a system is brought into operation and changes are made to remove them. System planners must always plan for resource availability to carry out these maintenance functions. The importance of maintenance is to continue to bring the new system to standards.

Post – Implementation and Maintenance

Maintenance is to eliminate errors in the working system during its working life and to tune the system to any variations in its working environment. After the installation phase is completed and the staff is adjusted to changes created by the candidate system, evaluation and maintenance being. Like any system there is an ageing process the requires periodic maintenance of hardware & software. If the new information is inconsistent with the design specifications, then changes have to be made. Hardware also requires periodic maintenance to keep in time with design specification. The importance of maintenance is to continue to bring the new system to standards.

priorities, changes in organizational requirements, or environmental factor also call for system enhancements. To contrast maintenance with enhancement, if a bank decided to increase its service charges for checking s from $ 3.00 to $ 450 for a minimum balance of $ 3,000, it is maintenance. However, if the same bank decided to create a personal loan on negative balances when customers overdraw their , it is enhancement. This change requires evaluation, program modifications, and future testing.

Role of a Systems Analyst

Who is Systems Analyst? A systems analyst is a person who conducts a study, identifies activities and objectives and determines a procedure to achieve the objectives. Deg and implementing systems to suit organisational needs are the functions of the systems analyst He plays a major role in seeing business benefit from computer technology. The analyst is a person with unique skills. He uses these skills to coordinate the efforts of different type of persons in an organisation to achieve business goals.

What a Systems Analyst does? A system analyst carries out the following job: (a)

The First and perhaps most difficult task of systems analyst is problem definition. Business problems are quite difficult to define. It is also true that problems cannot be solved until they are precisely and clearly defined.

(b)

Initially a systems analyst does not know how to solve a specific problem. He must consult with managers, s and other data processing professionals in defining problems and developing solutions. He uses various methods for data gathering to get the correct solution of a problem.

(c)

Having gathered the data relating to a problem, the systems analyst analyses them and thinks of plan to solve it. He may not come up personally with the best way of solving a problem but pulls together

other people's ideas and refines them until a workable solution is achieved. (d)

Systems analysts coordinate the process of developing solutions. Since many problems have number of solutions, the systems analyst must evaluate the merit of such proposed solutions before recommending one to the management

(e)

Systems analysts are often referred to as planners. A key part of the systems analyst's job is to develop a plan to meet the management's objectives.

(f)

When the plan has been accepted, systems analyst is responsible for deg it so that management's goal could be achieved. Systems design is a time consuming, complex and precise task.

(g)

Systems must be thoroughly tested. The systems analyst often coordinates the testing procedures and helps in deciding whether or not the new system is meeting standards established in the planning phase.

Attributes of an effective Systems Analyst Systems analyst must have the following attributes: (a)

Knowledge of people: Since a systems analyst works with others so closely, he or she must understand their needs and what motivates them to develop systems properly.

(b)

Knowledge of Business functions: A systems analyst must know the environment in which he or she works. He must be aware of the peculiarities of management and the s at his installation and realize how they react to systems analyst. A working knowledge of ing and marketing principles is a must since so many systems are built around these two areas. He must be familiar with his company's product and services and management's policies in areas concerning him.

(c)

Knowledge of Data processing principles: Most systems today are computer based. The systems analyst must fully aware about the potential and limitations of computers.

(d)

Ability to communicate: As a coordinator, a systems analyst must communicate properly with people of different levels within an organisation. Systems analyst must listen carefully to what others say and integrate the thoughts of others into the systems development process.

(e)

Flexibility: Systems analysts must be flexible in their thinking since they often do not get-their own way. Different factions in an organisation have conflicting needs and most systems are the result of compromise. The analyst's goal is to produce the system that will be the best for the organisation. This requires an open mind and flexibility in his ideas.

(f)

An analytical mind: It takes an unusual person to see through problems facing an organisation and develop solutions that will work. Systems analysts often find themselves with more data than

they can cope with. It requires an analytical mind to select pertinent data and concentrate on them in defining problems and forming solutions. (g)

Well educated with sharp mind: Systems analysts are called upon to work with people at all levels virtually in every aspect of business. They must know how to work with all of them and gain their confidence. Analysts must have sharp mind to learn quickly how people do their jobs and develop ways for them to do it better.

Objectives of Feasibility Analysis The main objectives of feasibility analysis are – 

To identify the deficiencies in the current system.



To determine objectives of the proposed system.



To acquire a sense of scope of the system.



To identify the responsible s.



To determine whether it is feasible to develop the new system.

Consider our case scenario ‘Stock Monitoring System’ for finding the main objectives of feasibility study. The various objectives of feasibility analysis for are discussed below.

Deficiencies in the Current System The major deficiencies in the manual ‘Stock Monitoring System’ are –



Searching for a particular item or transaction is time consuming.



There is a possibility of making wrong entries in stock by the store clerk.



The management does not get stock status reports on time.



The purchase department cannot place orders on time.

Objectives of the Proposed System The main objectives of the proposed system are – 

To resolve the deficiencies of the current system.



To help the store clerk in doing his role more efficiently and correctly.

Scope of the Proposed System The proposed system can be – 

Developed further to get many inventory management reports; and



Integrated with other systems, viz. Production, Planning and Control systems and Invoicing system.

Responsible s The responsible s of the proposed system are store clerk and production manager.

Feasibility of the System Whether the proposed system is feasible to develop depends on many factors which we will discuss throughout this unit.

Steps in Feasibility Analysis Feasibility analysis is carried out in following steps: 1.

Form a Project Team and Appoint a Project Leader: First of all project management group of the organization forms separate teams for independent projects. Each project team comprises of one or more systems analysts and programmers with a project leader. The project leader is responsible for planning and managing the development activities of the system.

2.

Start Preliminary Investigation: The systems analyst of each project team starts preliminary investigations through different fact finding techniques.

3.

Prepare the Current Systems Flowchart: After preliminary investigations, the analysts prepare the systems flowchart of the current system. These charts describe the general working of the system in a graphical way.

4.

Describe the Deficiencies in the Current System: On studying the systems flowcharts, the analysts identify and describe the deficiencies in the current system.

5.

Determine Objectives of the Proposed System: The major objectives of the proposed systems are listed by each analyst and are discussed with the project leader.

6.

Prepare the Proposed Systems Flowchart: After determining the major objectives of the proposed system, the analysts prepare their systems flowcharts. Systems flowcharts of the proposed system are compared with those of current system in order to ensure that they meet the objectives.

7.

Determine the Technical Feasibility: The existing computer systems (hardware and software) of the concerned department are identified and their technical specifications are noted down. The analysts decide whether the existing systems are sufficient for the technical requirements of the proposed system or not.

8.

Determine the Economic Feasibility: The analysts determine the costs and benefits of proposed system in order to ensure that the project is economically feasible.

9.

Determine the Operational Feasibility: After determining the economic feasibility, the analysts identify the responsible s of the system and hence determine the operational feasibility of the project.

10.

Presentation of Feasibility Analysis: During the feasibility study, the analysts also keep on preparing the feasibility study report. At the end of feasibility analysis, the feasibility analysis report is given to the management alongwith the oral presentation.

Types of Feasibility During feasibility analysis, the analyst considers the three main types of feasibility – technical, economical and operational feasibility, all of which are interrelated. (a)

Technical Feasibility: During this study, the analyst identifies the existing computer systems (hardware and software) of the concerned department and determines whether these technical resources are sufficient for the proposed system or not. If they are not sufficient, the analyst suggests the configuration of the computer systems that are required. The analyst generally pursues two or three different configurations which satisfy the key technical requirements but which represent different costs. During technical feasibility study, financial resources and budget is also considered. The main objective of technical feasibility is to determine whether the project is technically feasible, provided it is economically feasible.

(b)

Economic Feasibility: Economic feasibility is the most important study that determines the cost and benefits of the proposed system and compares with the budget. The cost of the project should not outweigh the budget. The cost of the project includes the cost of hardware, software, development and implementation. Cost/benefit analysis is the common method to determine the benefits that are expected from the proposed system and compare them with the costs expected to spend on development of the system. If benefits are found to be more than costs, then the analyst decides to continue the development of the proposed system otherwise considers it economically not feasible. The feasibility study presents both tangible (e.g., increased productivity, low operating cost, etc.) and intangible benefits (e.g., improved organizational planning, improved asset utilization, etc.) in a formal way. We will discuss the cost/benefit analysis in a subsequent sub-section.

(c)

Operational Feasibility: When it is found that the project is both economic and technical feasible, the next step is to determine whether it is operationally feasible or not. During operational feasibility study, it is determined whether the system will operate in the way that wants. Operational feasibility depends upon human resources for the development and implementation of the system. It is considered whether the qualified and experienced manpower is available for development and implementation of the system. involvement is more required in determining the operational feasibility.

d.

Social Feasibility: Social feasibility is a determination of whether a proposed project will be acceptable to the people or not. This determination typically examines the probability of the project being accepted by the group directly affected by the proposed system change.

e.

Management feasibility: It is a determination of whether a proposed project will be acceptable to management. If management does not accept a project or gives a negligible to it, the analyst will tend to view the project as a non-feasible one.

f.

Legal feasibility: Legal feasibility is a determination of whether a proposed project infringes on known Acts, Statutes, as well as any pending legislation. Although in some instances the project might appear sound, on closer investigation it may be found to infringe on several legal areas.

g.

Time feasibility: Time feasibility is a determination of whether a proposed project can be implemented fully within a stipulated time frame. If a project takes too much time it is likely to be rejected.

After the feasibility study, a document is prepared that is known as ‘Feasibility Study Report’. Besides this report, the analyst also gives the oral presentation of feasibility study to the management.

Feasibility Analysis Report

Feasibility analysis report is a formal document for management use and is prepared by systems analyst during or after feasibility study. This report generally contains the following sections: (a)

Covering letter: It formally presents the report with a brief description of the project problem alongwith recommendations to be considered.

(b)

Table of Contents: It lists the sections of feasibility study report alongwith their page numbers.

(c)

Overview: It presents the overview of the project problem alongwith the purpose and scope of the project.

(d)

Description of Existing System: A brief description of the existing system alongwith its deficiencies are presented in this section.

(e)

System Requirements: The system requirements, which are either derived from the existing system or from the discussion with the s, are presented in this section.

(f)

Description of Proposed System: It presents a general description of the proposed system, highlighting its role in solving the problem. A description of output reports to be generated by the system is also presented in the desired formats.

(g)

Development Plan: It presents a detailed plan with starting and completion dates for different phases of SDLC. A complementary plan is also needed for hardware and software evaluation, purchase and installation.

(h)

Technical Feasibility Findings: It presents the findings of technical feasibility study alongwith recommendations.

(i)

Costs and Benefits: The detailed findings of cost and benefits analysis are presented in this section. The savings and benefits are highlighted to justify the economic feasibility of the project.

(j)

Operational Feasibility Findings: It presents the findings of operational feasibility alongwith the human resource requirements to implement the system.

(k)

Alternatives Considered/Rejected: The different alternatives that an analyst usually considers and rejects during feasibility study, should also be included in the feasibility study report. These alternatives are required to be discussed because they show, how the suggested system is the best alternative to solve the problem.

(l)

Recommendations and Conclusions: The benefits and savings are summarized and it is recommended whether the management should decide to proceed with the project or abort the project.

(m)

Appendixes: In the last section of feasibility study report, all memos, documents and data compiled during study are enclosed for reference.

Oral Presentations

Although, feasibility study report is the best written presentation of the proposed system, it is expected that the analyst gives an oral presentation to the management and end s. During oral presentation, many issues can be clarified and new ideas from the s can be picked up by the analyst. There is no standard form of the sequence of topics to be discussed during oral presentation by the analyst but the following general outline is suggested: I.

Introduction. A.

Self introduction by the analyst.

B.

A brief introduction of the problem.

C.

A brief description of the current system. (i)

Specify the drawbacks of the current system.

(ii)

Specify how the proposed system can solve the

problem. II.

Body of Presentation. A.

Describe Current System. (i)

Highlight drawbacks of the current system.

(ii)

Highlight how the current system cannot satisfy the

. B.

III.

IV.

Describe Proposed System. (i)

Highlight System Requirements.

(ii)

Highlight scope and objectives of the proposed system.

(iii)

Highlight savings and benefits of the proposed system.

C.

Describe implementation plan of the proposed system.

D.

Describe Operational Feasibility of the system.

Conclusion. A.

Summarize the proposal.

B.

Summarize the objectives and recommendations.

C.

Summarize the benefits and savings.

Discussion period.

Cost/Benefit Analysis Since cost plays quite an important role in deciding the new system, it must be identified and estimated properly. Costs vary by type and consist of various distinct elements. Benefits are also of different type and can be grouped on the basis of advantages they provide to the management. The benefits of a project include four types: (i)

Cost-savings benefits

(ii)

Cost-avoidance benefits

(iii)

Improved-service-level benefits

(iv)

Improved-information benefits

Cost-savings benefits lead to reduction in istrative and operational costs. A reduction in the size of the clerical staff used in the of an istrative activity is an example of a cost-saving benefit. Cost-avoidance benefits are those, which eliminate future istrating and operational costs. No need to hire additional staff in future to handle an istrative activity is an example of a cost-avoidance benefit. Improved-service-level benefits are those where the performance of a system is improved by a new computer-based method. Improved-information-benefit is where computer based methods lead to better information for decision-making. For example, a system that reports the most-improved fifty customers as measured by an increase in sales is an improved-information. This information makes it easier to provide better service to major customers.

Categories of Costs and Benefits The costs associated with the system are expenses, outlays or losses arising from development and using a system. But the benefits are the advantages received from installing and using this system. Costs and benefits can be classified as follows: (a)

Tangible or intangible

(b)

Fixed or variable

(c)

Direct or indirect

Tangible or Intangible Costs and Benefits Tangibility refers to the ease with which costs or benefits can be measure. An outlay of cash for any specific item or activity is referred to as a tangible cost. These costs are known and can be estimated quite accurately. Costs that are known to exist but their financial value cannot be exactly measured are referred to as intangible costs. The estimate is only an approximation. It is difficult to fix exact intangible costs. For example, employee moral problem because of installing new system is an intangible cost. How much moral of an employee has been affected cannot be exactly measured in of financial values. Benefits are often more difficult to specify exactly than costs. For example, suppliers can easily quote the cost of purchasing a terminal but it is difficult for them to tell specific benefits or financial advantages for using

it in a system. Tangible benefits such as completing jobs in fewer hours or producing error free reports are quantifiable. Intangible benefits such as more satisfied customers or an improved corporate image because of using new system are not easily quantified. Both tangible and intangible costs and benefits should be taken into consideration in the evaluation process. If the project is evaluated on a purely intangible basis, benefits exceed costs by a substantial margin. We call such projects cost effective. On the other hand, if intangible costs and benefits are included, the total costs (tangible-intangible) exceed the benefits making the project an undesirable investment. Hence it is desirable that systems projects should not be evaluated on the basis of intangible benefits alone.

Direct or Indirect Costs and Benefits Direct costs are those which are directly associated with a system. They are- applied directly to the operator. For example, the purchase of floppy for Rs.400/- is a direct cost because we can associate the floppy box with money spent. Direct benefits also can be specifically attributable to a given project. For example, a new system that can process 30 per cent more transactions per day is a direct benefit. Indirect costs are not directly associated with a specific activity in the system. They are often referred to as overhead expenses. For example, cost of space to install a system, maintenance of computer centre, heat, light and air-conditioning are all tangible costs, but it is difficult to calculate the proportion of each attributable to a specific activity such as a report. Indirect benefits are realized as a by-product of another system. For example, a system that tracks sales-calls on customers provides an indirect marketing benefit by giving additional information about competition. In this case, competition information becomes an indirect benefit although its work in of money cannot be exactly measured.

Fixed or Variable Costs and Benefits Some costs and benefits remain constant, regardless of how a system is used. Fixed costs are considered as sunk costs. Once encountered, they will not recur. For example, the purchase of an equipment for a computer centre is called as fixed cost as it remains constant whether in equipment is being used extensively or not. Similarly, the insurance, purchase of software etc. In contrast, variable costs are incurred on a regular basis. They are generally proportional to world volume and continue as long as the system is in operation. For example sample, the cost of computer forms vary in proportion to the amount of processing or the length of the reports desired. Fixed benefits also remain constant by using a new system, if 20 percent of staff member are reduced, we can call it a fixed benefit. The benefit of personnel saving may occur month. Variable benefits, on the other hand, are realized on a regular basis. For example are reduced, we can call it a fixed benefit. The benefit of personnel saving may occur month. Variable benefits, on the other hand, are realized on a regular basis. For example

the library information system that saves two minutes in providing information about a month. Variable benefits, on the other hand, are realized on a regular basis. For example the library information system that saves two minutes in providing information about particular book whether it is issued or not, to the borrower compared with the manual system. The amount of time saved varies with the information given to the number of borrowers.

Structured Analysis Structured analysis is a development method for analysis of an existing system. It is a set of techniques that allow the analyst to design the proposed system. The main purpose of structured analysis is to completely understand the current system.

Tools of Structured Analysis Data flow diagrams, data dictionary and process descriptions are the main tools for structured analysis. (a)

Data Flow Diagrams (DFDs): Data flow diagrams are widely used graphic tools for describing the movement of data within or outside the system. As a DFD consists of a series of bubbles ed by lines, it is also known as a ‘bubble chart’. The basic DFD format is shown in Figure 4.5.

(b)

Data Dictionary: Data dictionary is an organised list of and their definitions for all the data elements and data structures that are pertinent to the system. It stores the names alongwith their descriptions of all data used in a system.

Figure 4.5: Basic DFD Format for a Generalised Payroll Application

(c)

Process Descriptions: Process descriptions are another major tool of structured analysis, that describe the sequence of different processes in the system. Structured English (pseudocode), decision tree and decision table are commonly used process descriptions.

Data Flow Diagrams During analysis phase of SDLC, the systems analyst or other of the project team draw many diagrams to show how data move within an organisation. These diagrams, popularly called as DFD (Data Flow Diagram), quickly convey to both the software developers and s how the current system is working and how the proposed system will work. The main advantage of DFD is that they are easily understood by the s, and hence s can suggest modifications in the proposed system. We will discuss now the different types of DFD and see how these DFD can be drawn.

Determination of DFD Armed with interview results, tabulated questionnaires, and experience through personal observations, the analyst is ready to describe the current system in narrative form, with a data-flow diagram, or with a system flowchart. Since all organisations have an s payable (AP) system

let us being with such an example using a context DFD. A context DFD defines the system under study in a general form, showing: Inputs to AP: Packing slips, invoices, checking balances, payment notifications. Outputs from AP: reports to management, cheque to suppliers.

Figure 4.6: A context data-flow diagram depicts a typical s payable system in its broadest perspective, not showing any of the details or internal processes

A context DFD does not show any detail but is an overview drawing of the system. It is an excellent diagram to share with management whose interest is general in nature. Context DFDs place a boundary around the system under investigation, saying that this is what will be examined nothing more and nothing less. After developing a context DFD, the analyst turns his attention to the details of s able. Management reviews inventory reports and determines what to order from suppliers orders are placed by the ing department using a purchase order/requisition: on delivery merchandise and packing slips enter the warehouse, and packing slips are sent to the ing department, which receives invoices directly from suppliers, while merchandise stays the warehouse or goes to a distribution outlet. ing clerks compare purchase order requisitions with invoices and packing slips to make sure all invoiced items have actually rived, and then post the purchase to the supplier's ledger. At the end of each month, the ing department prepares a report of balances due suppliers-and an inventory report for management evaluation. These detailed activities by the ing department, management, warehouse personnel the bank and suppliers add up lo six major activities (Figure 4.8):

1.

Generation of reports

2.

Ordering of stock

3.

Printing of cheque

4.

Posting of s

5.

Reconciliation of bank statements

6.

Authorisation of payment

During the design phase of the systems process, the analyst will study each of these activities further, leveling the data-flow diagram of Figure 4.7 into far more details. To draw the analysis DFD: 1.

Look at the system from the inside to the outside

2.

Identify the activities

3.

Locate the data flows

4.

Show the relationships between activities

5.

Find the internal inputs or outputs that exist within the system

6.

Level complex processes in the DFD into simpler ones

7.

Look for duplication of data flows or data stores (Files)

Figure 4.7

While determining the flow of data, the analyst collects samples of all relevant documents, such as sample cheques, invoices, packing slips, and other relevant forms. To create a record of all purchases from and

payments to suppliers, a manual system requires that someone prepare a ledger entry for each supplier.

The assembled documents help an analyst understand what data the new system must collect and process. For example, the company can easily obtain the following data from the invoice itself: 1.

Supplier name, address, and telephone number

2.

Invoice number

3.

Invoice dale

4.

Invoice

5.

of invoice

6.

Amount of invoice

From the packing slip, it can obtain 1.

Supplier name

2.

Shipping date

3.

Date goods are received

4.

Freight charges

5.

Invoice number

Packing slips are carbon copies of invoices omitting certain data, such as the money value of the shipment. The warehouse clerk checks the merchandise received against the packing slip to be sure everything is in the carton and notes any discrepancies. Then the packing slip goes to ing for comparison with invoices to be sure that the company received what it is paying for. The ledger offers two purchase/payment history:

categories

1.

Supplier name

2

Supplier address

3.

Supplier telephone number

4.

Date of transaction

5.

Description of transaction

6.

Amount of invoice or payment

7.

Discount

8.

Balance due the supplier

offers

supplier

Each cheque sent to a supplier contains the following data: 1.

Invoice number

data

and

2.

Cheque number

3.

Amount of payment

4.

Payment date

In addition to these documents, it is useful to have copies of reports prepared by the ing department

Types of DFD There are two types of DFD - Physical and Logical DFD. (a)

Physical DFD: The data flow diagrams which represent the model of the current system (manual or computerised), are known as physical DFD. These diagrams are drawn, when the analyst studies the current working system in detail.

(b)

Logical DFD: The data flow diagrams which represent the model of the proposed system, are known as logical DFD. These diagrams are drawn from the physical DFD.

Each of these DFD can be further categorised into different levels like zero level (context diagram), first level, second level and third level. Each higher level DFD is drawn by adding more details to each process of lower level, by a technique called ‘Exploding DFD’. We will learn these techinques in subsequent sections.

DFD Modelling Notation The four notations that are widely used in DFD, are shown in Table 4.2. The description of these notations is explained below – Table 4.2: DFD Modelling Notation

(a)

External Entity: External Entity represents any entity that supplies data or receives information from the system. For example, customer, sales department, employee, etc., are external entities.

(b)

Data Flow: The data flow indicates the movement of data either from input to process or from process to output. Data flow is labeled to show what data is flowing. For example, customer details, sale reports, etc., are data flows.

(c)

Process: Processes are the actions performed on input data to produce the output data. They are given some meaningful names. For example, Prepare Bill, Calculate Sales, Compute Pay, etc., are the processes.

(d)

Data Store: Data store indicates the data file or where data is accumulated. For example, Customer Master File, Employee , Sales Transaction File, etc., are data stores.

Steps to Draw DFD The different level physical and logical DFD are generally drawn in the following steps: 1.

Identify external entities and data flows of the current system and draw physical context diagram.

2.

Identify data stores and processes of the system and draw first level physical DFD.

3.

Explore the processes of first level and draw second level DFD.

4.

Explore the processes of second level and draw third level DFD.

5.

Derive the logical view of each physical DFD by the following ways(a)

Remove documents and show actual data in data flow.

(b)

Remove s and use files as data stores.

(c)

Remove unnecessary processes.

(d)

Remove data flow between external entities (if any) and show data flow through processes.

Data Dictionary Data dictionary is a catalogue of all data elements, data structures and processes described in logical DFDs. Before we discuss the importance and contents of a data dictionary, let us understand the meaning of the following terminology: Data Element: Data element is the smallest unit of data that has some meaning. For example, part code, part name, date of transaction, etc., are data elements. Data Structure: Data structure is a group of data elements that describe a unit in the system. For example, Part Details is a data structure that contains part code, part name and date of transaction as data elements. Data Store: Data store is a data structure for collecting data input during processing. For example, Part is a data store. Data Flow: Data flow is a data structure, that shows a unit of data in motion. For example, New Part Details is a data flow that moves from an external entity to a process. The data elements, data stores, data flows and processes are described in a data dictionary as illustrated in Figures 4.13, 4.14, 4.15 and 4.16.

Part Code Data Element Short Description: This element describes the code of a part or subassembly. Organisation: B.R. Auto Limited Date: Aliases (contents): Part Number If Discrete Value

If Continuous

Meaning

Range of Value: A001 to Z999 Typical Value: A001 Length: 4 Internal Representation: Character

Figure 4.13: An Example of Data Element in a Data Dictionary Data Dictionary Transactions file Data Store Description: Day’s Transaction Data Flow in: Issue, Return, Receipt

Data flow out: Consolidated transaction of the day

Contents: Part No., Part Name, Date of Transaction, Issue, Receipt, Name of Concerned Person and Posting Status Physical Organisation: Store

Figure 4.14: An Example of Data Store in a Data Dictionary New Part Details

Data Flow

Source Ref. Description:Part Destn. Ref. Description: Part Expanded Description: Part Details like: Part code, Part name, Date Transaction etc. are entered into the Part .

of

Included data structure:

Volume Information

Part

Volume increases when new part is entered but do not decrease when old part is discarded.

Figure 4.15: An Example of Data Flow in a Data Dictionary

Description: Maintain Part Process Input New part details

Logic Summary All part details with

Output Updated

part a unique part code is accepted. Duplicate part code is not accepted Daily Transaction Details

Daily Transactions Details of those part codes are accepted that exist in Part-s.

Figure 4.16: An Example of Process in a Data Dictionary

Importance of Data Dictionary Data dictionary is an important tool for structured analysis as it offers following advantages

It is a valuable reference for deg the system. It is used to build the database and write programs during design phase.



It assists in communicating meanings of different elements, and procedures.



It facilitates analysis in determining additions and changes in the system.



It helps the analyst to record the details of each element and data structure.

 

It is used to locate errors in the system descriptions. It is also a useful reference document during implementation of the system.

Data Dictionary Data dictionary is a repository of data about data (metadata). It contains information about each of the component of DFDS, data stores, processes and data flowed. DD is a integral part of system specifications, since with it, DFDS are just pictures with no details e.g. Emp-master

Empho

Data flows:

4

Empted

Get empted

Emp_no: Char (6) Emp_details: Ep_Empa_add+Emp_det Data stores: Emp_record: Emp_no + Emp_no+Emp_add+Emp_doc Process do while not of empmaster open emp_master gotop get emp_det

Basic Notations used for DD = is equivalent of + And [ ] either or ( ) optional entry Alias Another nature.

Why Data Dictionary? A data dictionary defines each term (called a 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 vendor's name and address at the bottom of a cheque. The data dictionary might define vendor's name and address as follows: Vendor name and address =

Vendor name +

Street + City+ State + Pin + Phone + Fax+ e: mail This definition becomes a part of the data dictionary that ultimately will list all key used to describe various data flows and files.

Four Rules Four rules govern the construction of data dictionary entries: 1.

Words should be defined to stand for what they mean and not the variable names by which they may be described in the program; use CLIENT_NAME not ABQ or CODE06. Capitalization of words helps them to stand out and may be of assistance.

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, Individual's name

which we might further decompose to Company name

=

Individual's name =

() + Business name Last name + First name + (Middle initial)

After defining a term, say VENDOR NUMBER, we list any aliases or synonyms, describe the term verbally, specify its length and data type, and list the data stores where the term is found (figure 4.8). Some may have no aliases, may be found in many files, or may be limited to specific values. Some self-defining or obvious words and 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 s s must enter to gain access to sensitive data. Rather, data dictionaries offer definitions of words and 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.

DATA ELEMENT NAME:

VENDOR_NUMBER

ALIASES:

None

DESCRIPTION: s payable system.

Unique

FORMAT:

Alphanumeric, six characters.

DATAFLOWS:

Vendor master s payable open item s payable open adjustments Cheque reconciliation

REPORTS:

Alphabetic vendor list Numeric vendor list A/P transaction Open item Vendor inquiry Cash requirements Pre-cheque-writing Cheque Vendor analysis

identifier

for

vendors

in

the

Figure 4.8

There are two kinds of data dictionaries: (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 any one 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.

Data Dictionary Functions Both these types of dictionaries can be identified by functions as either ive, active, or inline. Viewed either way, by type or function, the differences are striking. ive, active, and in-line dictionaries differ functionally as follows:

ive Data Dictionaries The functionally ive 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 ive dictionary has clear advantages. From the organisational view the documentation function is the most important dictionary service with the most potential benefits, so the ive dictionary should not be thought of negatively. It has more limited functionality but may perform its critical function of global documentation best of all.

Active Data Dictionaries Besides ing documentation to one degree or another, the active data dictionary s program and operations development by exporting database definitions and program data storage definitions for languages such as COBOL and Job Control Language (JCL) for executiontime 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 proportions.

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 are associated with DBMS products such as Cullinet Software Corporation's IDMS-R or Cincom System's TOTAL, to name just two. The Make-up of Data Dictionaries: Data Dictionary Internals The minimum data dictionary is shown in figure 4.9

Figure 4.9: Minimum Data Dictionary

We have a database system consisting of databases or files. These files consist of data groups or segments or records. These data groups consist of data items or fields. There is an implicit relationship here, which needs no additional comment. A certain amount of attribute information is always present In the case of data items we need to know if it is a primary or secondary key or an attribute field, if it has aliases, what are the field type and field size, what is the name in various languages, and what is the description of the item. We need to know whether the data item or data group is in test, system test, or production status need to know the number of occurrences of this data item on the dictionary. Addressing these last points, a data item (for instance) on the IBM data dictionary may lok strange to the uninitiated. It will look like this: T,C,BALANCE-ON-HAND,0 We recognize balance-on hand as an inventory quantity. The T is the status code, which will say is T because the data- item balance-on-hand is on the test-data database. The C is the subject code, which in this case is the primary programming language: COBOL. The 0 is the occurrence number where duplication exists in the common information system. So, of this dictionary, the full description of the data-item consists of the four elements mentioned above. This convention holds for all subjects defined on the IBM data dictionary. Before discussing the functions of the full-service extended data dictionary we need to review data-dictionary elements. Figure 4.10 shows these elements.

Figure 4.10: Data-Dictionary Elements

We have already referred to categories, subjects, relationships, attributes, and descriptions on other occasions. These are the elements that make up the data dictionary. In figure 4.6, Category A has a forward and reverse relationship to Category B. We have two-way relationships simply because we may want to examine these relationships in both directions. Data-Item is an example of a category. In a full- service dictionary some categories are predefined regarding attributes and relationships, but the dictionary has the capacity to handle -defined categories. This, in IBM parlance, is an extended use of the dictionary. This "extensibility" feature is the heart of the full-service dictionary, allowing documentation of the whole organization and allowing us to use the dictionary as the software for strategic and tactical planning. Category A in figure 4.13 has four subjects. Each subject has the same attribute set as the others (attributes AA, AB, AC). For instance the category may be Projects. The four subjects are four different projects, described by name and description as unique. Perhaps the attributes are Project Leader, Project Due Date, and Percent Accomplished. All four subjects would have identical attribute names. Perhaps Category B is Information Systems, with subjects and attributes defined in a similar fashion. The forward relationship might be Projects ACCOMPLISH Information Systems. Reverse might be ACCOMPLISHED-BY. Figure 4.14 shows another example of the elements that make up a datadictionary database. In this case we have the category Business Function (or department) related to the Processes of the organisation such as Provide-Materials. that the subject name looks like this: P„Provide-Materials,0. that the P is the status code, which in

this case stands for Production. The two adjacent commas means the subject code is not used for this kind of category, and the zero is the occurrence (only this occurrence exists).

Figure 4.11: Example of Data-Dictionary Elements

The IBM data dictionary, which is actually six linked databases, each with many segments, consists of standard categories and the infrastructure needed to "customize" installation categories. The standard categories have the attributes prebuilt and ready for the to fill in. These standard categories are: 

DATA-BASE



SEGMENT



ELEMENT



PROGRAM COMMUNICATION BLOCK



IMS SYSTEM DEFINITION



APPLICATION SYSTEM



JOB



PROGRAM



MODULE



TRANSACTION



PSB

These categories are all related to servicing the data processing function and are not sufficiently broad in scope to a dictionary for the entire organisation. The strategic plan cannot be documented with just these categories. It is the ability of this data dictionary to allow the creation of other -defined categories that allows us to consider the dictionary a serious tool for systems analysis and documentation in of the current and new system applications.

Process Organisation and Interaction Organization refers to the structure and order of hierarchical steps. Organization means the arrangement of components things. Organization means the arrangement of components so that we become able to achieve our goals or objectives. For example in a typical company the hierarchial relationships of the employees begins with the president at the top. After president there may be vice presidents, department hands and the hierarchy goes to blue-collar works. Such as relationship describes the structure of authority, specifies the formal flow of communication and formalize the chain of command. Another example of an organization is a computer system which consists of input devices, output devices control processing unit, etc., These components are organized or linked together to achieve the goal, i.e., to process data, etc., Hence in a business system the organization of different workers plays an important role for the success of the system. Interaction describe the way in which each component of a system functions with other components. For example, in a factory purchasing must interact with production, advertising with sales, and payroll with personnel. In a computer system each component should interact with another in order to solve the problem. The central processing unit should interact with input devices in order to take input and start processing. In a business system there must be a proper interaction between system. There must be a proper interaction between different levels. Presidents should interact with managers with their subordinates and so on. If there is interaction between different levels then the system will run smoothly.

Process Descriptions After defining all the data elements and data structures in the data dictionary, the systems analyst begins to describe the processes. Process descriptions are the tools for documenting the procedures and describing the system logic. They contain the logic used to process the input data for getting the output. The commonly used process description tools are– (a)

Structured English - used to describe a procedure in simple English statements.

(b)

Decision Tree - used to describe a set of conditions and actions diagrammatically.

(c)

Decision Table - used to describe a set of conditions and actions in a tabular form.

Structured English Structured English is used to describe the logic of a process. It consists of simple narrative sentences and adheres to limited vocabulary and limited syntaxes. Structured English uses narrative statements to describe a procedure and reserve words for logical formulation. No strict syntaxes but simple English words with vocabulary consisting of: i.

Imperative English language verbs

ii.

defined in data dictionary

iii.

Reserved or key words for logic formulation

Eg. Keywords BEGIN……END IF….ELSE, ENDIF REPEAT…..UNTIL WHILE…..DO It uses three basic types of statements (a)

Sequence Structures: They include a set of instructions that are carried out one after another and do not depend on any condition.

(b)

Decision Structures: They include one or more sets of instructions that are carried out depending upon one or more conditions. They generally use the phrase IF THEN ELSE to carry out different actions.

(c)

Iteration Structures: They include a set of instructions that are repeated until a particular condition occurs. They generally use the phrase DO WHILE ...ENDDO to repeat a set of instructions.

The examples of these three types of statements are illustrated in Table 4.3. Table 4.3: Examples of Three Types of Statements Sequential Structure:

Decision Structure:

Accept employee code Accept employee name Accept other details Store data

If Basic_Pay <=1000 HRA = 500 Else If Basic_Pay <= 3000 HRA = 1000 Else HRA = 1500 Endif Endif

Decision Tables and Decision Trees

Iteration Structure Ans = “Y” Do while Ans = “Y” Accept employee code Accept employee name Acet other details Display “Continue (Y/N)?” Accept Ans Enddo

Decision tables and trees were developed long before the widespread use of computers. They not only isolate many conditions and possible actions, but they help ensure that nothing has been overlooked.

Decision Tables The decision table is a chart with four sections listing all the logical conditions and actions. In addition the top section permits space for title, date, author, system and comment The condition stub displays all the necessary tests or conditions. Like the diamond in a flowchart or the IF in pseudocode, these tests require yes or no answers. The condition stub always appears in the upper left-hand corner of the decision table, with each condition numbered to allow easy identification. Thus Condition stub is a list of all the necessary tests in a decision table. In the lower left-hand comer of the decision table we find the action stub where one may note all the processes desired in a given module. Actions, like conditions, receive numbers for identification purposes. Thus Action Stub is a list of all the processes involved in a decision table. The upper right corner provides space for the condition entry - all possible permutations of yes and no responses related to the condition stub. The yes or no possibilities are arranged as a vertical column called rules. Rules are numbered 1,2,3, and so on. We can determine the number of rules in a decision table by the formula: Number of rules = 2 h N where N represents the number of conditions and h means exponentiation. Thus a decision table with four conditions has 16 (2M = 2x2x2x2 = 16) rules one with six conditions has 64 rules and eight conditions yield 256 rules. Thus Condition entry is a list of all the yes/no permutations in a decision table. The lower right comer holds the action entry. X's or dots indicate whether an action should occur as a consequence of the yes/no entries under condition entry. X's indication action; dots indicate no action. Thus Action entry Indicates via dot or X whether something should happen in a decision table.

Figure 4.17

Returning to the assembly of a bicycle, let us assume we must assemble a variety of containers full of parts. Since a bike can have either hand caliper or foot coaster brakes, the decision table must show the two conditions

and five actions (figure 4.18). The two conditions necessitate four condition entries, and the five actions produce 20 possible action entries. When we build the yes or no rules for the condition entry, we must construct all possible patterns of y's and n's. An arrangement that guarantees thoroughness is to place two y's is succession followed by two n's. In the second row, we place alternating pairs of y's and n's. (a)

Decision table for bicycle assembly:

Figure 4.18: Decision table for bicycle assembly

A decision table with four conditions (2M = 16) would have 16 different sets of y's and n's and would result in the following pattern of yes and no responses. The first row therefore will have eight y's followed by eight n's. The second row (corresponding to the second entry in the condition stub) has four y's, four n's, four y's and four n's. The complete four-condition entry would read:

This form ensures that the analyst includes all combinations with duplication. If large number of conditions exist (four conditions result in 16 condition entries, six conditions in 64), decision tables can become unwieldy. To avoid lengthy decision tables, analysts must remove redundancies and yet still take precautions not to overlook anything. On occasion, two or more rules may be combined to reduce or eliminate redundancy. In figures 4.19 and 4.20, rules 1 and 2 cause the last action in the action stub to occur. Therefore, these two-rules could be combined to eliminate redundancy. To indicate redundancy, we put a dash (-) in the condition entry to show that this condition stub is irrelevant and can be ignored. The decision table in figure 4.21 depicts the AP cheque module. Compare with figure 4.16 (IPO). Although this format is fairly typical, in practice you

will encounter several different kinds of decision tables. Figure 4.22 called limited entry, because the condition entry contains yes or no responses for each rule. Limited Entry: A type of decision table listing a y or n response for each condition.

AP cheque decision table:

Figure 4.19: A limited entry decision table

Extended Entry: Type of decision table displaying values to be tested in the condition entry (Figure 4.23). AP cheque written as an extended-entry decision table:

Figure 4.20: An extended-entry decision table

Mixed Entry; A type of decision table mixing values in the condition and action entries. AP cheque written as a mixed-entry decision table: Shown below in Fig. 4.24

Figure 4.20: A mixed-entry decision table

Open ended (1) A type of decision table that permits access to another decision table. (2) Questionnaire items that respondents must answer in their own words. A mixed-entry decision table combines the values and yes or no (Figure 4.24), while an open-ended one allows an action entry specifying an additional decision table(figure 4.25). An analyst may want to use one of these other types of decision tables to make the table more readable for a or manger or to decompose a large (seven conditions leading to 128 rules) table into a series of smaller ones. AP cheque decision table (open-ended):

Figure 4.21: A open-ended decision table

Besides deg screen layout formats and determining screen specifications, the design must develop input controls for interactive dialogue and illustrate the way in which screens and menus are linked together. Three tools which help the design team in doing this are dialogue trees, decision trees, and picture-frame analyst With dialogue and decision trees, the team is able to show the flow of control in processing, including the actions s can take to halt or stop an input procedure. With pictureframe analysis, the design team is able to provide a walk-through of how screens will appear once a design becomes operational.

Tree Once the data elements are defined in the data dictionary, we begin to focus on the processes. Trees provide a graphical representation of logics for non-technical people to understand easily:

Example If the analyst requires “What is the discount policy?” He may will be shown a memo, which looks like: Trade discount (to established booksellers) is 20%. For private customers and libraries, 5% discount is allowed on orders for 6 books or more, 10% on orders for 20 books or more, and 15% on orders for 50 or more. Trade orders for 20 books and over receive the 10% discount in addition to the trade discount. The tree for the process will be:

Type of customer Ordersie Discount 20 or more……………… 30% Trade Less than 20……………..20%

50 or more……………… 15% 20-49…………………….10% 6-19………………………5%

Private or Librarian

Less than 6…………………Nil

Figure 4.22: Tree Representation of Logic

The branches of the tree correspond to each of the logical possibilities. A dialogue tree maps the static and dynamic messages that take place between the computer and the . Figure 4.27 shows the design of a tree for a simple file processing menu.

Figure 4.23: Dialogue Tree showing branches from promoting menus

As shown, a dialogue tree has multiple branch points when menus are used, and forks at yes or no points. If we trace the steps shown in figure 4.27, the dialogue tree should lead you to conclude the following:

1.

When an initial response of 2 is received, the program branches to a procedure to DELETE A RECORD from the employee master file.

2.

Before a record is deleted, the is asked to that the employee name is correct. The message reads: EMPLOYEE NAME OK?

3.

If the name is correct, the tree forks and asks: SURE YOU WANT TO DELETE?

4.

If the name is incorrect, the tree forks and asks: NAME OK NOW?

5.

If the name is correct (is OK now) and the responds yes to the question sure you want to Delete, the record is removed from the file.

6.

If the name is not correct, or if the name is correct but the decides not to delete control is shown as "return to start" - namely, a loop back to the start of the tree.

Isn't this tree incomplete? If the employee name is not correct at node 2.0, how could it be correct at node 2.1? an expanded dialogue tree, like the one shown in figure 4.28, helps fill the missing messages. The more detailed tree shown a node with an X. This is a nonrestricted node, meaning that it is not restricted to a prescribed number of choices. The first nonrestricted node indicates that it is necessary to find an employee record before testing to determine whether the name is correct. Moreover, if a record is found but the name is incorrect, a second attempt (as noted by a second unrestricted node) is made to find the correct employee record. If this second search is successful, the is aksed: NAME OK NOW?

Figure 4.24

Decision Trees At times, a dialogue tree is too specific for design teams to work with. What they prefer is an easier-to-follow mapping of a complex design. This mapping should show branch points and forks, but not the details of the dialogue. A decision tree helps to show the paths that are possible in a design following an action or decision by the . Figure 4.29 illustrates this second type of tree. As indicated, if the selects 1, followed by M and A, the algebra menu would be displayed.

Figure 4.25

What is the value of a tree such as this? It helps the designer visulaize how the will move through the design to reach a desired location. Thus, a decision tree provides an overview of the flow of consol to be built into computer programs. Decision trees turn a decision table into a diagram (figure 4.30). This tool is read from left to right, decisions result in a fork, and all branches end with an outcome. Figure 4.30 shows the decision trees for printing the s payable check. Trees can be easily ready by nontechnical s who dined decision tables too complex. s readily grasp branches, folks, and outcomes.

Figure 4.26: Decision trees she graphic equivalents of decision tables

The Process of Design The design phase focuses on the detailed implementation of the system recommended in the feasibility study. Emphasis is on translating performance specifications into design specifications. The design phase is a transition from a -oriented document (system proposal) to a document oriented to the programmers or data base personnel. Logical and Physical Design Systems design goes through two phases of development: logical and physical design. As we saw in Chapter 6, a data flow diagram shows the logical flow of a system and defines the boundaries of the system. For a candidate system, it describes the inputs (source, outputs (destination), data bases (data stores), and procedures (data flows)—all in a format that meets the 's requirements. When analysts prepare the logical system design, they specify the needs at a level of detail that virtually determines the information flow into and out of the system and the required data resources. The design covers the following: 1.

Reviews the current physical system—its data flows, file content, volumes, frequencies, etc.

2.

Prepares output specifications—that is, determines the format, content, and frequency of reports, including terminal specifications and locations.

3.

Prepares input specifications—format, content, and most of the input functions. This includes determining the flow of the document from the input data source to the actual input location,

4.

Prepares edit, security, and control specifications. This includes speeding the rules for edit correction, backup procedures, and the controls that ensure processing and file integrity.

5.

Specifies the implementation plan.

6.

Prepares a logical design walkthrough of the information flow, output, input, controls, and implementation plan.

7.

Reviews benefits, costs, target dates, and system constraints.

As an illustration, when a safe deposit tracking system is designed, system specifications include weekly reports, a definition of boxes rented and boxes vacant, and a summary of the activities of the week—boxes closed, boxes drilled, and so on. The logical design also specifies output, input, file, and screen layouts. In contrast, procedure specifications show how data are entered, how files are accessed, and how reports are produced. Following logical design is physical design. This produces the working system by defining the design specifications that tell programmers exactly what the candidate system must do. In turn, the programmer writes the necessary programs or modifies the software package that accepts input from the , performs the necessary calculation through the existing file or data base, produces the report on a hard copy or displays it on a screen, and maintains an updated data are at all times. Specially, physical system design consists of the following steps: or database, produces the report.

Figure 5.1: Safe Deposit Tracking System

1.

2.

Design the physical-system. (a)

Specify input/output media.

(b)

Design the data base an specify backup procedures.

(c)

Design physical information flow through the system and a physical design walkthrough.

Plan system implementation. (a)

Prepare a conversion schedule and a target date.

(b)

Determine training procedure, courses, and timetable.

Devise a test and implementation hardware/software.

plain

and

specify

and

new

The physical design for our safe deposit illustration is a software pack-age written in Pascal (a programming language). It consists of program steps that accept new box rental information; change the number of boxes available with every new box rental; print a report by box type, box size, and box location; and store the information in the data base for reference. The analyst instructs the software programmer to have the package display a menu that specifies for the how to enter a new box rental, produce a report, or display various information on the screen. These and other procedure specifications are tested and implemented as a working model of the candidate system

Logical Models Logical models show what a system is or does. They are implementation independent; that is, they depict the system independent of any technical implementation. As such, logical models illustrate the essence of the system. Popular synonyms include essential model, conceptual model, and business model.

Physical Models Physical models show not only what a system is or does, but also how the system is physically and technically implemented. They are implementation-dependent because they reflect technology choices and the limitations of those technology choices. Synonyms include implementation model and technical model. Systems analysts have long recognised the value of separating business and technical concerns. That is why they use logical system models to depict business requirements and physical system models to depict technical designs. Systems analysis activities tend to focus on the logical system models for the following reasons: 

Logical models remove biases that are the result of the way the current system is implemented or the way that any one person thinks the system might be implemented. Thus, we overcome the “we’ve always done it that way” syndrome. Consequently, logical models encourage creativity.



Logical models reduce the risk of missing business requirements because we are too preoccupied with technical details. Such errors can be costly to correct after the system is implemented. By separating what the system must do from how the system will do it we can better analyse the requirements for completeness, accuracy, and consistency.



Logical models allow us to communicate with end-s in nontechnical or less technical languages. Thus, we don’t lose requirements in the technical jargon of the computing discipline. Here we will focus exclusively on logical process modeling.

Logical Deg Requirements of a System Once a commitment has been made by the , the decision-makers, the analyst and the designer work together to translate the logical model and the tentative physical design into a firm physical design. Logical Deg consists of the following phases: a.

Review the current physical system The current physical system analyzed in order to perform the logical design of the proposed system. This analysis consists of the followings: i.

Physical Data Flows. A physical data flow represent the planned implementation of an input to or output form a physical process. It also indicates database action such as create, delete, read or update a record. It also represents the import of data from or the export of data to another important system across a network. Finally, it represents the data flows between two modules or subroutines within the same program. Hence a physical data flow helps to understand the system.

ii.

File Contents: Now we have to analyze the files used by the current system. We know that a file is the set of similar records. there may be many types of files in a system such as Master files, which contains the relatively permanent records; Transaction files, which contain, the records that describes the business events; Document files which contain the stored copy of historical data for easy retrieval & review; Archival files, which contain the record that are deleted from Master and Transaction files from on – line storage; Audit files, which are special records of update to other files, especially master and transaction files. The analysis of the contents of these files would helps to design the new system.

iii.

Volumes: Volume analysis is the analysis of the data used by the current system. The size of the database used by the current system may severely large. We see that whether this volume can be reduced. We try to design a new system with respect to this volume.

iv.

Frequency: In the last phase of the reviewing the current system we analyze the frequency of the data used by the system. That is, how frequently the data is used by the

system. It may be possible that the data is retrieved after a fixed period (a day, a week or a month etc.) for processing. If this is the case then we can use sequential file system and a batch processing system. If the records are accessed frequently then we propose an on – line processing system and we have to use a direct access file system. b.

Prepare Output Specification This phase sees the output requirements of the system. It consists of the following: i.

–

Format and Content of the Output: You must understand the type and purpose of the output. Is the output an internal or external report? If it’s an internal report, is it a historical, detailed, summary, or exception report? If it‘s an external report, is the form a turnaround document? After assuring yourself that you understand what type of report the output is and how it will be used, you need to address several design issues. –

What medium would best serve the output? Various media were discussed earlier in the chapter. You will have to understand the purpose or use of the output to determine the proper medium. You can select more than one medium, for instance, video with optional paper. All these decisions arc best addressed with the system s.

–

What would be the best format for the report? Tabular? Zoned? Graphic? Narrative? Some combination of these? After establishing the format, you can determine what type of form or paper will be used. Computer paper comes in three standard sizes: 8½ by 11, 11 by 14, and 8½ by 14 inches. Many printers can now easily compress 132 columns of print into an 8-inch width. You need to determine the capabilities and limitations of the intended printer. Despite the increase in larger 17-inch and 21-inch high-resolution monitors today, it is still recommended that display outputs (thus, the entire application screen) are designed for the lowest common denominator to ensure that all s be able to run the application and see the screens on their computers. Thus, it is still recommended that screen applications be able to run on systems having 640 by 480 screen resolution.

–

How many pages or sheets of output will be generated for a single copy of a report? This information is necessary to accurately plan paper and form consumption. Does the output require multiple copies? If so, how many? Photocopy (doesn't tie up printer)? Carbons (most printers can make not more than six legible carbons)? Duplicates (requires the most printer time, although laser printers are changing this situation)? For external documents, there are also several alternatives. Carbon and chemical carbon are the most common duplicating techniques. Selective carbons are a variation whereby certain

fields on the master copy will not be printed on one or more of the remaining copies. The fields to be omitted must be communicated to the forms manufacturer. Two-up printing is a technique whereby two 'sets of forms, possibly including carbons, are printed side by side on the printer. –

For printed outputs, have distribution controls been finalized? For on-line outputs, access controls should be determined.

–

For attributes contained on the output, what format should be followed?

ii.

Frequency of Reports –

c.

How frequently is the output generated? On demand? Hourly? Daily? Monthly? For scheduled outputs, when do system s need the report? Today, reports are more commonly generated by the s themselves. However, in the event that reports are to be oriented by the information services department, they must be worked into, the information systems operations schedule. For instance, a report the system needs by 9:00 A.M. on Thursday may have to be scheduled for 5:30 A.M. Thursday. No other time may be available.

Prepare Input Specification In order to design a -friendly system we should take care of the inputs to the system. Input specification consists of the formal, content and most of the input functions. i.

Format: Format determines the way of taking the input of the system. Input format should be convenient to of the system as well as to the implementer of the system. There are several ways of taking input, e.g. Text Boxes, Radio buttons, Check boxes, List boxes, Dropdown list and Combo box etc. Each of these tools has its applications with certain limitations.

ii.

Contents: These general principles should be followed for design:

–

Capture only variable data. Do not enter constant data. For instance, when deciding what elements to include in a SALES ORDER input, we need PART NUMBERS for all parts ordered. However, do we need to input PART DESCRIPTIONS for those parts? PART DESCRIPTION is probably stored in a database table. If we input PART NUMBER, we can look up PART DESCRIPTION. Permanent (or semipermanent) data should be stored in the database. Of course, inputs must be designed for maintaining those database tables.

–

Do not capture data that can be calculated or stored in computer programs. For example, if you input QUANTITY ORDERED and PRICE, you don't need to input EXTENDED PRICE, which is equal to QUANTITY ORDERED X PRICE. Another example is incorporating FEDERAL TAX

WITHHOLDING data in tables (arrays) instead of keying in that data every time. –

Use codes for appropriate attributes. Codes were introduced earlier. Codes can be translated in computer programs by using tables. Second, if source documents are used to capture data they should be easy for system s to complete and subsequently enter into the system. The following suggestions may help:

d.

–

Include instructions for completing the form. Also, that people don't like to have to read instructions printed on the back side of a form.

–

Minimize the amount of handwriting. Many people suffer from poor penmanship. The data entry clerk or CRT operator may misread the data and input incorrect data. Use check boxes wherever possible so the system only needs to check the appropriate values.

–

Data to be entered (keyed) should be sequenced so it can be read like this book, top to bottom and left to right. The data entry clerk should not have to move from right to left on a line or jump around on the form to find data items to be entered.

–

Ideally, portions of the form that are not to be input are placed in or about the lower right portion of the source document (the last portion encountered when reading top to bottom and left to right). Alternatively, this information can be placed on the back of the form.

Edit, Security & Control Specifications This includes specifying rules for edit correction, backup procedures and the controls that ensure the file integrity. i.

Edit Corrections: We should be able to edit the corrections made, i.e., we can change the corrective made later if they are proved wrong.

ii.

Backup Procedures: This is an important part of the system. We should take backup of what we have done. Backup is generally taken periodically e.g. at the end of the day, the week or the month. We design procedures to take backup of the systems. All of these backup procedures should be tested so that they will never fail.

iii.

File Integrity: We should make certain controls the checks the integrity of the file.

The controls are generally used after a transaction is made and record is modified in the file. e.

Specifies the Implementation Plan

This is the planning of the implementation of the proposed system. Implementation involves the gathering information about the organization. That is, is the organization where the system is implemented has required hardware or software? Is the staff has technical skills needed to handle the proposed system? These points should be discussed earlier so that there is no difficulty in the implementation of the system. f.

After computation of above issues, we prepare a logical design walkthrough of the information flow, output, input and implementation plan. Now we have a clear picture in mind and in documents also about the input, file, screen layouts, how data is entered, how files are accessed, how reports are produced, and how to cope up with the difficulties in implementation.

g.

Review benefits, costs target data and system constraints. This is the last phase of logical design. In this phase we review the earnings from the proposed system, and the cost of developing and implement the new system. We also see the time feasibility i.e. is it possible to develop the system within the given time limit. We identify the constraint in developing as well as in the implementation of the system. All of these points should be very clear in mind prior to developing the system.

Physical Data Files, Data Elements Data Elements Database

Physical Procedures Programs Clerical

Figure 4.3: Chart of Logical Requirements

This process involves 4 overlapping activities.

Refining the Logical Model

The logical model by this stage consists of the overall data flow diagrams, logical level data dictionary entries for each major data flow, data structure, data store, and processes. The detailed logic at this point has not been specified. Detailed data flow diagrams must be developed dealing with error and exception handling and all the other processes that have yet not been specified. The logical design also specifies input forms, screen layouts, output screen definitions, report formats etc.

Deg the Physical Data Base From the logical data store contents, the information held in the data dictionary, the designer must make a near-final commitment as to the contents and organization of the physical files and/or data base. If the system is to use an existing file or an existing database, the designer must check that the existing contents and organization are known and fit the data flows planned in the logical model.

Structure Chart Notations The following notations (illustrated in Figure below) are used in a structure chart: (i)

Rectangle: A rectangular box is used to represent a module. The module name is written inside the rectangular box.

(ii)

Arrows: They indicate the control relationships between calling and called modules with an arrow pointing towards called module. They also indicate the transfer of data or information between modules.

(iii)

Circles: Circles represent two types of data parameters - data couples and control flags. Data couples are the data items moved from one module to another. They are represented by an arrow with an empty circular tail. Control flags are the flags that assist to control the logic of the two modules. They are represented by an arrow with a filled circular tail.

(iv)

Loop: It indicates that the instructions of called module are repeated until a given condition is satisfied.

(v)

Small Diamond: A small diamond below the rectangular box indicates that one of the modules is being called depending upon the validity of given condition.

Figure 5.6: Structure Chart Notation

Strategies for Converting DFD to Structure Charts Structure charts are drawn on the basis of logical DFD. The following two strategies have been developed for converting data flow diagrams to structure charts (a)

Transform Analysis

(b)

Transaction Analysis

Generally, both strategies are used to convert DFDs to structure charts. Before discussing these strategies, let us first discuss the two types of constructs, that are used while drawing structure charts. Two such constructs are transform-centered and transaction-centered constructs. In transform-centered construct, the main module calls three types of modules, i.e., input, transform and output modules as illustrated in Figure below. Input modules send inputs to the main-module and transform modules receive these inputs and process them. The output modules receive the processed data and give output data. In transaction-centered construct, the main module calls one input, one output and one of the different transaction modules depending upon the transaction type of input module as illustrated in Figure below.

Figure 5.7: A Transform-centred Construct

Figure 5.8: A Transaction-centred Construct

Database Design As we have discussed that the organization selected for a particular file mainly depends on the nature of the application for which it will be used. Historically, Files have been designed based on specific application. Payroll files are created containing all the data pertinent to a company's payroll system. Similarly, individual files are created for use with the company's personnel, s receivable, inventory, and other systems. If the data contained on these files are not carefully delineated, it is very likely that the same data will appear on several of these files. In other words, these files would contain redundant data. For example, both a company's personnel file and payroll file could contain the name and address of each employee. This would mean that a simple change of address would have to be processed twice and possibly three or four times, depending on the number of other files on. which these data appear. Clearly, it would be more practical to have each employee's name and address on one file from which it can be accessed by all programs requiring these data. This would reduce the amount of redundant data and minimise the possibility that data contained on a file might be inaccurate because they were never updated. This is but one of the reasons that database technology was developed. A DATABASE can be thought of as a set of logically related files organised to facilitate access by one or more applications programs and to minimise data redundancy. In other words, a database can be defined as a stored collection of data, organised on the basis of relationships in the data rather than the convenience of storage structures. It is not a replacement for files. Some general objectives in establishing a database are as follows: –

Eliminate redundant data as much as possible.

–

Integrate existing data files.

–

Share data among all s.

–

Incorporate changes easily and quickly.

–

Simplify the use of data files.

–

Lower the cost of storing and retrieving data.

–

Improve accuracy and consistency.

–

Provide data security from unauthorised use.

–

Exercise central control over standards.

In addition to the database itself, a set of programs is necessary to facilitate adding new data as well as modifying and retrieving existing data within a database. This set of programs is referred to as a Data Base Management System (DBMS). A data base system merge data into one pool shared by all systems so that any change automatically affects all relevant systems. The following figures defines the difference between the traditional file systems and database management system. Figure below shows the Traditional file systems in which each system is responsible for its own data.

Figure 5.12: Traditlonal File System

Figure below shows the Data Base Management Systems in which data is centralised.

Figure 5.13: Data Base Management System

Specific advantages of data base are: 1.

File Consolidation: Pooling data reduces redundancy and inconsistency and promotes cooperation among different s. Since data bases link records together logically, a data change in one system will cascade through all the other system using the data.

2.

Program and file independence: This feature separates the definition of the files from their programs, allowing a programmer to concentrate on the logic of the program instead of precisely how to store and retrieve data.

3.

Access Versatility: s can retrieve data in many ways. They enjoy the best of both worlds - sequential access for reporting data in a prescribed order and random access for rapid retrieval of a specific record.

4.

Data Security: Usually a DBMS includes a system that controls access to sensitive data. By limiting their access to readonly, write-only, or specified records, or even fields in records, s can prevent certain s from retrieving unauthorised data.

5.

Program Development: Programmers must use standard names for data items rather than invent their own from program to program. This allows the programmer to focus on desired function.

6.

Program Maintenance: Changes and repairs to a system are relatively easy.

7.

Special Information: Special-purpose report generators can produce reports with minimum effort.

Logical and Physical view of Data In database design, several views of data must be considered along with the persons who use them. In addition to data structuring, where relationships are reflected between and within entities, we need to identify the application program's logical views of data within an overall logical data structure. The logical view is what the data look like, regardless of how they are stored. The physical view is the way data exist in physical storage. It deals with how data are stored, accessed, or related to other data in storage. There are four views of data out of which three are logical and one is physical. The logical views are the 's view, the programmer's view and the overall logical view, called a schema.

SCHEMA Once a database system has been designed, it will be possible to identify each type of data item, data aggregate, record and set by a name or code. It will be possible to state which data item types go together to make data aggregate types and record types, and to identify which record types are and owners of set types. A coded set of tables describing this information and stored in the computer system on direct access devices is called a SCHEMA. It is a description of the data structure which is separate from the data itself. The schema describes the areas, their identifiers and page sizes, and indicates how these are related to the records and sets. In other systems, a different set of tables is used for this. The schema therefore, is the view of the data, the overall logical data structure which is held by the DBMS. Each time a program requires data, the DBMS will look up in the schema for the details of the structure of the data requested. For example if the program requires an occurrence of a set, the DBMS will look up in the schema which record types are required, how to find the relevant records given a certain key by the program, and perhaps also which areas the pages containing the relevant data are stored in.

Sub-Schema In a database system, it is not always possible to allow programmers to write the data division of their choice for reasons of security or control. It is more useful to provide the programmer with a standard description of the logical data to be used in a particular application. All references to data within the program will be for this description, which is called a SUBSCHEMA and is similar to the Schema in structure. The DBMS has the job of matching data requests on a subschema and data requests based on the schema.

Types of Database In conventional file systems, groups of bytes constitute a field, one or more Fields make a record, and two or more records make a file. In a database environment, a group of bytes constitutes a data item or segment, a collection of segments a data entry, and a series of data entries a data set. The complete collection of data sets is the database itself. With traditional processing of files, records are not automatically related, so a programmer must be concerned with record relationships. Often the Files are stored and processed by record key, just as we sorted the transaction file. Data bases relate data sets in one of three models: hierarchical, network, or relational.

Hierarchical Model In a hierarchical structure, sometimes referred to as a tree structure, the stored data get more and more detailed as one branches further and further out on the tree. Each segment, or node, may be subdivided into two or more subordinate nodes, which can be further subdivided into two or more additional nodes. However, each node can have only one "parent" from which it emanates. The Figure below shows the hierarchical structure.

Figure 5.14: Hierarchical Structure

Network Model The network related data sets are similar to hierarchical ones, except that a node may have more than one parent. Thus a hierarchical DBMS is a subset of network DBMS. The trade off between the simplicity of design of a hierarchical structure and the storage efficiency of a network structure is a very important consideration in database implementation. The Figure below shows the Network structure.

Figure 5.15: Network Structure

Relational Model The relational structure, however, organises the data in of two dimensional tables. That is. Relational data sets order data in a table of rows and columns and differ markedly from their hierarchical or network counterparts. "There are no parent or node data sets as shown in Fig. 1.8. In a relational database management systems, we have the same concept of files, records, and Fields. Files are represented by two-dimensional tables, each of which is called a "relation". Records, which can be visualized as rows in the table, are called "Tuples". Fields can be visualised as columns, and are called by attribute names, or domains. For example, note that in the supplier table in Figure below we have three Tuples, or rows, and three attribute names or columns. If we need to know the name of the supplier of blue chairs, the relational DBMS searches the type and color columns of the Furniture, Table and Finds supplier number 30, and then it scans the supplier table for number 30, which turns out to be PANKAJ'S. Since each "record" is a row in the table and each "Field" a column, an inventory system of 1600 Tuples, each with 5 attributes, would create a table of 1600 rows and 5 columns.

Figure 5.16: Relational Structure

A relational DBMS can perform the following basic operations:

–

create or delete tables

–

update, insert, or delete rows

–

add or delete columns

–

copy data from one table into another

–

retrieve or query a table, row or column

–

print, recognize, or read a table or row

–

or combine tables based on a value in a table.

Since the relational structure organises the data in of two dimensional tables, they offer great flexibility and a high degree of data security. The relational structure uses relatively little memory or secondary storage. Unfortunately, the process of creating the tables is a rather elaborate procedure. Another disadvantage of this structure is that it generally requires more time to access information than either of the other two structures. This is because much more information must be searched in order to answer queries posed to the systems. In addition, some implementation use a fixed amount of storage for each field, resulting in insufficient storage utilisation. In spite of these disadvantages, the relational structure has gained rapid acceptance and is currently the most popular of the three structures. Many experts predict that it will eventually replace the others completely.

Levels of Data Independence The data independence may be of the following two levels: (a)

Physical Data Independence: If the data is designed in such a way that the physical storage techniques of the data can be changed without changing the application programs then this level of data independence is called as physical data independence.

(b)

Logical Data Independence: If the database is organised in such a way that the logical structure can be changed without changing the application program then this level of data independence is called as logical data independence.

Reasons for Data Independence Why the data independence is required? It is mainly due to the following two reasons: (1)

The development of one application is generally very expensive and time consuming. Therefore, the application should be developed considering the possibility of changes required in specifications of reports or queries in future. Hence, if the database is application independent, then there would not be any need to modify the application programs in future and hence will save time and money of the organisation.

(2)

The requirement of queries or reports may be changed in future depending upon different applications. If the database is application independent, then the data can be stored in one particular

representation (e.g. say in binary) but can be viewed in another representation (say in decimal). Sometimes the units of numeric data can also be changed in future (say from centimeters to inches). So, there are a lot of possibilities of modification of specifications given by organisation in future. Therefore, the data independence concept is ideal for such applications.

Conversion Methods/ Installation Methods Conversion is the process of changing from the old system to the new one. It must be properly planned and executed. Four methods are common in use. They are: parallel systems, direct conversion, pilot system and systems phase-in. Each method should be considered in the light of the opportunities that it offers and problems that it may create. However, it may be possible that sometimes, we may be forced to apply one method over others, even though other methods may be more beneficial. In general, systems conversion should be accomplished in shortest possible time. Long conversion periods create problems for all persons involved including both analysts and s.

Parallel Systems The most secure method of converting from an old to new system is to run both systems in parallel. Under this approach, s continue to operate the old system in the usual manner but they also start using the new system. This method is the safest one because it ensures that in case of any problems in using the new system, the organisation can still fall back to the old system without loss of time and money. The disadvantages of the parallel systems approach are: 

It doubles operating costs



The new system may not get fair trial.

Direct Conversion This method converts from the old to the new system abruptly, sometimes over a weekend ( even overnight. The old system is used until a planned conversion day, when it is replaced by the new system. There are no parallel activities. The organisation relies fully on the new system. The main disadvantages of this approach are: no other system to fall back on, if difficulties arise with new system. Secondly, wise and careful planning is required.

Pilot System Pilot approach is often preferred in the case of the new system which involves new techniques or some drastic changes in organisation performance. In this method, a working version of the system is

implemented in one part of the organisation, such as a single work area or department. The s in this area are aware that they are piloting a new system and that changes can be made to improve the system. Based on the , changes are made and the system is installed in the remaining departments of the organisation, either all at on (direct conversion method) or gradually (phase-in method). This approach provides experience and live test before implementation.

Phase-in Method This method is used when it is not possible to install a new system throughout an organisation all at once. The conversion of files, training of personnel or arrival of equipment may force the staging of the implementation over a period of time, ranging from weeks to months. It allows some s to take advantage of the new system early. Also it allows training and installation without unnecessary use of resources.

Hardware Acquisitions Once a decision has been reached to install an in-house computing device, the next step is to prepare a list of specifications of the proposed system so that suitable vendors would be invited for meeting the specific requirements. The tender specifications are prepared as per norms of approved feasibility report. Main technical parameters of the various units of the required hardware objectives of the project and implementation schedule are also included in the tender specifications. Vendors may also be asked to quote separately in respect of leasing' and 'buying' options. In addition to this, the vendors may be required to furnish the details of the infrastructure which the customer will have to arrange.

Tender Evaluations It is often seen that requirements as indicated by the customer do not match with the offer made by individual vendors where the specification given by the vendors are far below the essential requirements of the customers, such offers may be rejected straightway from the purview of short listing. Marginal shortfalls may be considered on merits. However, in case of additional features in the offers which could be categorised as 'desirable', it becomes necessary to assign appropriate weights to such features, in order to bring all the bids on equal footing. The additional features include quantifiable differences are: 

One time costs as well as in the continually running and maintenance costs.



Equipment characteristics such as storage capacities, speeds of various units of computing device.



In-built spare capacity as well as capability of the system to additional peripherals.



Additional to be provided by the vendor.

Costing Factor Cost consideration is quite important factor in computer acquisitions. Costs are of two types: (i)

One-time costs such as post of site preparation (space, false ceilings, special floorings, electrical fittings, air- conditioning etc.)

(ii)

Continued running and maintenance costs of the entire installations.

Equipment Characteristics Hardware device which provides higher transfer rates (that is arrange number of bytes ing between various functional units per unit of time), or has large storage capacity or in case of printers, if the printed characters per line are quite high, then such additional characteristics get entitled to weightage to the extent of their practical utility to the buying organisation. Appropriate weightage can also be given to such characteristics as high mean-time-between-failures (MTBF), compatibility with the equipment, peripherals etc. available in the market

Potential for Growth Following features can be considered in this category: 

Potentiality of the system to grow beyond the currently specified capacity by adding on certain components,



Potentiality of growth within a particular family of computer models,



Capacity of the system to handle a large variety of peripherals,



Ability of the system to handle considering the peak hour load.

additional

workloads

after

Vendor The features to be given weightage under the vendor include: 

hardware maintenance facilities offered.



training facilities provided.



assistance to be provided in software development



back-up facilities provided by vendor in case of system failure



comparative delivery periods offered by different vendors.

Service Suppliers Outside computer services are commonly used by small firms or first time s. Also called ‘Services’ they include the following:-

1.

Computer manufacturers supply services such as system design, programming, education and training and hardware maintenance.

2.

Service bureaus run “bread and butter” applications for small firms. Larger firms contract for specialised applications or for running jobs during peak volume periods. The primary services are programming, file and system conversions, system design and training.

3.

Facilities management (FM) furnishes specialists to manage a installed computer on the s premises. In some cases service is limited to developing application programs. The runs the system but calls on the service organisation for developmental work and maintenance.

The FM concept has several benefits. The pays only for the service rendered. Turnover problems for the are eliminated when the service manages the centre. The main drawbacks, however, are loss of control over the operation, valuerability of information, and the high fees charged for the service.

Evaluation and Validation The evaluation phase ranks vendor proposals and determines the one best suited to the ’s needs. It looks into items such as price, availability, and technical . System validation ensures that the vendor can, infact, match his/her claims, especially system performance. True validation is verified by having each system demonstrated.

Role of Consultant For a small firm, an analysis of competitive bids can be confusing. For this reason, the may wish to contract on outside consultant to do the job. Consultants provide expertise and an objective opinion. A recent survey found, however, that 50 percent of respondent s had an unfavourable experience with the consultants they hired, and 25 percent said they would never hire another consultant. With such findings, a decision to use consultants should be based on careful selection and planning. A rule of thumb is that the larger the acquisition the more serious should be the consideration of using professional help. Although the payoffs from using consulting services costs are also high for many small companies that acquisition, for them, consulting services may be During 1984, the average rates of consultants were not including travel and out-of-pocket expenses.

can be dramatic, the are exploring system totally out of reach. $600 - $1,800 a day,

The past decade has seen the growth of internal management consultant in large organisations as opposed to external consulting teams. The figure below outlines the cases where an external or internal consultant is appropriate. Pros and Cons of Using Consultants External Consultant

Internal Consultant

Full-time internal consultant is not needed or is beyond the budget of the organisation.

An outside consultant is too costly; internal consultants can be much chapter.

Extra help on a project is needed for a short time, and internal person cannot afford the time.

A fast decision necessitates using an internal consultant.

The internal staff does not possess the expertise or broad knowledge needed for a specific situation.

An external consultant often does not understand the nature of the internal problem.

The political nature of the problem requires an objective, neutral opinion.

An internal consultant already exists who has an objective and technical understanding.

An outside opinion is desired in addition to that of the internal consultant.

An inside opinion is desired in addition to that of the external consultant.

Criteria for Vendor’s Selection Mandatory requirement is that, if a vendor fails to meet them, he would be screened out without any reason. The desirable characteristics would surely be little bit difficult to evaluate because he may offer several alternatives in lieu of them. The criteria of vendor selection may be listed in descending order by importance as below:

Economic Factors 

Cost comparisons



Return on investment



Acquisition method

Hardware Factors 

Hardware performance and its reliability



Facilities for back up facilities



Provision for back up facilities



Firmness of delivery data



Compatibility with existing systems



Expandability

Software Factors 

Performance of software and its price



Efficiency and reliability of available software



Programming languages available



Availability of well documented package programs



Firmness of delivery date for a promised software



Ease of use and modification as per requirements



Portability and its capacity to interface with the environment.

Service Factors



Facilities provided by the manufacturer for detecting errors in the new programs



Providing of good training facilities



Assistance in software development and conversion facilities provided



Maintenance and quality

Reputation of Manufacturer 

Financial stability



Past history for keeping promises

Three criteria may have to be further sub-divided particularly for hardware performance and services.

Software Selection Software selection is a critical aspect of system development. As mentioned earlier, the search starts with the software, followed by the hardware. There are two ways of acquiring software: custom-made or "offthe-shelf packages. Today's trend is toward purchasing packages, which represent roughly 10 percent of what is costs to develop the same in house. In addition to reduced cost, there are other advantages: 1.

A good package can get the system running in a matter of days rather than the weeks or months required for "home-grown" packages.

2.

MIS personnel are released for other projects.

3.

Packages are generally reliable and perform according to stated documentation.

4.

Minimum risks are usually associated with large-scale systems and programming efforts.

5.

Delays in completing software projects in house often occur because programmers quit 'n midstream.

6.

It is difficult to predict the cost of "home-grown" software.

7.

The has a chance of seeing how well the package performs before purchasing it.

There are drawbacks, however, to software packages: 1.

The package may not meet requirements adequately.

2.

Extensive modification of a package usually results in loss of the vendor .

3.

The methodology for package evaluation and selection is often poorly defined. The result is a haphazard review based on a faulty process or questionable selection criteria.

4.

For first-time software package s, the overall expectation from package is often unclear and ill defined.

It can be seen, then, that the quality of a software package cannot be determined by price alone. A systematic review is crucial.

Criteria for Software Selection Prior to selecting the software, the project team must set up criteria for selection. Selection criteria fall into the categories described here.

Reliability It is the probability that the software will execute for specified time period without a failure, weighted by the cost to the of each failure encountered. It relates to the ease of recovery and ability to give consistent results. Reliability is particularly important to the profession.

s For example, a pharmacist relies on past files on patients when filling prescriptions. Information accuracy is crucial. Hardware may become inoperative-because of design errors, manufacturing errors, or deterioration caused by heat, humidity, friction, and the like. In contrast, software does not fail or wear out. Any reliability problems are attributable to errors introduced during the production process. Furthermore, whereas hardware failure is based lately on random failures software reliability is based on predestined errors. Although reliable software is a desirable goal, limited progress has been made toward improving it in the last decade. The fact of unreliable software had led to the practice of securing maintenance agreements after the package is in operation. In a sense, unreliability is rewarded. Software reliability brings up the concept of modularity, or the ease with which a package can be modified. This depends on whether the package was originally designed as a package or was retrofitted after its original development for single installation use. A package with a high degree modularity has the capacity to operate in many machine configurations and perhaps across manufacturers' product lines With modularity comes expandability, which emphasizes the sensitivity of a software package to handle an increased volume of transactions or to integrate with other programs. The following questions should be considered: 1.

Is there room for expanding the master file?

2.

How easily can additional fields, records, and files be added?

3.

How much of the system becomes unusable when a part of it fails'.

4.

Are there errors a can make that will bring down the system?

5.

What are the recovery capabilities?

Functionality

It is a definition of the facilities, performance, and. Other factors that the requires in the finished product. All such information comes from the . The following are key questions to consider 1.

Do the input transactions, files, and reports contain the necessary data elements?

2.

Are all the necessary computations and processing performed according to specifications?

Capacity Capacity refers to the capability of the software package to handle the 's requirements for size of files, number of data elements volume of transactions and reports, and number of occurrences of data elements. All limitations should be checked,

Flexibility It is a measure of the effort required to modify an operational program. One feature of flexibility is adaptability, which is a measure of the ease of extending the product.

Usability This criterion refers to the effort required to operate, prepare the input, and interpret the output of a program. Additional points to be considered are portability and understandability. Portability refers to the ability of the software to be used on different hardware and operating systems. Understandability means that the purpose of the product is clear to the evaluator and that the package is clearly and simply written, is free of jargon, and contains sufficient references to readily available documents so that the reader can comprehend advanced contents. that the reader can comprehend advanced contents.

Security It is a measure of the likelihood that a system's can accidentally or intentionally access or destroy unauthorized data. A key question is: How well can one control access of software or data files? Control provides system integrity.

Performance It is a measure of the capacity of the software package to do what it is expected to do. This criterion focuses on throughput, or how effectively a package performs under peak loads. Each package should the evaluated for acceptance on the 's system. The language in which a package is written and the operating system and additional performance considerations. If we plan to modify or extend a package, it is easier if it is written in a language that is commonly known to programmers. Likewise, if the package runs only under a disk operating system and the installation is under a full operating system, then either

the package will have to be upgraded to the larger operating system or the system downgraded to handle the package as is. In either case, the change could be costly and counterproductive.

Serviceability This criterion focuses on documentation and vendor . Complete documentation is critical for software enhancement. It includes a narrative description of the system, system logic and logic flowcharts, input-output and file descriptions and layouts, and operator instructions. Vendor assures the adequate technical for software installation, enhancements, and maintenance. The should determine how much on-site technical assistance is provided by the vendor, especially during the first few weeks after the installation. The expects on-site training and as part of most commercial packages. It is vital to inquire about the amount of training provided. The may require training at several levels—clerical, operations, programming, and management.

Ownership Who owns the software once it is "sold" to the ? Most of the standard license agreement forms essentially lease the software to the for an indefinite time. The does not "own" it, which means that the source code is inaccessible for modification, except by the vendor. Many s enter into an escrow arrangement whereby the vendor deposits the source code with a third-party escrow agent who agrees to release the code to the if the vendor goes out of business or is unable to perform the services specified in the license. In acquiring software, several questions should be asked: Criterion

Meaning

1. Reliability

Gives consistent results

2. Functionality

Functions to standards

3. Capacity

Satisfies volume requirements

4. Flexibility

Adapts to changing needs

5. Usability

Easy to operate and understand-usually-friendly

6. Security

Maintains access

7. Performance

Capacity to deliver as expected

8. Serviceability

Good documentation and vendor

9. Ownership

Right to modify and share use of package

10. Minimal costs

Affordable for intended application.

1.

What rights to the software is the buying?

2.

Can the sell or modify the software?

integrity

and

prevents

unauthorized

3.

If the vendor is modifying the package especially for the , can the vendor sell it to others within the same industry the is in?

4.

What restrictions documentation?"

are

there

to

copying

the

software

or

Minimal Costs Cost is a major consideration in deciding between in-house and vendor software. Cost-conscious s consider the following points: 1.

Development and conversion costs.

2.

Delivery schedule.

3.

Cost and frequency of software modifications.

4.

Usable life span of the package.

Design of Input The input design is the link that ties the information system into the world of its s. Input specifications describe the manner in which data enters the system for processing. Input design features can ensure the reliability of the system and produce results from accurate data, or they can result in the production of erroneous information. Input design consists of developing specifications and procedures for data preparation steps necessary to put transaction data into a usable form for processing data entry, the activity of putting data into the computer for processing

Objectives of Input Design Five objectives guiding the design of input focus on 

Controlling the amount of input required



Avoiding delay



Avoiding errors in data



Avoiding extra steps



Keeping the process simple

Forms Requirements Design We have learned that data provide the basis for information systems} Without data there is no system, but data must be provided in the right form for input and the information produced must be in a format acceptable to the . In either case, it is still data-the basic element of a printed form.

What is a Form? People read from forms, write on forms, and spend billions of hours handling forms and filing forms. The data the forms carry come from people, and the informational output of the system goes to people. So the form is a tool with a message; it is the physical carrier of data-of information. It also can constitute authority for action. For example, a purchase order says BUY, a customer's order says SHIP, and a paycheck says PAY TO THE ORDER OF. Each form is a request for action. It provides information for making decisions and improving operations. With this in mind, it is hard to imagine a business operating without using forms. They are the vehicles for most communications and the blue-print for many activities. As important as a printed form is, however, the majority of forms are designed by poorly trained people. People are puzzled by confusing forms they ask for directions on how to read them and how to fill them out. When a form is poorly designed, it is a poor (and costly) istrative tool.

Classification of Forms A printed form is generally classified by what it does in the system. There are three primary classifications: action, memory, and report forms. An action form requests the to do something-get action. (Examples are' purchase orders and shop orders.! A memory form is a record of historical data that remains in a file, is used for reference, and serves as control on key details. (Examples are inventory records, purchase records, and bond s.! A report form guides supervisors and other s in their activities. It provides data on a project or a job.

Figure 4.4: Different Types of Forms

Requirements of Forms Design Forms design follows analyzing forms, evaluating present documents, and creating new or improved forms. Bear in mind that detailed analysis occurs only after the problem definition stage and the beginning of deg the candidate system. Since the purpose of a form is to communicate effectively through forms design, there are several major requirements: 1.

Identification and wording. The form title must clearly identify its purpose. Columns and rows should be labeled to avoid confusion. The form should also be identified by form name or code number to make it easy to reorder.

2.

Maximum readability and use. The form must be easy to use and fill out. It should be legible, intelligible, and uncomplicated. Ample writing space must be provided for inserting data. This means analyzing for adequate space and balancing the overall form’s layout, istration, and use.

3.

Physical factors. The form's composition, color, layout (margins, space, etc.), and paper stock should lend themselves to easy reading. Pages should be numbered when multipage reports are being generated for the .

4.

Order of data items. The data requested should reflect a logical sequence. Related data should be in adjacent positions. Data copied from source documents should be in the same sequence on both forms. Much of this design takes place in the forms analysis phase.

5.

Ease of data entry. If used for data entry, the form should have field positions indicated under each column of data and should have some indication of where decimal points are (use broken vertical lines).

6.

Size and arrangement. The form must be easily stored and filed. It should provide for signatures. Important items must be in a prominent location on the form.

7.

Use of instructions. The instructions that accompany a form should clearly show how it is used and handled.

8.

Efficiency considerations. The form must be cost effective. This means eliminating unnecessary data and facilitating reading lines across the form. To illustrate, if a poorly designed form causes 10 supervisors to waste 30 seconds each, then 5 minutes are lost because of the form. If (the firm uses 10,000 of these forms per year, then 833 hours of lost time could have been saved by a better forms design.

9.

Type of report. Forms design should also consider whether the content is executive summary, intem1ediate managerial information, oring-data. The requirements for each type often detem1ine the final form design.

Form Control The first step in tonus control is to determine whether a, form is necessary, Managing the hundreds of tonus in a typical organization requires a forms control program. Forms control is a procedure for (1) providing improved and effective forms (2) reducing printing costs, and (3) securing adequate stock at all times. The first step in a procedure for forms control is to collect group, index, stock, and control the tonus of the organization. Each form is identified and' classified by the function it pelf onus and whether it is a flat form, a snap-out form, or something else. Once classified, a form is evaluated by the data it requires, where it is used, and how much it overlaps with other forms. The object is to get rid of unnecessary tonus and improve those forms that are necessary. Before launching a tonus control program, the designer needs to consider several questions:

1.

Who will be responsible for improving tonus design?

2.

Should forms be produced in house or assigned10 an outside printer?

3.

What quantity should be printed? What is the break-even point on printing forms?

4.

How much lead time is required to replenish forms?

5.

How will one handle reorders? Who will initiate them? In what way?

6.

How will obsolete forms be handled?

7.

What should be the life of the form?

8.

Where and how should the forms be stored?

If questions of this nature are not addressed in advance, the organization is probably not ready to launch a tonus control program.

Input Stages Several activities have to be carried out as part of the overall input process. They include some or all of t following: 

data recording (i.e., collection of data at its source):



data transcription (i.e., transfer of data to an input form);



data conversion (i.e., conversion of the input data to a computer acceptable medium);



data verification (i.e. checking the conversion);



data control (i.e. checking the accuracy and controlling the flow of the data to the computer);



data transmission (i.e. transmitting or transporting the data to the computer);



data validation (i.e. checking the input data by a program when it enters the computer system)



data correction (i.e. correcting the errors that are found in any of the earlier stages).

Input Media Once the input types and their contents have been examined the analyst can start to think about input devices of which there is a very wide range. Much careful thought has to be given to the choice of the input media and devices. Consideration can be given to: 

type of input



flexibility of format



speed



they -accuracy



verification methods



rejection rates



ease of correction



off-line facilities



need for specialised documentation



storage and handling requirements



automatic features



hard copy requirements



security



ease of use



environment of data capture



portability



compatibility with other systems



cost

Avoiding Errors in Data Every effort must be made to ensure that input data remains accurate from the stage at which it is recorded and documented to the stage at which it is accepted by the computer. This can only be achieved by careful control each time data is handled, The rate at which errors occur depends on the quantity of data, since the smaller the amount of data to input, of the fewer the opportunities for errors. Poor form design can lead to a 

Misunderstanding of the instructions



Insufficient space to write clearly.

The effectiveness of checking data by verification or sight-checking can only be assessed by keeping individual records of the preparations of the input data and 'tracing' errors which are subsequently found by the computer or even later in the system, back to their source.

CRT Screen Design Many online data entry devices are CRT screens that provide instant visual verification of input data and a means of prompting the operator. The operator can make any changes desired before the data go to the system for processing. A CRT screen is actually a display station that has a buffer (memory) for storing data. A common size display is 24 rows of 80 characters each or 1,920 characters. There are two approaches to deg data on CRT screens: manual and software utility methods. The manual method uses a work sheet much like a print layout chart. The menu or data to be displayed are blocked out in the areas reserved on the chart and then they are incorporated into the

system to formalize data entry. For example, we use dBASE II software commands to display a menu on the screen. The first command in the partial program is interpreted by the, system as follows: "Go to row 10 and column 10 on the screen and display (SAY) the statement typed between quotes. The same applies to. the next three commands, The command "WAIT TO A" tells the system to keep the menu on the screen until the operator types the option next to the word "WAITING," The main objective of screen display design is simplicity for accurate and quick data capture or entry. Other guidelines are: 1.

Use the same format throughout the project.

2.

Allow ample space for the data. Overcrowding causes eye strain and may tax the interest of the .

3.

Use easy-to-learn and consistent , such as "add," "delete," and "create."

4.

Provide help or tutorial for technical or procedures.

The second approach to deg screen layouts is through software utility, usually provided by the CRT vendor. For example, IBM provides a Screen Design Aid (SDA) package that allows the designer (at the terminal) to modify the display components.

Figure 4.5: The CRT Design

In online applications, information is displayed on the screen. The layout sheet for displayed output is similar to the layout chal1 used for deg input. Areas for displaying the information are blocked out, leaving the rest of the screen blank or for system status information. Allowing the

to review sample screens can be extremely important because the is the ultimate judge of the quality of the output and, in turn, the success (or failure) of the system. For example, the following shows editing output for a student birth date. Display: DATE OF BIRTH (mm/dd/yy) 23/19/80 RESPONSE: MONTH EXCEEDS 12 SUGGESTS A RETRY: DATE OF BIRTH (mm/dd/yy)