Business Plan

System Analysis & Design
KSOU
1
E E -1 R e c o r d C lu b M em ber
o rd e r
V e r if y m e m b e r s ta tu s O R C le r k
m em ber d a ta
D -1
M e m b e r M a s te r
E E -2 C u s to m e r (n o n -m e m b e r)
m em ber o rd e r
n o n -m e m b e r o rd e r a n d a p p lic a t io n f o r m
2 V e r if y o r d e r it e m d a t a O R C le r k
v e r if ie d m em ber o rd e r
it e m d a ta
D -2
Ite m M a s te r
3 E n te r o rd e r in t o D a i ly O rd ers O R C le r k
o rd e r d a ta
o rd e r
D -3
D a ily O r d e r s D e t a il
4 P r i n t in v o ic e and s h i p p in g li s t O R C le r k
in v o ic e a n d s h ip p in g lis t E E -3 O rd e r F u lf illm e n t
1
o rd e r
m em ber d a ta
D -1
m em ber o rd e r -1-
it e m d a t a O R C le r k
System Analysis & Design v e r if ie d m em ber 1 o rd e r
o rd e r
d a ta
D -2
Ite m M a s te r
KSOU
V e r if y m e m b e r 3 s ta tu s
m em ber d a ta
D -1
E On tRe r C o ler dr ke r in t o D a ily O rd ers O R C le r k

m em ber o rd e r
o rd e r
D -3
D a ily O r d e r s D e t a il
2 V e r if y o r d e r it e m d a t a O R C le r k
it e m d a ta
D -2 Ite m M a s te r
1
o rd e r
m em ber d a ta
D -1
1
o rd e r
m em ber d a ta
D -1
SYSTEM ANALYSIS AND DESIGN

-2-
KSOU
Course Objective
The overriding objective of the course is to provide students exposure to the theory of systems analysis and design. It describes fundamental concepts and trends that provide the context of Systems Analysis and Design methods. After successfully completing the course, students will have the following abilities to describe the different major approaches to systems analysis and design and ability to describe the tools used in systems analysis and design and the management of these analysis and design projects.
Module 1
Unit 1 - Data and Information: Distinction between Data and Information, Types of data, Types of Information, Characteristics of information, Attributes of information quality. Unit 2 - Systems Concepts: Definition, Characteristics of a system: organization, Interaction, Interdependence, Integration, Central objective. Elements of systems: Inputs, outputs, Processes, Control, Feedback, Environment, Boundaries and Interface, Types of system: Physical or Abstract, Open or closed system. Unit 3 - Information systems: What is an information system?, Trends in Information system, Information system resources, Types of Information system: Operation support and Management support.
Module 2
Unit 4 - System Development Life Cycle: What is system development, beginning of system development, system development methodology. Steps in system development life cycle: Preliminary Investigation , Requirements analysis or system analysis , Design of System, Development of Software, System Testing , Implementation and Maintenance . Unit 5 - Feasibility Analysis: Steps in feasibility Analysis, Types of feasibility studies, Case Study on identifying and examining alternative solutions Unit 6 System Analyst: Who is a system analyst?, Roles of system analyst: Change agent, Investigator & Monitor, Architect, Psychologist, Salesperson, Motivator, Information system resources, System analyst skill sets: Technical, Managerial, Communication and analytical.
-3-
KSOU
-4-
KSOU
Module 3
Unit 7 - Information Gathering Techniques 1: Sampling & Investigation, Interviewing: Kinds of information sought, Interview plan, Interview conduction, Interview report. Unit 8 Information Gathering Techniques 2: Questionnaires: Kinds of information sought, Different Scales in Questionnaires, Using questionnaires, Onsite observation: Observing the Organizations Environment Unit 9 Information Gathering Technique 3: Prototyping: Prototyping approaches, Prototype development, Users Involvement in Prototyping. Advantages and disadvantages of different information gathering techniques.
Module 4
Unit 10 System Analysis Tools 1: Data Flow Diagrams: Data Flow diagrams, DFD Symbols, Logical and physical DFDs, Leveling or decomposition of DFD, Guidelines for drawing DFDs, Rules for stopping decomposition. Unit 11 System Analysis Tools 2: Case Studies on DFDs: Order Processing System, Food ordering system, Travel Agency, Online university registration, A Real Estate Inc (AREI). Unit 12 System Analysis Tools 3: Data Dictionary: Data repository, creating and using data dictionaries, Making Structured Decisions: Structured English, Decision tree, Decision tables.
Module 5
Unit 13 Input Design: Data processing, Input implementation methods A taxonomy, Input design objectives & guidelines, Form design, Screen design, GUI controls, Extending input design to web, Input controls, Tools for input design and prototyping. Unit 14 Output Design: Types of outputs: Internal, external and turnaround, Output implementation methods A taxonomy, Output design guidelines, Output Bias, Report design, Screen output design, Extending output design to web. Unit 15 Database or file Design: Database design objectives, Conventional files and databases, Data concepts, Database design guidelines.
-5-
KSOU
Module 6
Unit 16 System Design: System design, Logical and physical design, System design elements, Structured design, System design approaches: Modern structured designStructure charts, JAD, RAD, Object oriented design, Information engineering. Unit 17 Project Management: What is project management?, Project management functions, Project management tools and techniques: Gantt chart, Bar Chart, WBS and PERT. Unit 18 Quality Assurance: Quality Assurance Definition, Approaches to quality, Total quality management, Testing, maintenance and auditing.
UNIT 1
DATA AND INFORMATION
Data
Data refers to a set of discrete objective facts about an event or a process. Data may be numerical quantities or other attributes derived from observation, experiment, or calculation. The term data is derived from the Latin word datum which means "that which is given" Data is often viewed as a lowest level of abstraction from which information and (or) knowledge is derived. Data has no significance beyond its existence. Data can be meaningful only when a human or a machine interprets its context.
Some of the characteristics of data are: Data represents unorganized and unprocessed facts Usually data is static in nature. It can represent a set of discrete facts about events. Data is a prerequisite to information.
Types of data
Data can be classified into different types. The following table 1.1 illustrates some of the commonly used types of data.
-6-
KSOU
Data Alphanumeric data Image data Audio data Video data
Represented by Numbers, letters, and other characters Graphic images or pictures Sound, noise, tones Moving images or pictures
Table 1.1 Types of data
Information
Information is a collection of facts organized in such a way that they have additional value beyond the value of the facts themselves. Information is data that has been interpreted or processed so that it has meaning for the user. In simpler terms, data endowed with relevance and purpose is information. For instance consider the following set of numbers 16.0, 17.0, 16.0, 18.5, 17.0,15.5, etc. What does the set convey? A students of a deemed university may consider it as his /her Continuous Internal Evaluation marks. A doctor may treat it as thermometer reading of temperature a patient. A programmer may treat it as output or set of real numbers which are input of /to his /her program. A researcher visualizes it as set of simulated data obtained through his /her experiment or simulation. Thus the interpretation differs from person to person with respect to a particular context. However, if we say the temperature a patient taken every two hour 16.0, 17.0, 16.0, 18.5, 17.0,15.5 then it is information. Anyone who visualizes this information cannot interpret in any other way. Similarly consider another example it is raining. Even this is a data because it doesnt convey the cause and effect. But the temperature dropped 15 degrees and then it started raining, is information as it embodies the cause and effect of that cause.
-7-
KSOU
Converting data into information Data becomes information when it is processed. For example, consider a marketing company, set of raw sales figures is data. The sales manager may need to analyze the sales performance of each region thereby solving the problem of poor sales in one region or deciding the future focus of a sales drive. Therefore, the raw data needs to be processed into a sales report, which provides information.
Data
Transformation
Fig 1.1 Process of converting data to information
Information
The following table illustrates how the huge amount of data that manager may receive could be processed to create useful information. Data Financial performance Sales figures Market and competition data Production output Costs of resources or other inputs Possible methods of converting data into information Present complex data as a chart or graph Plot charts and identify trends Find average or typical values Monitor changes over time and forecast future values Compare figures and identify similarities or differences
Table 1.2 Converting data to information
Note: Collecting data is an expensive process. To merit the effort, one needs to be very clear about why you need it. Proper planning must be done so that only required data is obtained for processing and usage. For organizations, the key reason behind collection of data is to monitor and improve performance. Some of the important guidelines for data collection include
-8-
KSOU
Collect data on the indicators that really do affect performance Collect data from reliable sources Collect data, which can be converted into information.
Characteristics of information
Information must posses the following characteristics for it to be useful and qualitative in nature. These include: Completeness Accuracy Timeliness Consistency Validity Appropriateness Relevance Usability Accessibility
-9-
KSOU
Completeness Information must be complete, else it leads to incorrect decision-making.
Accuracy Accurate information is the best kind of information. Accurate information is one, which is reliable and from a correct source. Timeliness "Timely" means, "appearing at the right moment. Information needs to be available when it's needed. Also, information needs to be up-to-date. Consistency The source of information should not change at different places, or contradicts itself. It is the sign that it is untrustworthy. Validity To be valuable, information should be unbiased, representative and verifiable. If information neglects key topics or issues, it might not represent the full knowledge base you need to know. If information cannot be independently verified, it should be treated with utmost caution. Appropriateness Information should be presented in a way that is meaningful, relevant and formatted to suit the users needs Relevance
- 10 -
KSOU
The Information should be relevant to the user quires. Information is not universally relevant and valuable, it is valuable and relevant only to a person who needs it and can use it. Usability The information has to be presented to the users to understand and explore it during decision-making activities.
- 11 -
KSOU
Accessibility Up-to-date information should be accessible at any time to authorized or relevant users only.
Knowledge
Knowledge is a subset of information. It is a subset that has been extracted, filtered, or formatted in a very special way. More specifically, knowledge is information that has been subjected to and passed tests of validation. For instance, scientific knowledge is information i.e hypotheses and theories validated by the rules and tests applied to it by some scientific community. Organizational knowledge is information validated by the rules and tests of the organization seeking knowledge. The quality of the knowledge depends on the tendency of validation rules and tests to produce knowledge that improves organizational performance. In simpler terms, knowledge is a combination of information, experience and insight that may benefit the individual or the organization. Knowledge is based on information that is organized, synthesized, or summarized to enhance comprehension, awareness, or understanding. Knowledge represents a state or potential for action and decisions in a person, organization or a group. It could be changed in the process of learning, which causes changes in understanding, decision or action. Types of Knowledge There are two kinds of knowledge namely, explicit and tacit. Formal, explicit or generally available knowledge. This is knowledge which can be captured, articulated in formal language / records and transmitted among individuals of the organization. Example of such knowledge includes policies and operating procedures of a firm.
- 12 -
KSOU
Instinctive, subconscious, tacit or hidden knowledge. personal knowledge embedded in individuals based on their experience and involving such intangible factors as personal belief, perspective, and values.
applied for build and
Data
Fig 1.2 From data
a purpose
Information
to information to
process
Knowledge
knowledge
Converting information to knowledge The tremendous amount of information that is generated is only useful if it can be applied to create knowledge within the organization. Building and managing knowledge is one of the greatest challenges that the organizations are facing. Figure 1.2 illustrates the process of information conversion into knowledge.
- 13 -
KSOU
UNIT 2
SYSTEMS CONCEPTS
Learning Objectives: This unit gives a brief overview of general system concepts such as Definition of system, Characteristics of a system namely, organization, Interaction, Interdependence, Integration, Central objective. Later part concentrates on elements of systems namely input, output, process, control & feedback, environment, boundaries and interface. The different types of system, physical or abstract, open or closed system is also delt.
Definition of System
A system is a set of elements or components that interact to accomplish goals. The term System is derived from the Greek word systma which means a set of interacting or interdependent entities, real or abstract, forming an integrated whole. In simpler terms, a system is an organized relationship among functioning units or components. With reference to a business organization system or specifically a business system is a group of interrelated procedures used for a business function, with an identifiable boundary, working together for some purpose.
A system can be defined in many ways. Some of these include: A regularly interacting or interdependent group of items forming a unified whole. An organized set of doctrines, ideas, or principles, usually intended to explain the arrangements or working of a systematic whole. An organized or established procedure. An organized society or social situation regarded as stultifying establishment. A System is a set of related components that produces specific results. An organization consisting of interrelated departments or subsystems for carrying out specific business objectives is a business system.
System Concept Implications

- 14 -
KSOU
We can observe three implications from the concept of system. They are: A system must be designed to achieve some set objectives. Interrelationships & interdependence must exist among the components of the system. The objectives of the organization i.e the system must have a higher priority than that of the subsystems.
Characteristics of a system
Systems have five important characteristics namely organization, interaction, interdependence, integration and central objective. Organization The term organization here implies to the structure & order of the system. It can be viewed as the arrangement of components that help to achieve the goals and objectives. It is a collection of one or more subsystems. Interaction A system many have many subsystems / components. The way in which each component functions with other components is called interaction. For instance, consider a Manufacturing firm, the sales unit must interact with production unit so that they have sufficient inventory level as and when the demand is made. The sales unit may also interact with finance unit for employee payments. Interdependence Some or all components or subsystems of the system may be dependent on one another. They may be coordinated & linked together according to some plan. In simpler terms, if the output of one subsystem is input for the proper functioning of another subsystem, then
- 15 -
KSOU
the second subsystems is said to be interdependent on first. This interdependence may continue like a chain with in a system. For example the outcome of the raw material unit of a firm i.e the processed raw material may be input to the production unit. The finished products manufactured by production unit may be input to testing unit and so on. Integration The term integration refers to the holism of system. It tells how different subsystem or components are tied together to form a system .It also implies how the different parts of system work together within the system even though each part performs a unique function. For a Manufacturing firm to produce required products with a very good quality and at a reasonable price, all other subunits like procurement, production, finance, quality control & testing and sales must work with coordination. Central Objective Objectives are the main goals / aim to be achieved through the system. The systems exists to achieve or to help achieve these objectives. Objectives may be real or stated. Objectives may be long-term objectives or short-term objectives.
Types of systems
There are numerous types of systems that exist and we also come across them in our day-to-day life. Systems may be classified into different types. Normally all the systems are categorized into two categories namely natural systems and man-made systems.
- 16 -
KSOU
Natural systems There are thousands of systems that exist in nature. We can further classify natural systems into two basic subcategories namely, physical systems and living systems. Physical systems include diverse systems like Stellar systems: galaxies, solar systems, etc. Geological systems: rivers, mountain ranges, etc. Living systems encompass all of the animals, plants and human beings. The living systems, whether at the level of the cell, the organ, the organism, the group, the organization, the society, or the supranational system, all consists of around 19 subsystems. Some of these include the boundary, the distributor, the converter, the producer, the extruder, the channel and net, the decoder, the memory, etc. Man-made systems Man-made systems are the systems developed to support the human working ability. Some of the man made systems include: Social systems: organizations of laws, doctrines, customs, etc. Transportation systems: networks of highways, canals and airlines. Communication systems: telephone, telex and messaging system Manufacturing systems: factories, assembly lines, etc.
Financial systems: accounting, inventory, general ledger and so on. Today because of technology advancements, we can observe that most of these systems include computers. However there are still some systems may not being automated because of reasons like cost, convenience, security, maintainability and politics. Most of the man-made systems, including computer systems can interact with physical systems and living systems. In some cases, automated systems are being designed to replace living systems. And in some cases living systems are considered as components of automated systems. Automated systems Automated systems are the man-made systems that interact with or are controlled by one or more computers. Although many different kinds of automated systems exists, they all
- 17 -
KSOU
have some of the common components like hardware, software, people, data and procedures. Automated systems can be classified in many ways. One simplest way of categorizing is by application. But, such a classification is not useful because techniques like analyzing, modeling, designing and implementing automated systems are generally the same regardless of the application. A more useful categorization of automated systems is as follows: Batch system: In a batch system the information is usually retrieved on a sequential basis, i.e the computer system read through all the records in its database, processing and updating those records for which there is some activity. On-line systems: An on-line system is one, which accepts input directly from the user or environment where it is used and also returns outputs or results of computation directly to where they are required. Real-time systems: A real-time system may be defined as one which controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time. Decision-support systems: These computer systems that help managers and other knowledge workers in an organization make intelligent, informed decisions about various aspects of the operation. Typically, the decision-support systems do not operate on a regular basis. Instead, they are used on an adhoc basis, whenever needed. Knowledge-based systems: The goal of computer scientists working in the field of artificial intelligence is to produce programs that imitate human performance in a wide variety of intelligent tasks. For some expert systems, that goal is close to being attained. For others, although we do not yet know how to construct programs that perform well on their own, we can begin to build programs that significantly assist people in their performance of a task. Other classifications Systems can also divided as Physical or abstract Open or closed
Physical systems
- 18 -
KSOU
Physical systems are tangible entities that may be static or dynamic in operation. For example, physical parts of the computer center like computers, desks, and chairs that facilitate operation of the computer can be seen and counted. Such systems are static physical systems. A programmed computer in which data, programs, output and applications change as the users demand is dynamic physical system. Abstract systems Abstract systems are conceptual or nonphysical entities. They may be formulas of relationship among sets of variables or models i.e. the abstract conceptualization of physical situations. A model is an easier way of visualizing relationships in the system under study. Open system Open systems is a system having an interface with environment. It permits interaction across its boundary. It receives inputs from within the system or from the environment and delivers outputs the system or environment. Open systems tend to have form and structure. They adapt to changes in environment so as to continue to exist. Information systems are open systems, which adapt to the changing demands of the user. Other examples of open system include biological system, organizational system. Closed system A closed system is one that does not interface with its environment, i.e. it has no input or output.
- 19 -
KSOU
The concept of closed systems is more relevant to scientific systems than to social systems. Closed systems are isolated from environmental influences. A completely closed system is rare in reality. A chemical reaction in a sealed, insulated container is an closed system. Relatively closed systems are special type of closed system, which is less relaxed when compared to closed systems. They are used in organizations and in information processing, where systems are relatively isolated from the environment, but are not completely closed. For example, a computer program with predefined input, a process and an output is a relatively closed system.
Systems principles
There are a few general principles or guidelines that are of particular interest to people building automated information systems. They include: 1. If a system is more specialized then it is less flexible i.e., the ability of a system to be adapted to different circumstances is very less. 2. If a system is more general-purpose then it is less optimized for a particular situation. But the more the system is optimized for a particular situation, the less adaptable it will be to new circumstances 3. If a system is very large then maintenance is a tedious process. 4. Systems can be part of larger systems and they can always be partitioned into smaller subsystems. 5. Systems can be scalable. However, this principle could not be true for all systems.
Elements of a system
A systems consists of the following elements, Input Processing Output Boundary Environment Components
- 20 -
KSOU
Input: A system may accept input from within its boundary or from the environment. For example, in a manufacturing firm, the production unit may get raw materials from the procurement section which is a part of the system i.e. a subsystem (within the system boundary) or directly from the raw material supplier which is outside the system i.e. environment. Output: Any system that has an intended set of inputs with certain processing yields output. This output may be used by any subsystems or by the environment. Consider the same manufacturing scenario, the production unit may deliver finished products to the sales unit, a subsystem or directly delivery to the wholesalers / retailers i.e. to environment. Processing: Data to be converted into information should undergo a transformation process. Similarly, inputs that need to be converted into a desirable output should undergo the processing. For instance, to get a finished product the raw materials have to undergo the process of cleaning, manufacturing, testing, etc. System boundary: System boundary is a delimiter, which divides or separates the system from the environment. Environment: Anything outside system boundary is environment. Components: The subsystems/ subparts of a system operating independently are called the components of a system. There may be association between to or more components of a system like finance unit and sales unit of a manufacturing firm. Such an association is called interrelationship. Interaction between two or more components requires an interface to be used. The following figure 2.1 illustrates the different view of basic elements of a system.
- 21 -
KSOU
- 22 -
KSOU
Environment
Input
Processing
Output
System Boundary
Other Systems
Fig. 2.1 System Elements
- 23 -
KSOU
UNIT 3 INFORMATION SYSTEMS

Learning Objectives: This unit introduces the concepts of Information systems such as, What is an information system?, Information system resources, Types of Information system: Operation support and Management support.
What is an information System?

Information systems can be defined in many ways. An Information System is an organized combination of people, hardware, software, and communication networks and data resources. The information systems are used to collect, transform and disseminate information in an organization for better management. Alternatively, an information system can also be defined as a set of interrelated components that collect, process, store, and distribute information to support decision making, coordination, control, analysis, and visualization of various organizational activities. Finally, we can also define an information system is a set of interrelated elements or components that collect (input), manipulate (process), and disseminate (output) data and information and provide a feedback mechanism to meet an objective. Today most of the automated systems that we come across are information systems. For instance, ATM, card catalog in a library and cash register maintained in banks are all information systems.
Why information systems?

Today the business environment is changing due to the following factors Globalization Industrial economies Transformation of the enterprise
- 24 -
KSOU
Globalization has paved a way for management & control in a global marketplace and also competition in world markets. Global work groups and global delivery systems are extensively used by most of the companies. We can also notice that most of the recent business firms are focusing on knowledge and information based economies. This inturn has led to higher productivity in terms of new products & services. Thus knowledge is treated as one of the basic assets of the organization. Thus, globalization and industrial economies have made industrial revolution by transforming the centralized business approach into a decentralized, more flexible and location independent approach. They have also empowered teamwork within the firms. In order to survive and prosper in such a chaining environment, automation of day-to-day business activities is becoming crucial. As a solution deployment of Information systems are considered. The fundamental roles of information system in business includes
1. Support of most business processes and operations. 2. Support of decision making by its employees and managers. 3. Support of its strategies for competitive advantage.
Information system Resources

Information systems resources include, 1. People resources 2. Hardware resources 3. Software resources
- 25 -
KSOU
4. Data resources 5. Network resources People resources: The main aim of an information system is to provide information to its users. Users are the people who interact with an information system, both inside and outside the organization. There are two types of user namely end user and specialists. Information system specialist includes users like system analysts, software developers and system operators. Other users other than the IS specialists are called end users. The success or failure of a system usually depends on whether users are satisfied with the systems output and operations. To serve users, successful information systems depend on skilled professional, such a systems analysts, programmers, network administrators, and other IT staff members. Hardware Resources Hardware consists of everything in the physical layer of the information system. Hardware resources can be classified as into machine resources and media. Machine resources include computers, video monitor, magnetic disk drives, printers and optical scanners. Media includes floppy disks, magnetic tape, optical disks, plastic cards and paper forms. Software Resources Software refers to the programs that control the hardware and produce the desired information or results. Software consists of system software and application software. System software manages the hardware components, which can include a single workstation or a global network with many thousands of clients. Either the hardware
- 26 -
KSOU
manufacturer supplies the system software or a company purchases it from a vendor. Examples of system software include the operating system, security software that protects the computer from intrusion, device drivers that communicate with hardware such as printers, and utility programs that handle specific tasks such as data backup and disk management. Application software consists of programs that support day-to-day business functions and provide users with the information they require. Application software can serve one user or thousands of users throughout the organization. Example of company-wide applications, called enterprise applications, includes order processing systems, payroll systems, and company communications network. On a smaller scale, individual users increase their productivity with tools such as spreadsheets, word processors, and database management systems.
Data Resources
Data is the raw material that an information system transforms into useful information. An information system can store data in various locations, called table. By linking the tables, the system can extract specific information. Consider a payroll system. At the end of a pay period, the payroll system produces a payback check that accurately reflect the employees hours worked, gross pay, current deduction, and net pay.
- 27 -
KSOU
Network Resources Today most of the enterprises are internetworked enterprises i.e globally distinct parts of the organization are connected together through network. Thus network resources includes communication media, communication processors, network access and control software
Types of Information System

Information systems can be broadly classified into two categories namely, operation support system and management support system. The following figure 3.1 illustrates the classification of Information Systems.
Information System
Operation support System
Management support System
Process Transaction Control Processing System System
Enterprise Collaboration System

- 28 -
Management Information System
Decision Support System
Executive Information System
KSOU
Fig 3.1 Classification of Information System
- 29 -
KSOU
Operation Support System Operation support systems are that process data generated by and used in business operations. The main objective of an operation support system is to efficiently process business transactions, control industrial processes, support enterprise communications and collaboration, and update corporate databases. Operation Support System includes other subsystems like transaction processing system, process control system and enterprise collaboration system. Transaction processing systems process data resulting from business transactions, update operational databases, and produce business documents. Examples of transaction processing system includes Sales and inventory system and processing and accounting systems. Process control systems are used to monitor and control industrial process. Some of the process control systems are petroleum refining, power generation, steel producing systems. Enterprise collaboration systems are used to support team, workgroup, and enterprise communications and collaboration. They inturn create virtual groups / teams. Some examples include email, chat, and video conferencing groupware systems.
Management support systems:

Management support systems focus on providing information and support for effective decision making by managers. Management information systems provide information in the form of prespecified reports and displays to support business decision-making Transactions recorded in a TPS are analyzed and reported by an MIS. They have large quantities of input data and they
- 30 -
KSOU
produce summary reports as output. They are normally used by middle managers. Some of the examples of management information system are Sales analysis, production performance and cost trend reporting systems. Decision support systems provide interactive ad hoc support for the decision making by providing information, models, or analysis tools. Often used by senior manager or highlevel managers. Some of the decision support systems are product pricing, profitability forecasting, and risk analysis.
Executive Information System or Executive Support System provides top executives with information in interactive format. They provide both summary and detailed report for the top executives about the entire organization.
UNIT 4 SYSTEM DEVELOPMENT LIFE CYCLE
The objective of this chapter is to focus on the stages of the system development life cycle (system study). In the present booming economical environment every organization plans to expand and develop quick system and encash economic boom, as soon as possible. This require a process which can quickly develop new systems, in lesser time with lesser cost.
- 31 -
KSOU
What is system development? Just like a living system, the candidate system has a life cycle. We need to recognize this to understand system development. System development is a process of understanding how an information system can support business needs, designing the system then building it and delivering to the users. Definition: A systems development life cycle (SDLC) is a systematic and orderly approach to solving system problems. A conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. The system development project meaning and direction is given by the system analyst. A candidate system is approached after the analyst has a thorough understanding of user needs and problems, has developed as viable solution to these problems, and then communicates the solution through the installation of a candidate system. System Development refers to the process of examining a business situation with the intent of improving it through better procedures and methods. System Development is having two major components in it System Analysis Analysis of current system for Problems & Demerits in it and Additional requirements in new system System Design Process of planning new system which will replace the old one
- 32 -
KSOU
Beginning of a System Development: System Development usually begins when a problem or opportunity is identified by Managers, it can be because of any of the followings: New design idea to smoothen the process in the organization. Evolving environmental changes such as Competition. Adding new business or product line to present business. Present system does not satisfy the users information needs. Present system no longer efficiently and effectively meets the Goals of organization. Excessive time spent in correcting errors. Current Reports / Outputs not meting users decision making skills. Escalating customer and vendor complaints.
System Development Methodology: A system development life cycle is a logical method of system development. Where as a methodology is the physical implementation of that logical life cycle including: step-by-step activities for each phase individual /group roles to be played in each activity deliverables and quality standards for each activity tools and techniques to be used for each activity
Why do we use methodologies?
- 33 -
KSOU
To ensure that a consistent, reproducible approach is applied to all projects systematic approach reduce the risk associated with shortcuts and mistakes produce complete and consistent documentation from one project to the next able to incorporate the use of several development tools and techniques. A system development methodology is a very formal and precise system development process which defines a set of activities, methods, best practices, deliverables, and automated tools for system developers and project managers to use to develop and maintain information systems and software. A system development methodology is a formalized, standardized, documented set of activities used to manage a system development project. It can be characterized as follows: DIVISION OF PROJECT into the identifiable phases which can be managed without having any problem. REVIEW OF DEVELOPMENT PROCESS by TOP Management on periodically by getting deliverables. APPROVALS from all the participants of the Development (i.e. Users, Managers, Analyst and Auditors). TESTING OF SYSTEM thoroughly prior to implementation to ensure that it meets users needs. TRANNING of user who will operate the new system.
POST IMPLEMENTATION REVIEW for effectiveness and efficiency of new system.
Different types of system development methodologies are used in designing information system. Depending upon the actual requirement of the system, different approaches for data processing are adopted. However, some system groups
- 34 -
KSOU
recommend the Centralized data processing system while others may go in for distributed data processing system. In a Centralized data processing, one or more centralized computers are used for processing and the retrieval of information is done from them. The distributed processing systems involve number of computers located remotely in the branches/departments of the organization. The client/server technologies are also gaining popularity these days. Different Phases for System Development Life Cycle: A systematic approach to problem solving and is made up of several phases, each comprised of multiple steps. System development life cycle means combination of various activities. In other words we can say that various activities put together are referred as system development life cycle.
Following are the different phases of system development life cycle: Preliminary Investigation System Analysis or Requirement Analysis System Design Development of Software System Testing Implementation Maintenance
The different phases of system development life cycle is shown in the below figure
- 35 -
KSOU
Fig. 29.1 Different phases of System development Life Cycle
PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE Let us now describe the different phases and the related unique activities of system development life cycle in detail.
Preliminary or Initial Investigation(System Study): System study is the first stage of system development life cycle. This gives a clear picture of what actually the physical system is? In practice, the system study is done in two phases. In the first phase, the preliminary survey of the system is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identification of users requirement and the limitations and problems of the present system are studied. After completing the system study, a system proposal is prepared by the System Analyst (who studies the system) and placed before the user. The proposed system contains the findings of the present system and recommendations to overcome the limitations and problems of the present system in the light of the users requirements. Identifying of problems, opportunities, and objectives. This phase introduces the objectives of the initial investigation, the steps required to initiate an investigation; the tasks involved in the initial investigation, and the data gathering and interviewing techniques. It also
- 36 -
KSOU
includes information and exhibits that should be in the initial investigation report, with regard to "How the standards manual might be used ?" To describe the system study phase more analytically, we would say that system study phase passes through the following steps: problem identification and project initiation background analysis inference or findings
Whatever may be the reason of a request submitted by the Users or Managers to the IS department a system analyst is assigned to make a preliminary investigation. The objective of this activity is to review all requests and identify those proposals that are most beneficial to the organization. But this should be noted that this is neither a designed study nor it includes collection of details to completely describe the business system. Gather information, define system requirements, build prototypes for discovery of requirements, prioritize requirements, generate and evaluate alternatives, review recommendations with management these are various tasks that are performed in this stage. Preliminary Investigation object can be achieved in following steps: Request Clarification Feasibility study Estimating Costs and Benefits Request Approvals
Request Clarification: Defining the Scope and Objective of Request: As mentioned in the objectives of System development objective earlier, an analyst has to define for which objective a request for development is submitted. Conducting the Investigation: This is nothing but the Collection of data / inputs by:
- 37 -
KSOU
Reviewing internal documents (i.e Organizational Charts, operating procedures etc. Conducting interviews of User, Supervisory Personal and Managers
Identify viable option: Analyst has to identify the viable option by applying his common sense and intuitions on his investigation Feasibility (Possibility) Study: Evaluation of alternative systems through cost and benefit analysis. On the basis of the initial study, feasibility study takes place. The feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources and .of course, the cost effectiveness. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy. This phase determines the objectives of the feasibility study and who this task belongs to -- analysts or the project team? It lists out the steps required to complete a feasibility study, identifies the scope of the current system, problems and unexploited opportunities in the current system, which may be either manual or automated. It then discusses the major objectives for the new system, and the various methods to gather data and determine how to use the methods. It also helps to estimate the costs of each possible solution, and develops estimates of the benefits and shortcomings of each solution. It presents users and the management views on the above issues and their decision of whether to commit to the analysis part of the project. This phase may be included some related sub-phases: Current physical model: The description of the system as it is now, including the mechanisms used to accomplish tasks (e.g., people, devices).
- 38 -
KSOU
Current logical model: The system description in term of functions, processes, and data with the mechanisms removed. New Logical Model: The Current Logical Mode with new features added. New Physical Model: The Current Logical Model with the various processes allocated to automation, manual procedures, other mechanisms. Types of feasibility study that need to addressed in this phase are: Technical Feasibility: Hardware and software availability, Technical Guarantee of Accuracy, Reliability, Easy to Access, Data security, technical capacity to hold data and future expansion. Economical Feasibility: Evaluation of cost & Benefits expected. Operational Feasibility: Finding views of workers, employees, customers & suppliers about the use of new system. Schedule Feasibility: Estimation of time to take new system to become operational. Legal feasibility: Testing whether new system will comply financial reporting requirements & Companys contractual obligations. Estimating Cost & Benefit: Costs: Development Costs: This includes cost of testing, training, start up costs, salary to designers, acquisition cost of hardware & software. Operation Costs: This includes operator salary, maintenance costs, etc. Intangible Costs: Loss of employee productivity, self confidence etc.
- 39 -
KSOU
Benefits: Tangible Benefits: Increase in sales / Contribution / Profits. Decrease in investment, operating and processing cost. Improved information availability, analysis, Management Decision skill. Intangible Benefits: Increase in Goodwill / Improved Image of Business.
Request Approval: Based on the Observation and Findings of the Analyst, selected requests are put up for the approval of management. Personnel involved in all these activities: Analyst User management Systems management
System Analysis or Requirement Analysis: After the selection of a request for development analyst study in depth the Present and Proposed New System. This is the study of weakness & Problems in the present system and management requirements of new system. This phase of System Development is being completed in following step: Collection of data and facts Analysis of Present System Analysis of Proposed system
Collection of Data & Facts: Every system is built to meets some set of needs and to assess these needs, the analyst often interact extensively with the people, who will be benefited from the system In
- 40 -
KSOU
order to determine the requirement of those peoples he can use following facts finding techniques: Documents: This includes the Manuals, diagrams, forms, organizational charts etc. It should be ensured that all documents are accurate & up to date Questionnaires: These are skillfully drafted group of standard question which can be given to all personal and can be analyze quickly. Interviews: To get a complete picture of problems and opportunities. Observation: Surprise Visit of users work palace to get a clear picture of users environment. Analysis of Present System: Detailed investigation of the present system involves collecting, organizing and evaluating facts about the present system and the environment in which it operates by studying following areas in depth: Review of Historical Aspects of organization Analyze Present inputs to the system Review of all data file maintained irrespective of online or offline Review methods, procedures & data communications Analyze Present outputs of system Review internal controls Model the existing physical system and logical system Undertake overall analysis of present system
Analysis of Proposed System: After each functional area of present system is defined the purposed system specification must be defined. These specification will be based on the strength and weakness of present system. System Specification which should be in conformity with the Project Objective and Areas Covered should be following: Output / Reports Maintenance of Database Data Inputting Process Methods and Procedures to show the relationship between Input and Output
- 41 -
KSOU
Work volume including peak period work volume
-Determining information requirements: Interview management, operations personnel Gather systems/operating documents Use questionnaires Observe the system and personnel involved
-Learn the who, what, where, when, and how, and the why for each of these. -Analyzing system needs Create data flow diagrams Document procedural logic for data flow diagram processes Complete the data dictionary Make semi-structured decisions Prepare and present the system proposal Recommend the optimal solution to management
Assuming that a new system is to be developed, the next phase is system analysis. Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system. During analysis, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for system analysis. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration: Keeping in view the problems and new requirements and workout the pros and cons including new areas of the system All procedures, requirements must be analyzed and documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specifications. System Analysis also includes sub-dividing of complex process involving the entire system, identification of data store and manual processes.
- 42 -
KSOU
The main points to be discussed in system analysis are: Specification of what the new system is to accomplish based on the user requirements. Functional hierarchy showing the functions to be performed by the new system and their relationship with each other. Function network which are similar to function hierarchy but they highlight those functions which are common to more than one procedure.
System Design: Based on the user requirements and the detailed analysis of a new system, the new system must be designed. This is the phase of system designing. It is a most crucial phase in the development of a system. System design first involves Logical Design. First one has to write detailed specification that called design specification. Than secondly it involves Physical Design. Design and integrate the network, design the application architecture, design the user interfaces, design the system interfaces, design and integrate the database, prototype for design details, design and integrate the system controls
Normally, the design proceeds in two stages: Preliminary or general design Structure or detailed design
Preliminary or general design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Show the users the view of the application. In this phase, as well as the previous two, users must be directly involved. In this phase, The analysts imagination, creativity... and initiative are used to their fullest. It also issues the System Flowcharts to develop. In addition, broad specifications that describe how the data is to be processed by the computer will be developed. Structure or Detailed design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a
- 43 -
KSOU
blue print of a computer system solution to a given problem having the same components and inter-relationship among the same components as the original problem. Input, output and processing specifications are drawn up in detail. In the design stage, the programming language and the platform in which the new system will run are also decided. The Analysts have to transform from general design specifications to detailed requirements that can be used in implementing the many tasks that make up the system. The final report should include the Procedural Flowchart, record and report layout, and a realistic plan for implementing the design. No major changes should be made until the design is implemented and the system is operational, Then the programs for both transaction processing and batch jobs are executed. If there is the problems, the professional data processing staff is responsible for determining the cause and implementing a solution. There are several tools and techniques used for designing. These tools and techniques are: Flowchart Data flow diagram (DFDs) Data dictionary Structured English Decision table Decision tree
This Phase of System Development includes following functions: Designing System Output Designing System Input Data Storage Designing System Output: Important factor of Output Design: A process of Output designing contained Designing of Content (required info in an output), Form (the way in which a content presented to user), Volume (quantum of Output i.e. Prints), Time Lines (time of need of outputs), Media (method of output i.e. Print, CD etc) and Format (Physical arrangement of Data).
- 44 -
KSOU
Way of Presenting Information: The way in which data will be presented to the User which should be simple and better understandable and for this Tabular and Graphic (charts, maps etc) can be used. Design / Layout of Output: The layout of a output can be in Printed form, visual on screen etc. Designing of System Input: Important Factor of Input Design: A process of Input designing contained Designing of Content (required info in a input), Form (the media in which input is received by user), Volume (quantum of input records), Time Lines (required time to enter one record), Media (method of input i.e. keyboard, BCR etc) and Format (Input by the user in the system). Coding: To reduce input control errors and speed up the entire process coding is very important. This is also important to get all records in a specific form.
Methods: Individually (Unique codes giving only one option to user out of may i.e selection of gender from male or Female etc), Space or suggestive (for brief information).
Schemes: Classification Codes (only single digit is required for quick input), Function code (activities to be performed without spelling out all details) etc.
Data Storage: This includes the storage of data, indexing etc. For storage of data it can follow the following approaches: Conventional File Approach: This is a traditional approach where each transaction is updated in the master file, each application have their own database and it is not useful for other applications. (Boss in IHCL) Database Approach: This support decision making skill of the management. Data are stored in the small-small database files and same data can be used in the multiple applications. (Files maintained as a process of the organization for MIS etc.)
- 45 -
KSOU
In this phase designing the recommended system, design the user interface, design output, design input, design system controls, design files and/or database, produce program specifications, producing decision trees or tables these are the various activities that are performed. Personnel involved in this phase are Analyst, System designer, User management, User operations workers, Systems management.
Development of Software(Coding): After designing the new system, the whole system is required to be converted into computer understanding language. Coding the new system into computer programming language does this. It is an important stage where the defined procedure are transformed into control specifications by the help of a computer language. This is also called the programming phase in which the programmer converts the program specifications into computer instructions, which we refer as programs. The programs coordinate the data movements and control the entire process in a system. It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance and future change, if required. Developing and documenting software. Design computer programs using structure charts, NassiSchneiderman charts, and pseudo code, walkthrough program design, write computer programs, document software with help files, procedure manuals, and Web sites with Frequently Asked Questions(FAQs). After designing the system all required resources (hardware & Software) should be gathered. If some of them are already with the organization than it reduces the cost of acquisition, for remaining items organization has to plan its procurements process, this includes following: Selection of Hardware: Selection of Software Vendor Selection
Selection of Hardware:
- 46 -
KSOU
While selecting the hardware for new system a developer must keep in mind following: Latest Technology Whether requirement of business is for Scientific or Business Computer Software supplied by the manufacture and requirement of additional software Compatible with the existing systems in organization Selection of Software: Selection of a perfect Software for organization is totally depends on the followings: Rapid Implementation: Whether software can be implemented quickly and put on use ASAP. This characteristic will not be there if software is to be developed, hence that will take long time. Low Risk of Quality: Software should be properly tested by the manufacturer for the quality otherwise organization has to spend its precious time on quality assurance. Low Risk of Cost: The cost and benefit analysis will give us the perfect cost, which organization can bear for acquiring the given software. Vendor Selection: This is finding of resources from new system hardware and software will be procured. At resource will be finalized based on the following: Performance Capability in relation to cost and quality: Cost & Benefits -Preparation of comparative statements based on the quotations received from vendors with terms and conditions. Maintainability - Maintenance requirements of the new equipments Compatibility with the Existing system. Vendor support -Post sale support from vendors Personnel involved in this phase are Analyst, System designer, Programmers, Systems management.
System Testing:
- 47 -
KSOU
Before actually implementing the new system into operations, a test run of the system is done removing all the bugs, if any. It is an important phase of a successful system. After codifying the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results. Using the test data following test run are carried out: Unit test System test
Unit test: When the programs have been coded and compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections). System Test: After carrying out the unit test for each of the programs of the system and when errors are removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analyzed. During the result analysis, it may be found that the outputs are not matching the expected out of the system. In such case, the errors in the particular programs are identified and are fixed and further tested for the expected output. When it is ensured that the system is running error-free, the users are called with their own actual data so that the system could be shown running as per their requirements. This is Performing Parallel Operation and get the following done to analyze the operational implementation feasibility. Preparation realistic data based on the actual working data of the organization. It may be based on the Historical data of the organization. Processing of Test Data with the new system and take all outputs which can be possible. Checking result of all system with the results of the same data in the current system for the accuracy and error in the processing. Review result with future users, operational and support personal:
- 48 -
KSOU
Testing the system is nothing but test and debug computer programs, test the computer system, enhance system. Personnel involved in this process are- Analyst, System designer, Programmers, Systems management
Implementation: After having the user acceptance of the new system developed, the implementation phase begins. Implementation is the stage of a project during which theory is turned into practice. During this phase, all the programs of the system are loaded onto the user's computer. After loading the system, training of the users starts. Main topics of such type of training are: how to execute the package, how to enter the data, how to process the data (processing details), how to take out the reports. After the users are trained about the computerized system, manual working has to shift from manual to computerized working. In this phase construction of software components, verification and testing, converting data, train users and document the system and installation of the system is carried out. As the final Phase of the System Development it gives the results of the whole process and handover the new system to end users. This also includes the overall review of the development process for its leakages and errors in it. Detailed logic plans must be developed for all programs before they can be written, tested, and documented. After each procedure and program are tested, the system is tested. The conversion to the new system is made according to a plan developed in the detailed design phase. Many companies encourage their customers documenting their own systems. System Audit: When the implementation report is submitted, an evaluation should be made to determine whether the system meets the objectives stated in the general design report. In this phase, users may be able to suggest the easy-to-implement improvements. As in the six phase development life cycle, the project can be
- 49 -
KSOU
dropped at any point prior to implementation. A project may be dropped if the benefits derived from the proposed system do not justify commitment of the needed resources. Or if the costs is higher, than expected.
The following two strategies are followed for running the system: Parallel run: In such run for a certain defined period, both the systems i.e. computerized and manual are executed in parallel. This strategy is helpful because of the following: Manual results can be compared with the results of the computerized system. Failure of the computerized system at the early stage, does not affect the working of the organization, because the manual system continues to work, as it used to do. Pilot run: In this type of run, the new system is installed in parts. Some part of the new system is installed first and executed successfully for considerable time period. When the results are found satisfactory then only other parts are implemented. This strategy builds the confidence and the errors are traced easily. To complete this phase a developer has to complete the following functions successfully: Equipment Installation Training Personnel Conversion Procedure Post Implementation Evaluation (Feedback) Equipment Installation: This includes following functions: Site Preparation: Preparing the site for installation and mobilizing all required equipments and personnel at the site. Equipment Installation: Assembling and commissioning of the equipments (hardware) and installation of software Equipment Checkout: Organize test runs of the system with sample actual data and thereafter if it performs satisfactory than with the live actual data.
- 50 -
KSOU
Training Personnel: Since user are not familiar with the New System, System Development Process includes training of System Operators: IT personnel who will handle the system maintenance in the future. Users (Operators): The final user who will work on the system. If there are deficiencies in Training, these may translate into reduction in user productivity levels Conversion Procedures: This is the time when organization switch over from old system to new developed system. Following are the Strategies / Methods for conversion / Changeover of old system to new system. Direct Changeover: Direct closing the old system and starting the new one. Parallel Changeover: for sometime operating both system simultaneously. Gradual Changeover: Department wise switch over to new systems. Distributed Changeover: Any other method which management feels good for organization. Post Implementation Evaluation (Feedback): Analysis of Satisfaction of Users or checking whether system is Operating Properly or whether Objectives of System Development is achieved or not, is the most important function in whole System Development process. This is also important for development of new system in future since each development gives some experiences and lists some things to be taken care off. Post Implementation Evaluation includes following area: Development Evaluation: Check whether development was done within schedule and budgets. Operation Evaluation: Check whether system is capable for handling the duties and objective of development is achieved Information Evaluation: Check Satisfaction of users etc.
Implementing and evaluating the system involves plan conversion, train users, purchase and install new equipment, convert files, install system, review and evaluate system.
- 51 -
KSOU
Personnel involved in this process Analyst, System designer, Programmers, User management, User operations workers, Systems management. Maintenance: Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environment. It has been seen that there are always some errors found in the system that must be noted and corrected. It also means the review of the system from time to time. The review of the system is done for: knowing the full capabilities of the system. knowing the required changes or the additional requirements. studying the performance.
System maintenance is done mainly to remove undetected errors, and enhancing existing software. The time spent on maintenance typically ranges from 48-60 percent of total time. Systems are enhanced for the following reasons: o Adding additional features to the system. o Business and governmental requirements change over time. o Technology, hardware, and software are rapidly changing. Perfective maintenance: -This implies that while the system runs satisfactorily, there is still room for improvement. Adaptive maintenance: - All systems will need to adapt to changing needs within a company. Corrective maintenance -Problems frequently surface after a system has been in use for a short time, however thoroughly it was tested. Any errors must be corrected.
- 52 -
KSOU
If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above life cycle phases.
UNIT 5 Feasibility Analysis

On the basis of result of the initial study, feasibility study takes place. The feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources and .of course, the cost effectiveness. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy. The objective of a feasibility study is not to solve the problem, but to acquire a sense of it's scope. The rest of feasibility study is a formal proposal. Depending on the results of the starting investigation, the survey is expanded to a more detailed feasibility study. Feasibility study is a test of a system proposal according to its workability impact on the organization, ability to meet user requirements and effective use of resources. Feasibility study focuses on three questions: 1. What are the users demonstrable requirements and how does a candidate system meet them? Is there a new & better way to do the job that will benefit the user? 2. What resources are available for given candidate system? Is the problem worth solving? What are the costs & savings of the alternatives? 3. What are the likely impacts of the candidate systems on the organization? How well does it fit within the organizations plan? What is recommended? The above questions must be answered carefully. They revolve around investigation & evaluation of the problem, identification & description of candidate system, specification of performance & the cost of each system and final selection of the system.
- 53 -
KSOU
This phase determines the objectives of the feasibility study and who this task belongs to -- analysts or the project team? It lists out the steps required to complete a feasibility study, identifies the scope of the current system, problems and unexploited opportunities in the current system, which may be either manual or automated. It then discusses the major objectives for the new system, and the various methods to gather data and determine how to use the methods. It also helps to estimate the costs of each possible solution, and develops estimates of the benefits and shortcomings of each solution. It presents users and the management views on the above issues and their decision of whether to commit to the analysis part of the project. This phase may be included some related sub-phases: Current physical model: The descriptions of the system as it is now, including the mechanisms used to accomplish tasks (e.g., people, devices). Current logical model: The system description in term of functions, processes, and data with the mechanisms removed. New Logical Model: The Current Logical Model with new features added. New Physical Model: The Current Logical Model with the various processes allocated to automation, manual procedures, other mechanisms. The rest of the feasibility study is a formal proposal. Factors that depend upon feasibility study are: 1. Statement of the problem: A carefully worded statement of the problem that led to analysis. 2. Summary of findings & recommendations: A listed of the major findings & recommendations of the study. It is deal for the user who requires quick access to the results of the analysis of the system under study.
- 54 -
KSOU
3. Details of findings: An outline of the methods & procedures undertaken by the existing system, followed by coverage of the objectives & procedures of the candidate system, including personnel assignments, costs, project schedules & target dates is also discussed. 4. Recommendations & conclusions: Specific recommendations regarding the candidate system, including personnel assignments, costs, project schedules & target dates. Since the proposed is reviewed by the management, it becomes a formal agreement. This is a crucial decision point in the life cycle. Changes in the proposal are made in writing, depending on the complexity, size & cost of the project. It is simply common since to verify changes before committing the project to design. Depending on the results of the staring investigation the survey is expanded into a more detailed feasibility study, it is a test of a system proposal according to it's workability impact on the organization, ability to meet user requirements and effective use of resources. Feasibility study focuses on three questions:
Steps in feasibility analysis: Feasibility Analysis involves 8 steps: 1. 2. 3. 4. 5. 6. 7. 8. Form a project team & appoint a project leader. Prepare system flowcharts. Enumerate potential candidate system. Describe & identify characteristics of candidate systems. Determine & evaluate performance & cost effectiveness of each candidate system. Weigh system performance & cost data. Select the best candidate system. Prepare & report final project directive to management.
- 55 -
KSOU
Form a project team & appoint a project leader: The concept behind a project team is that future system users should be involved in its design & implementation. Their knowledge & experience in the operations area are essential to the success of the system. The analyst & an assistant is sufficient for small projects but for complex studies project team is required. Team consists of analyst & the user staff. An outside consultant & information specialist may also join the team. The senior system analyst, the most experienced analyst in the team, is appointed as project leader. He has to conduct regular meetings to keep up the momentum & accomplish the mission (selection of the best candidate system). A record is kept of the progress made in each meeting. Prepare system flowcharts: The next step is to prepare generalized system flowcharts for the system. In the initial investigation stage information-oriented charts & data flow diagrams prepared & they are reviewed in this stage also. The main reason to prepare system flowcharts is that they bring up the importance of inputs, outputs & data flow among key points in the existing system. All the flowcharts needed for detailed evaluation are completed at this point.
Enumerate potential candidate system: In this step identification of the candidate systems that are capable of producing the outputs will be carried out, which are included in the generalized flowcharts. This is nothing but transformation from logical to physical system model. In this step consideration of hardware that handles the total system requirement is also done. An important aspect of hardware is processing & main memory. Because there are large numbers of computers with different processing sizes,
- 56 -
KSOU
main memory capabilities, & software support. The project team may also contact vendors for information on the processing capabilities of the system available. Describe & identify characteristics of candidate systems: The candidate systems are considered. Now from this the team begins a preliminary evaluation in an attempt to reduce them to a manageable number. Technical knowledge & expertise in the hardware/software area are critical for determining what each candidate system can & cannot do. Determine & evaluate performance & cost effectiveness of each candidate system: In this step the performance of each candidate system is evaluated against the system performance requirements set prior to the feasibility study. There has to be a close match as practicable, although the trade-offs is necessary to select the best system. The cost encompasses both designing & installing the system, which includes user training, updating the physical facilities & documenting. System performances are evaluated against the cost of each system to determine which system is likely to be the most cost effective as well as meets the performance requirements. Costs are more easily determined when the benefits of the system are tangible & measurable. An additional factor to consider is the cost of study design & development. The cost of the study phase is a fixed cost (sunk cost). The analyst can plot the performance criteria & costs for each system to determine how each fare. Weigh system performance & cost data: The performance & cost data of each candidate system show which system is best choice. This outcome terminates the feasibility study. Some times the performance/cost evaluation matrix is used to clearly identify the best system. So in this step weight the importance of each criterion by applying a rating figure. Finally the candidate system with the highest total is selected.
- 57 -
KSOU
The procedure for weighting candidate system is as follows:1. Assign a weighting factor to each evaluation criterion based on the criterions effect on the success of the system. 2. Assign a quantitative rating to each criterions qualitative rating. 3. Multiply the weight assigned to each category by the relative rating to determine the score. 4. Sum the score column for each candidate system. Select the best candidate system: The system with the highest total score is judged the best system. This assumes the weighting factors are fair & the rating of each evaluation criterion is accurate.
Prepare & report final project directive to management: The report is a formal document for management use, brief enough & nontechnical to be understandable, but has to be detailed enough to provide the basis for system design. There is no standard format for preparing feasibility reports. Usually the analyst decide on a format that suits a particular user & system. The report contains the following sections:1. Cover letter - formally presents the report & briefly indicates to management the nature, general findings & recommendations to be considered.
- 58 -
KSOU
2. Table of contents - specifies the location of the various parts of the report so that management can quickly refer to the sections that concern them. 3. Overview - is an explanation of the purpose & scope of the project, the reason for undertaking feasibility study, the department involved or affected by the candidate system. Names of the persons who conducted the study, when it began, other information that explains the circumstances surrounding the study. 4. Detailed findings - the methods used in the present system, systems effectiveness & efficiency, operating costs, descriptions of the objectives, general procedures of the candidate system, a discussion of output reports, cost & benefits gives management a feel for the pros & cons of the candidate system. 5. Economic justification point-by-point cost comparisons, preliminary cost estimates for the development & operation of the candidate system. A return on investment (ROI) analysis of the project is also included.
6. Recommendations & conclusions suggest to management the most beneficial & cost-effective system. Any conclusions from the study may be included. 7. Appendixes document all the memos & data compiled during the investigation. They are placed at the end of the report for reference. If the feasibility team has maintained good rapport with the user & staff it makes the recommendations easier to approve. Disapproval of the feasibility report is rare if it has been conducted properly. The report is only a recommendation, but it is an authoritative. Management has to finally approve. Approval of feasibility report is required before system design is initiated. Types of feasibility study:
- 59 -
KSOU
A feasibility study assesses the operational, technical, human factors, legal, economic merits of the proposed project. There are six types of feasibility: Technical feasibility Economic feasibility Operational feasibility Human Factors Feasibility Legal and Political Feasibility Schedule Feasibility Technical feasibility assesses whether the current technical resources are sufficient for the new system. Focused on understanding the technical resources and their applicability to the needs of the proposed system Hardware parts required for the proposed system (candidate system). Software necessary for the proper working of the candidate system. Operating environments the environment in which the proposed system has to be operated. If they are not available, can they be upgraded to provide the level of technology necessary for the new system. The technical resources needed to develop, purchase, install, or operate the system. The feasibility study has to ensure that the company have the necessary hardware, software, and network resources, have the needed technical expertise, the hardware and software environment be reliable, the system should be able to handle future transaction volume and company growth. Economic feasibility determines whether the time and money are available to develop the system. Economic Feasibility means that the projected benefits of the proposed system outweigh the estimated costs usually considered the total cost of ownership (TCO). Determine whether the proposed system will provide positive economic benefits to the organization.
- 60 -
KSOU
Economic feasibility analysis is the most frequently used method for evaluating the effectiveness of a candidate system. Most commonly known as cost/benefit analysis. This study is carried out to determine the benefits and savings that are expected from a candidate system and compare them with costs. If the benefits outweigh cost, then the decision is made to design and implement the system. Otherwise further justifications or alterations have to be made to the proposed system. This is an ongoing effort that improves accuracy at each phase of system development life cycle. In this analysis the expenses/finance provided to people, including IT staff and users, hardware and equipments, software, formal and informal training, licenses and fees, consulting expenses, facility costs, and the estimated cost of not developing the system or postponing the project are considered. Operational feasibility means that a proposed system will be used effectively after it has been developed. Users that do not want a new system may prevent it from becoming operationally feasible. Focused on whether the proposed project will be used effectively after it has been developed i.e., Schedule and Usability. This analysis determines whether the management or the users support the projects, users see the need for change, the system result in a work force reduction or not, the training is required for users to operate the system, customers experience adverse effect in anyway, either temporarily or permanently. Human factors feasibility is focused human resources that are required in during system development. It focuses on the managers, company staff and end users, degree of resistance from users, degree of change to users working environment, current state of human resources etc.. Legal and Political feasibility analyzes the potential legal ramification of the new system. Understanding of the key stakeholders within the organization. In this analysis consideration of legal issues like rules and regulations of government, market issues, political factors etc. has to be done. Consulting legal advisors during this process of the system development is must.
- 61 -
KSOU
Schedule feasibility means that a project can be implemented in an acceptable time. The company or the IT team control the factor that effect schedule feasibility. Conditions that are to be satisfied during the development of the system. Verify that an accelerated schedule pose any risk. Identify and weed out the systems requests that are not feasible. Feasibility analysis is an ongoing task that must be performed throughout the systems development process.
Feasibility assessment category
Description Determines the relationship between the
Technical
present technology resources of the organization and the expected technology needs of the proposed project.
Economic
Assesses the cost/benefit relationship of the proposed project and its net value contribution to the organization. Determines the relationship between the
Human Factors
present human resource base of the organization and the expected human resource needs of the proposed project.
Operational
Determines the degree to which the proposed development project fits with the existing business environment and objectives with regard to development schedule, delivery date, corporate culture, and existing business processes.
- 62 -
KSOU
Legal and Political
Identifies any potential legal ramifications resulting from the construction and implementation including infringements, of the new or of system patent existing copyright violation
antitrust laws, foreign trade restrictions, or any existing contractual obligations of the organization.
Table 5.1. Categories of Feasibility study
UNIT 6 SYSTEM ANALYST
Objectives: Explain the need of System analyst Discuss the various roles played by system analyst while developing a project. Here we shall go through in detail about who is the system analyst & the various roles played by the system analyst. Who is a Systems Analyst? Systems analysts are people who understand both business and computing. Systems analysts study business problems and opportunities and then transform business and information requirements of the business into the computer-based information systems and computer applications that are implemented by various technical specialists including computer programmers. Key individuals in the system development process. The organizational role most responsible for the analysis and design of information systems. A structured framework & a disciplined approach to solving problems are a
- 63 -
KSOU
part of analysis. Designing & implementing systems to suit organizational needs are the functions of the system analyst. Analyst plays a major role in seeing business benefit form computer technology. The analyst is a person with the unique skills. A system analyst is a person who conducts a methodical study & evaluation of an activity such as a business to identify its desired objectives in order to determine procedures by which these objectives can be gained. The task of the system analyst is to elicit needs & resource constraints & to translate these into a viable operation. Analysts must be ethical with users and customers Many organizations consider information systems and computer applications as essential to their ability to compete or gain competitive advantage. Information has become a management resource equal in importance to property, facilities, employees, and capital. All workers need to participate in the development of these systems and applications not just the computer and information specialists. But one specialist plays a special role in systems and applications development, the systems analyst. A systems analyst(s) facilitates the development of information systems and computer applications. The systems analyst performs systems analysis and design. The system analyst bridges the communications gap between those who need the computer and those who understand the technology. Systems analysis is the study of a business problem domain for the purpose of recommending improvements and specifying the business requirements for the solution. Systems design is the specification or construction of a technical, computer-based solution for the business requirements identified in a systems analysis. (Note: Increasingly, the design takes the form of a working prototype.). Assesses how businesses function by examining the inputting and processing of data and the outputting of information with the intent of improving organizational processes is the responsibility of a system analyst. System analyst is catalyst for change (i.e., improvements to the business that can be done via information systems).
- 64 -
KSOU
Major types of system analysts: - Outside consultants to businesses (organization). - Hired specifically to address information systems issues within a business (organization). - Supporting experts (within a business you are regularly employed) A systems analyst interacts with users at different levels in the organization - user managers, operations workers, systems managers, systems designers, programmers etc. A formal Definition A systems analyst facilitates the study of the problems and needs of a business to determine how the business system and information technology can best solve the problem and accomplish improvements for the business. The product of this activity may be improved business processes, improved information systems, or new or improved computer applications frequently all three. When information technology is used, the systems analyst is responsible for: The efficient capture of data from its business source The flow of that data to the computer The processing and storage of that data by the computer The flow of useful and timely information back to the business and its people A systems analyst is a business problem solver, who sells change, sells business management and computer users the services of information technology. A systems analyst helps the business by solving its problems using system concepts and information technology.
- 65 -
KSOU
A systems analyst performs the following tasks: Interacting with the customers to know their requirements, with designers to convey the possible interface of the software. Interact/guide the coders/developers to keep track of system development.
Perform system testing with sample/live data with the help of testers. Implement the new system.
Prepare high quality documentation which is necessary during the development of proposed candidate system
A systems analyst is also responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals. Roles of system analyst: The role of the system analyst has been emerging with changing technology. The roles that an analyst performs are: Change Agent
- 66 -
KSOU
Investigator & Monitor Architect Psychologist Salesperson Motivator Politician
Change Agent: The analyst may be viewed as an agent of change. A candidate system is designed to introduce change and reorientation in how the user organization handles information or makes decisions. It is important then that the user accept change. The way to secure user acceptance is through user participation during design and implementation. In the role of a change agent, the system analyst may select various styles to introduce change to the user organization. When drastic changes are required, it may be necessary to adopt the confronter or even the imposer style, no matter what style is used, however, the goal is the same, to achieve acceptance of the candidate system with minimum resistance. Investigator and Monitor: The analyst pieces together the information gathered to determine why the present system does not work well and what changes will correct the problem. This work is similar to that of an investigator extracting the real problems from the existing system and creating information structures that uncover previously unknown brands, that may have a direct impact on the organization. Related to the role of the investigator is the role of the monitor, to undertake and complete a project successfully. The analyst must monitor programs in relation to time, cost and quality. If time gets away, the project suffers from increased costs and wasted human resources. Motivator:
- 67 -
KSOU
The motivational approach in system development states that the candidate system should satisfy the user's needs if they are going to use it. There are two types of relationships the first relationship is between effort and performance, the user determines the probability that a certain level of motivation or effort will improve job performance. The second important relationship is between performance and rewards to the extent that rewards are contingent upon performance motivation may be enhanced. Politician: Since information is a source of organizational power, the process of system development may be viewed as a contest for power where analysts have the initial advantage. System development is often viewed as a bargaining process where analysts and users attempt to enhance their power positions. A system that is simple to explain and easy to understand is more readily accepted than a technical presentation. The political factor prompts the analyst to honestly assess the motives of allergies involved and attempt to remove barriers that lead to system failure. System analyst skill set: An analyst must posses various skills to effectively carry out the job. Specially they are divided into following categories: Analytical Skills / Problem Solver Technical Skills Interpersonal Communication Skills Managerial Skills Business Skills
Analytical Skills: Analytical skill is the ability to visualize, articulate, and solve complex problems and concepts, and make decisions that make sense based on available information. Such
- 68 -
KSOU
skills include demonstration of the ability to apply logical thinking to gathering and analyzing information, designing and testing solutions to problems, and formulating plans. To test for analytical skills one might be asked to look for inconsistencies in an advertisement, put a series of events in the proper order, or critically read an essay. Usually standardized tests and interviews include an analytical section that requires examine to use their logic to pick apart a problem and come up with a solution. There is no question that analytical skills are essential, other skills are equally required. For instance in systems analysis the systems analyst should focus on four set of analytical skills: systems thinking, organizational knowledge, problem identification, and problem analyzing and solving. A successful analyst is a team player. Has the capacity to understand the organization. He should be an efficient problem-solver. He should have system thinking ability. The ability to examine a complex set of components without losing sight of the bigger picture is essential to an analysts success. Technical Skills: Understanding of potential and limitations of technology is one among the important technical skill that an analyst must have. He should have general skills as well. He should know various techniques that are used in system development. Knowledge about various tools those are available to carryout development process. Dynamic interface, Creativity is also required to perform efficiently. Dynamic interface is nothing but blending technical and non technical considerations in functional specifications and general design. Creativity will help in modeling the ideas into concrete plans and developing candidate systems to match user requirements. Questioning attitude and inquiring mind are the qualities of an efficient analyst. These qualities will help analyst in knowing the what, when, why, where, who and how a system works.
- 69 -
KSOU
Technical Skill is a working knowledge of the technology in the areas of database management, data networks, telecommunications, operating systems, distributed architectures, object technology, languages and protocols, etc. Interpersonal Communication Skills: Effective written and oral communication skills. A successful analyst is a good communicator. Includes the ability to question, listen, interview and observe. Effectively conduct oral and written presentations. Working alone and with a team. Facilitate groups, and be a team player. Systems analysts work in teams composed of IS professionals, end-users, and management. Being able to cooperate, to comprise, and to function as part of a team, is critical for success in most projects. Because development teams include people with dramatically different levels of education and experience, group dynamics is an important skill to develop. Managing expectations of the user as well as management is the top most responsibility of the analyst and interpersonal communication skills will play a very important role in meeting these expectations. Selling ideas & promoting innovations in problem solving. Teaching or educating others in use of computer system, selling system to users & giving support when needed. It refers to mental and communicative algorithms applied during social communications and interactions in order to reach certain effects or results. The term "interpersonal skills" is used often in business contexts to refer to the measure of a person's another. Having positive interpersonal skills increases the productivity in the organization since the number of conflicts is reduced. In informal situations, it allows communication to be easy and comfortable. People with good interpersonal skills can
- 70 -
ability
to
operate
within
business
organizations
through
social
communication and interactions. Interpersonal skills are how people relate to one
KSOU
generally control the feelings that emerge in difficult situations and respond appropriately, instead of being overwhelmed by emotion. Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent. They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management. Managerial Skills: Managerial skills includes business domain knowledge, resource management, project management, risk management, change management etc. Management in all business and human organization activity is simply the act of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the deployment and manipulation of human resources, financial resources, technological resources, and natural resources. Management activities involves scheduling, performing well under time constraints, coordinating team efforts and managing costs and expenditures. Business Skills: Systems analysts have broader skills than computer scientists. What you need to know about your organization. He must know how to identify a problem, how to analyze it and give best solution. Responsibilities of a system analyst:
- 71 -
KSOU
Conduct requirement analysis and system design.
Prepare project document deliverables including requirement specification, functional design specification, test plan & case, training materials and related documents .
Develop application or customization, and ensure user requirements fulfillment.
Testing of application features and customization.
Support user to perform user acceptance test.
Provide user training and support production rollout / system migration .
Provide ongoing support and maintenance after system rollout.
The fundamental activity of the modern systems analyst is that of problem identification and solution development.
Analyst Role Programmer/Analyst Systems Analyst Independent Analyst Outsource Provider Systems Consultant Software developer
Relationship to Organization Employee of the organization Employee of the organization Contractor to the organization Employee of outsourcing contractor Contractor to the organization Manufacturer or supplier of software
Table 6.1. Typical Analyst-Organization Relationships

- 72 -
KSOU
Module 3 Unit 7 Information Gathering Techniques - I

Information gathering is an art and a science. The approach and manner in which information is gathered require persons with sensitivity, common sense, and a knowledge of what an when to gather and what channels to use in securing information. The information gathering is neither easy nor routine. Much preparation, experience and training are required. This section addresses the categories and sources of information and the functions, uses and relevance of key information-gathering tools during the phases of system analysis. The phases are: 1. Familiarity with the present system through available documentation, such as procedures manuals, documents and their flow, interviews of the user staff, and on-site observation. 2. Defining the decision making with managing system. This is because for the determining what information is required of the system. Conducting interviews clarifies the decision points and how decisions are made in the user area.
- 73 -
KSOU
3. After identifying the decision points, a series of interviews are conducted to define the information requirements of the user. Analysis and documentation of the information gathered will be carried out. Identification of discrepancies between decision system and information gathered form information system are also done. This concludes the analysis and sets the stage for system design.
Sampling: Sampling is a technique for obtaining an estimate from a population by studying, measuring, or interviewing a subset (or sample) of that population. In this chapter we will discuss basic sampling concepts. Sampling is a process of collecting a representative sample of documents, forms, and records. Which involves organization chart, memos and other documents that describe the problem, standard operating procedures for current system, completed forms, manual and computerized screens and reports, samples of databases, flowcharts and other system documentation. Sampling is a process of systematically selecting representative elements of a population. Sampling is a fact-finding technique that involves a large number of observations taken at random intervals. A well-selected sample yields an estimate of the target parameters in much less time and at much less cost than studying, measuring, or interviewing the entire population (conducting a census). It is often impossible to achieve 100 percent response because some of the entities to be studied, measured, or interviewed are unavailable or do not respond. A sample is sometimes more accurate than a census because obtaining numerous measurements introduces errors owing to fatigue, inaccurate or inconsistent data entry, and the use of less qualified personnel. The sample answer, called an estimate, is almost never exactly the same as the corresponding population value. (This difference is called error.) Additionally, before a
- 74 -
KSOU
statistically valid sample can be selected, a great deal of information about the population must be available. Before conducting a sample, it is necessary to define the specific information being sought and the population from which the sample will be drawn. For example, if an analyst needs information about perceived weaknesses in the existing sales order tracking system, the population would consist of all the people who utilize the existing system. Sampling can be used to select the subset of a population to be interviewed the members of a JAD (Joint Application Development) team, or the members of an inspection team. Sampling is an effective way to study an existing system by selecting the entities, transactions, occurrences, or personnel to be observed and measured. Sampling is an effective tool for estimating population characteristics when using such mathematical tools as simulation and queuing theory. During the testing phase of the system development life cycle, sampling is used to generate test data and select the specific events to be monitored. During the operation and maintenance phase, sampling is an effective tool for evaluating and monitoring performance and for implementing system controls. For example, quality control is often implemented by taking random samples of a process. Sometimes the estimates generated by sampling a process are plotted on a control chart to determine if the process is in control. Why sample? Every year, Consumer Reports magazine conducts tests on new automobiles and reports its findings to its readers. Given the (literally) millions of automobiles that roll off the assembly lines every year, testing the entire population would be incredibly time consuming, prohibitively expensive, and practically impossible, so the test results are based on a sample. In many cases, testing a sample is actually more accurate than testing the entire population. A testers reactions and perceptions are likely to change between the first car and the tenth car, if only because of fatigue. Multiple tests mean considerable data, and data entry errors are inevitable. Multiple tests also imply multiple testers, not all of whom are equally skilled. Finally, the test conditions and criteria will almost certainly change over time. For example, if enough cars are crashed into a barrier, the barrier will eventually be deformed, thus changing the test conditions.
- 75 -
KSOU
Sampling comes before interviews and includes look for the organization chart, investigate project history, look for high level mission or policies, charters for each organization affected, processes and procedures in use. Need for sampling: The reasons systems analysts do sampling are Reduction of costs Speeding up the data-gathering process Improving effectiveness Reduction of data-gathering bias
If the sample is drawn properly, it is reasonable to assume that the sample estimate reflects the population. The balance of this chapter discusses the process of drawing a good sample. Sampling Design Steps To design a good sample, a systems analyst needs to follow four steps: Determining the data to be collected or described Determining the population to be sampled Choosing the type of sample Deciding on the sample size
Sample size and sampling error The difference between the sample estimate and the true population value is called error. As a general rule, the sampling error decreases as the sample size increases. For example, assuming a 95 percent confidence interval, a sample of 1,000 voters might predict the outcome of an election with an error of slightly more than plus or minus 3 percent. Increase the sample size to 4,000, and the error drops to plus or minus 1.5 percent, while a sample size of 10,000 reduces the error to less than plus or minus 1 percent. A useful formula for computing the sample size is:
- 76 -
KSOU
n = (z2_2) /E2, (9.1) where z is a number from the normal distribution table that corresponds to the desired confidence interval, _ is the standard deviation of the population as estimated by the sample standard deviation, and E is the maximum acceptable error between the sample mean and the actual population mean. For a 95 percent confidence interval, use z = 1.96. For a 99 percent confidence interval, use z = 2.575. As a practical matter, one-fifth the sample range can be used as an estimate of the standard deviation. For example, suppose you want to estimate the average amount of money a state university student spends on food and beverages in an average week. The maximum acceptable error is $2. Based on a preliminary sample, _ is estimated to be $8. The desired confidence interval is 95 percent. Plugging those numbers into Equation (9.1) suggests a sample size of: n = [(1.962)(82)] / 22 = 62.426 or 63 students. (It is impossible to sample a fractional student, and rounding up yields a confidence interval slightly higher than 95 percent.) Assuming the students answer truthfully, averaging the weekly food expenditures of 63 randomly selected university students will yield a value that is within $2 of the population average with 95 percent confidence. To put it another way, there is a 0.95 probability that the sample mean will lie within $2 of the true mean. ( Note: A real statistician would probably argue that the last statement is not technically correct, but in most cases it is a reasonable way to visualize a confidence interval.) Deciding Sample Size for Attribute Data Steps to determine sample size Determine the attribute to sample Locate the database or reports where the attribute is found Examine the attribute and estimate p, the proportion of the population having the attribute Make the subjective decision regarding the acceptable interval estimate, i Choose the confidence level and look up the confidence coefficient (z value) in a table Calculate p, the standard error of the proportion as follows: p = i/ z Determine the necessary sample size, n, using the following formula:
- 77 -
KSOU
n = (p(1-p) / p2) + 1
Sample Size for Data on Variables The steps to determine the sample size when sampling data on variables are Determine the variable you will be sampling Locate the database or reports where the variable can be found Examine the variable to gain some idea about its magnitude and dispersion It would be useful to know the mean to determine a more appropriate interval estimate and the standard deviation, s to determine sample size (in the last step) Make a subjective decision regarding the acceptable interval estimate, i Choose a confidence level and look up the confidence coefficient (z value) Calculate x, the standard error of the mean as follows: p = i/ z Determine the necessary sample size, n, using the following formula: n = (s/ x2)2 + 1 Types of sampling There are four types of sampling Convenience Purposive Simple random Complex random Convenience Convenience samples are unrestricted. They are non-probability samples. It is easy to arrange and most unreliable. Purposive
- 78 -
KSOU
This type of sampling is based on judgment. Analyst chooses group of individuals to sample. This is purely based on criteria. This is also a non-probability sample and it is moderately reliable. Bias Any factor that systematically favors some members of the population over others when a sample is drawn. Simply selecting the right sample size is not enough, however. For example, a sample taken outside an expensive restaurant and a sample taken outside a food bank will almost certainly yield two very different (and equally invalid) estimates of the weekly food expenditures of university students because those samples are likely to be biased. A biased sample systematically favors some members of the population over others. To cite another example, if a telephone book is used to select a sample, people with unlisted numbers, people who have recently moved into that telephone market, and people with no telephone are automatically excluded from the sample. Non-response bias occurs when one or more members of the selected group are not included in the sample. A survey that includes information only from people who answer their telephones at a certain time of day excludes one subset of the population. Dismissing or excluding people who refuse to answer certain questions is another source of non-response bias. Be aware of nonresponse bias. Before taking a sample, study the sampling process, identify subsets of the population that might be excluded or choose not to participate, and adjust the sampling process as necessary.
Random sampling One relatively easy way to avoid introducing bias is to sample randomly. A sample is considered random if each member of the population has the same chance of being selected. Random samples yield unbiased estimates. Generally, an unbiased estimate is high about half the time and low about half the time. There are two commonly used techniques for selecting a random sample. If the population is small, the members (or slips of paper representing each member) can be
- 79 -
KSOU
mixed thoroughly and the sample selected directly (like bingo markers or lottery tickets). For larger populations, assign each member a number and use a random number generator or a table of random numbers to select the sample. Simple random Based on a numbered list of the population. Each person or document has an equal chance of being selected. As the name specifies it easy and simple type of sampling. Complex random This sampling type again has three formsSystematic sampling Stratified sampling Cluster sampling Systematic sampling This is the simplest method of probability sampling, which chooses every kth person on a list to perform the sampling. Not good if the list is ordered. Cluster sampling In this type of sampling first selection of group of documents or people to study then select typical groups that represent the remaining ones. Random-like samples In cases where it is impossible or inconvenient to select a true random sample, the objective is to generate estimates that behave as though they were based on a random sample. The key to successful, almost random sampling is to avoid introducing bias. For example, imagine a grocer inspecting a shipment of fruit. An estimate based on a sample taken from a single box or even from the tops of several boxes is unlikely to accurately reflect the quality of all the fruit. However, if the grocer selects several boxes and then selects fruit from the top, the middle, and the bottom of each, the sample is likely to be random-like.
- 80 -
KSOU
On an assembly line, selecting every tenth, hundredth, or thousandth item (generally, every nth item) as it flows by might be an effective way to select a random-like sample. An option is to select every m nth item), where n is a random number (for example, every 100 5th item. Avoid predictability when sampling human beings, however, because it often introduces bias. For example, if the boss walks through the work area every hour on the hour, he or she is likely to find everyone hard at work. If another boss were to use a random number table to define the times for random visits to the work area, he or she is likely to gain a more accurate picture of the employees work habits.
Stratified random sampling This sampling begins with identifying subpopulations or strata, then selecting objects or people for sampling from the subpopulation. After this Compensates for a disproportionate number of employees from a certain group will take place. This is most important to the systems analyst. With stratified random sampling, a population of size N is divided into m subgroups. Each subgroup is called a stratum, and each member of the population must lie in exactly one stratum. For example, dividing a group of people by sex yields two strata (male and female); dividing a group of voters into Democrat, Republican, Independent, and Socialist yields four strata; and comparing the products produced on the first, second, and third shifts calls for three strata. Samples are taken randomly within each stratum. Stratified random sampling is important if the different strata have different means and/or different levels of variability. For example, suppose the newer, relatively inexperienced employees who work the third shift produce markedly more errors than the people who work the other two shifts. In such cases, stratified sampling tends to yield more accurate estimates than simple random sampling. Proportional allocation One technique for distributing a sample across several strata is called proportional allocation. If 200 employees are distributed over three shifts with 100 on first shift, 60 on
- 81 -
KSOU
second shift, and 40 on third shift, a reasonable sample distribution might be 50 percent first shift, 30 percent second shift, and 20 percent third shift. Optimal allocation If one stratum exhibits significantly more variability than the others, proportionally more samples should be taken from the inconsistent stratum. Also, if one stratum is more costly to measure or interview than another, proportionally fewer samples should be taken from the expensive stratum. Optimal allocation is a technique for distributing a sample across several strata that considers variability and cost. The optimum allocation formula is: (ni/ n) = [Wi_i/ (Ci1/2)] / _ [Wi_i / (Ci1/2)], (9.2) where ni is the number of samples in stratum i, n is the total sample size, Wi is the percentage of the population in stratum i, _i is the standard deviation of stratum i, and Ci is the cost to sample stratum i. The formula calculates a relatively larger sample size for a given stratum if its variability (measured by _ i) is higher than average or if the cost of sampling from that stratum is lower than average. For example, suppose n, the total sample size, is 500. The population is divided among three strata, with costs to sample of $3, $4, and $5 per item for strata 1, 2, and 3 respectively ( C1 = $3, C2 = $4, and C3 = $5). Stratum 1 contains 50 percent of the population ( W1 = 0.5), stratum 2 contains 30 percent of the population (W2 = 0.3), and stratum 3 contains 20 percent of the population (W3 = 0.2). Finally, the estimated standard deviations for the three strata are _1 = 1.5, _2 = 2, and _3 = 2.5. First calculate _(Wi_i/(Ci1/2)) = [W1_1/(C1 1/2)] + [W2 _2/(C2 1/2)] + [W3_3/(C3 1/2)] = [0.5(1.5) / (31/2)] + [0.3(2) / (41/2)] + [0.2(2.5) / (51/2)] 0.433 + 0 .300 + 0.224 = 0.957. Next, compute n1/n = 0.433/0.957 = 0.452 n2/n = 0.300/0.957 = 0.314 n3/n = 0.224/0.957 = 0.234.
- 82 -
KSOU
Those numbers suggest that n1 (the stratum 1 sample size) should be 45.2 percent (or 226 units) of the total sample size (500 items), n2 should be 31.4 percent (or 157 units), and n3 should be 23.4 percent (or 167 units).
Workflow Analysis Workflow analysis may reveal signs of larger problems, such as - data or information doesnt flow as intended, bottlenecks in the processing of forms, access to online forms is cumbersome, unnecessary duplication of work occurs because employees are unaware that information is already in existence, employees lack understanding about the interrelatedness of information flow. Scope of Data always depends on the type, what type of data and amount, quantity of the data. So identify the population and determine sample characteristics
Convenience Sample : No criteria; non-Random selection Simple Random Sample : No criteria; Random selection Purposeful Sampling : Criteria; non-Random selection Complex (Stratified) Random Sampling : Criteria; Random
If you know a lot about the consistency of data, can use statistical sampling techniques A random sample should be truly random, not just convenient. A stratified sample may be used to avoid important special cases.
Research & site visits Research may use various sources, such as: The Internet (e.g. for vendors) Trade and professional journals (AITP, AIS, IEEE, ACM, etc.) Company-specific intranets
- 83 -
KSOU
Government agencies (SEI, STSC, etc.)
Site visits are to see the existing system
Observation of the work environment involves the participation of, or watch the existing system being used, should determine what kind of data to collect, when, and how (what forms), should already understand the process being observed somewhat, and can use sampling for large numbers of observations. Determine who, what, where, why, and how, obtain permission from supervisor, inform subject of reason for visit, keep a low profile; dont interrupt, take copious notes, and review them, focus on important activities, dont make assumptions.
Investigation Preliminary Investigation, the purpose of carrying out this is to decide whether to continue the project or not. Objectives for a preliminary investigation are: 1. Understand the problem. 2. Define the project scope and constraints. 3. Identify the benefits. 4. Estimate the time and costs. 5. Report to management - Interaction with managers and users.
Steps in the Preliminary Investigation Step 1: Understand the problem, identify the true nature of the problem and the reason for the systems request, stated problem may not be the real problem, clear statement defines the investigation scope. Step 2:
- 84 -
KSOU
Define the project scope and constraints. Project scope involves defining the range or extent of the project, setting project boundaries. Constraints is nothing but identifying conditions, restrictions, or requirements - present vs. future, internal vs. external, mandatory vs. desirable. Step 3: Perform fact finding. It is a process of analyzing organization charts, conducting interviews, observing operations and carry out a user survey. Step 4: Determine feasibility - determining operational, technical, and economic feasibility.
Step 5: Estimate time and cost to continue development. This step involves determining of what information is needed, identifying the sources of information, decide whether to use interviews, if so how many, and what time needed. decide whether to use surveys, if so who to complete it, and what time needed, estimate the cost of gathering, analyzing, and reporting the information to management. Step 6: Present results and recommendations to management. This step is the final task in the preliminary investigation. The key elements of this step are - Evaluation of systems request, Estimate of costs and benefits, Recommendations, oral and written presentations submitted to management. Things to be gleaned from Documents Symptoms and causes of problems Persons in organization who have understanding of problem Business functions that support the present system Type of data to be collected and reported by the system Questions that need to be covered in interviews
- 85 -
KSOU
Observation Fact-finding techniques wherein the systems analyst either participates in or watches a person perform activities to learn about the system. Observation Guidelines Determine the who, what, where, when, why, and how of the observation. Obtain permission from appropriate supervisors. Inform those who will be observed of the purpose of the observation. Keep a low profile. Take notes. Review observation notes with appropriate individuals. Don't interrupt the individuals at work. Don't focus heavily on trivial activities. Don't make assumptions.
Interviewing: Interviewing is an important method for collecting data on information system requirements. A face-to-face meeting between two (or more) people in which one person obtains information from another by asking questions. It is a fact-finding technique whereby the systems analysts collect information from individuals through face-to-face interaction. During the problem definition, feasibility study, and analysis stages, interviewing is one of the analysts most important sources of information about the present system and the users requirements. The purpose of this brief introduction is to provide some suggestions for planning and conducting an interview. Interviews reveal information about - Interviewee opinions, Interviewee feelings, About the current state of the system, Organizational and personal goals, Informal procedures.
- 86 -
KSOU
Interview process starts with determining of the people to interview, then establishing objectives for the interview, developing interview questions, preparing for the interview, conduct the interview, document the interview, and evaluate the interview. The personal interview is generally recognized as the most important and most often used fact-finding technique. Systems analysts spend a great deal of time talking with people. Much of that time is spent conducting interviews. Written documentation often provides a one-dimensional view of the problem. Interviews, in contrast, give the analyst the opportunity to sit down face to face with the affected people, investigate their opinions, feelings, and goals (as well as the facts), observe nonverbal behavior, and probe for additional feedback. An interview can serve as an effective entry point to the problem definition and analysis stages, identifying relevant personnel and specific topics that must be investigated in more depth. Interviews are excellent tools for achieving user involvement in the system development process and for verifying information collected using other tools. Interviewing is time consuming and costly. Its effectiveness is a function of the interviewers skill. Not all subjects are comfortable being interviewed, and many people react negatively or defensively to an interviewers questions. Interviewing is not particularly effective for uncovering technical or operational details. Interviews can be used in virtually any stage of the system development life cycle. Interviewing is often one of the first tasks performed during the information gathering and problem definition stage. Interviews are often performed as part of conducting a survey. During the problem definition, feasibility study, and analysis stages, interviewing is one of the analysts most important sources of information about the present system and the users requirements. The purpose of this brief introduction is to provide some suggestions for planning and conducting an interview. Planning the Interview
- 87 -
KSOU
Five steps in planning the interview are Reading background material Establishing interview objectives Deciding whom to interview Preparing the interviewee Deciding on question types and structure
Preparing for the interview People resent interviewers who waste their time, so do your homework. Good interviewers do not just wing it. Effective interviewing requires careful preparation. Study the users environment. Identify the people responsible for the problem area. Study the organization chart and learn what those people do. Familiarize yourself with the available reports, documents, and procedures, note unanswered questions, missing pieces, and ambiguities, and develop a specific set of objectives for the interview. Unless you know what you want to learn (more accurately, unless you know what you do not know), you cannot ask intelligent questions. Prepare for the Interview by following some of the interview question guidelines: Schedule a specific day and time Place a reminder call Send a memo to managers Send a list of essential questions to an interviewee ahead of time Use clear and concise language. Dont include your opinion as part of the question. Avoid long or complex questions. Avoid threatening questions. Dont use you when you mean a group of people
Given a set of objectives, the next step is to select the person (or the group) to be interviewed. The organization chart is a good starting point. Interview the responsible
- 88 -
KSOU
manager first, get an overview of the problem, request the names of the people who know the details, and request permission to interview them. Failing to obtain appropriate authorizations for an interview is usually a mistake.
Scheduling the interview Interviews should be scheduled; do not simply drop in unannounced and expect cooperation. Remember that you are the one who needs information and that you are asking another person to give up his or her time to help you achieve your goals, so you must be willing to meet at the subjects convenience. Also, limit the length of the interview to no more than an hour; half an hour is better. Before you meet the subject, prepare a list of questions you hope to answer. The purpose of the list is to help you remember your objectives and to help you prevent the interviewee from dragging the interview off topic. Interviewees will talk about the details of their jobs, and it is easy to become distracted. In the beginning of the Interview to create comfortable atmosphere shake hands, remind them of your name and why you are there, take out note pad, tape recorder, make sure tape recorder is working correctly.
The Interview Itself (Interview Conduction) Procedure to Conduct an Interview 1. Select Interviewees End users Learn about individual prior to the interview
2. Prepare for the Interview interview guide

- 89 -
KSOU
3. Conduct the Interview Summarize the problem Offer an incentive for participation Ask the interviewee for assistance
4. Follow Up on the Interview Memo that summarizes the interview
A well-conducted interview has four parts: an opening, a body, a closing, and follow-up. The opening Be on time. If you know you are going to be late, call and give the subject the option to reschedule. The point of the opening is to establish rapport and to encourage the subject to respond freely. Identify yourself, the topic to be discussed, the purpose of the interview, and how long you expect the interview to last. Tell the subject why he or she was selected for the interview. Where appropriate, identify the manager or managers who authorized the interview. In an attempt to establish a relaxed atmosphere, many good interviewers begin with a period of small talk. While this technique can be effective, it can also backfire. Avoid wasting the subjects time. When in doubt, get to the point. Opening Questions - Start with pleasant conversation, open-ended questions, listen closely to early responses, and look for metaphors.
The body You are conducting the interview, so you are responsible for getting things going. Have your first question prepared. Many interviewers like to start with an open-ended question, such as: When I read the documentation for this system, I had some trouble with (mention the part or section). Can you explain it to me? During the Interview - The interview should not exceed 45 minutes to one hour, make sure that you understand what the interviewee is telling you, ask for definitions if needed, use probing questions.
- 90 -
KSOU
Consider asking the subject how his or her job relates to the project. Another good opener is to ask the subject to walk you through some process or to explain how he or she uses the data in a report. Listen to the answer. A good technique is to say something like, Let me see if I understand what youre saying, and then offer a brief summary. If you are wrong, the subject will probably tell you. If you can paraphrase correctly, you establish that communication is taking place. Check your list of questions occasionally. As the subject responds to an open-ended question, he or she will answer some of them before they are asked. Unanswered questions tell you what to ask next. Use follow-up questions, such as, Why? or Can you give me an example? to probe for additional details. Listen for the answers to questions you did not include on your list, too. One advantage of starting with an open-ended question is that (almost by definition) the subject knows more about the topic than you do. Consequently, your prepared questions might focus on the wrong issues or force the subject to cover key points in the wrong order. If you can get the subject to tell you what you should know, you can learn a great deal very quickly. Not all interviewers are comfortable with open-ended questions, however, and the interviewee might be nervous or even hostile. In such cases, it might be better to start with closed-ended questions that can be answered with a few words. (A forced-choice survey is an extreme example.) The answers to those questions, in turn, might suggest more open follow-up questions. Generally, skilled interviewers start with open-ended questions for their initial interviews, particularly with higher-level managers. As they learn more about the system and begin to hone in on specific issues, the questions become more closed and specific. Beginners, on the other hand, should consider preparing (perhaps with the help of an experienced interviewer) a list of closed questions, and let the responses suggest follow-up questions. During the interview, be careful not to concentrate so intently on your next question that you miss the answer to the current one. (This is a common beginners mistake.) Your list of prepared questions should be used as a guide or as a memory jog, not as a script. Listen to the answers. Delete questions that seem unimportant. Skip questions you know your subject cannot or will not answer. Bypass questions that have already been answered. Avoid needlessly complex or multi-part questions; ask one clear question at a time. Be flexible. Try to stick to the subject, and do not allow the interviewee to drag the interview
- 91 -
KSOU
off topic, but do allow a certain amount of spontaneity. You might learn something. Avoid technical jargon; take the time to learn the subjects application specific language. An interview is not a trial. Ask probing questions, but do not conduct a crossexamination. Finally, avoid attacking the subjects credibility or implying that you know more about the topic than the interviewee. (If the assumption is true, why conduct the interview?) You will sit through an occasional useless interview. An early closing might be in order, but always act professionally in spite of your disappointment. Unless you have an incredible memory, take notes. One suggestion is to leave space for notes on your list of questions or your interview outline. Do not take dictation, however. When you try to write down every word, you miss the speakers meaning, and you cannot ask probing follow-up questions if your attention is focused on a piece of paper. Be honest with yourself. If you feel compelled to take dictation, request permission to tape the interview or bring a secretary with you. The closing Pay attention to the time. If the interview runs longer than expected, ask permission to continue and offer to reschedule a follow-up interview. When you have the information you need, ask if there is anything you missed. (At this point, let the subject take the lead.) When the interview ends, thank the subject for cooperating and offer to make your written summary available for review. If you anticipate a follow-up or subsequent interview, say so. Some interviewers like to wind down with a brief period of casual conversation. If you feel comfortable with this approach, use it. Do not force it, though. Remember: avoid wasting the subjects time. Closing the Interview - Always ask Is there anything else that you would like to add?, summarize and provide feedback on your impressions, ask whom you should talk with next, set up any future appointments, thank them for their time and shake hands.
Follow-up As soon as possible after the interview, transcribe your notes. Ideally, they should identify key points; use your memory to fill in the details. (Dont wait too long, you might forget something important.) If you recorded the interview, listen to the tape and compile a set of selective notes. If appropriate, prepare a transcript. Type the summary. Identify the
- 92 -
KSOU
person, the date, the place, and the primary topic. Offer to share your summary with the subject; it is good public relations and it provides an excellent opportunity for correcting misunderstandings and errors. Also, the subject might add something you forgot. One or more follow-up interviews might be necessary. Consider using e-mail or the telephone to ask a question or two. If you need more than five minutes, schedule an appointment. In order to make successful interview we need to dress to match interviewee, Arrive on time, Or early if need to confirm room setup, Open interview by thanking interviewee, State purpose and length of interview and how data will be used, Monitor the time, Ask follow-up questions - Probe until you understand and Ask about exception conditions ("what if...") The step-by-step analysis of interview process: Step 1: Determine the People to Interview Informal structures Select the right people Consider informal structures Step 2: Establish Objectives for the Interview Determine the general areas to be discussed List the facts you want to gather Solicit ideas, suggestions, and opinions Step 3: Develop Interview Questions Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents Avoid leading questions Keep questions consistent Open-ended questions encourage spontaneous and unstructured responses Closed-ended questions restrict the response Range-of-response questions ask the person to evaluate something
- 93 -
KSOU
Step 4: Prepare for the Interview Careful preparation is essential because interview is an important meeting and not just a casual chat Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available Step 5: Conduct the Interview Develop a specific plan for the meeting. Begin by introducing yourself describing the project explain interview objectives Listen carefully - practice engaged listening Allow the person enough time to think about the question After interview, summarize the session and seek a confirmation Summarize the main points Explain the next course of action Introduce yourself Describe the project Explain your objectives Ask questions in order Step 6: Document the Interview Note taking should be kept to a minimum After the interview, record the information quickly Allow time between interviews After the interview, thank the interviewee with a memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections. Note the date, time, location, and purpose Review the main points discussed Step 7: Evaluate the Interview
- 94 -
KSOU
In addition to recording the facts obtained in an interview, try to identify any possible biases. Determine whether interviewees have necessary experience Unsuccessful Interviews Not all interviews are successful No matter how well you prepare for interviews, some are not successful Find a way to conclude an unsuccessful meeting Consider alternatives
Types of Interviews Unstructured interview An unstructured interview is conversational. Conducted with only a general goal or subject in mind and with few, if any, specific questions. The interviewer counts on the interviewee to provide a framework and direct the conversation. Structured interview A completely structured interview is planned and the plan is strictly followed. Closed questions are the basis of structured interviews. Interviewer has a specific set of questions to ask of the interviewee. Ten Tradeoffs: Structured and Unstructured Interviews Evaluation Amount of time required Training required Spontaneity allowed Reliability Flexibility Interviewee insight provided Interviewer control Precision Breadth and depth
- 95 -
KSOU
Question Types There are two basic types of interview questions: Open-ended Closed Open-Ended Questions Open-ended interview questions allow interviewees to respond how they wish, and to what length they wish. Open-ended questions are appropriate when the analyst is interested in breadth and depth of reply. This type of questions allows the interviewee to respond in any way. Provide more personal information about body language, inflection, tone, etc. Take a lot more time, but are often liked. It can be structured or unstructured (rare), Closed-Ended question A question that restricts answers to either specific choices or short, direct responses. Closed ended interview questions limit the number of possible responses. Closed interview questions are appropriate for generating precise, reliable data which is easy to analyze. The methodology is efficient, and it requires little skill for interviewers to administer. Advantages of Open-Ended Questions Putting the interviewee at ease Allowing the interviewer to pick up on the interviewee's vocabulary Reflect education, values, attitudes, and beliefs Providing richness of detail Revealing avenues of further questioning that may have gone untapped More interesting for the interviewee
- 96 -
KSOU
Allows more spontaneity Makes phrasing easier for the interviewer Useful if the interviewer is unprepared Give analyst opportunity to motivate interviewee to respond freely and openly Allow analyst to probe for more feedback Permit analyst to adapt or reword questions for each individual Can observe nonverbal communication Disadvantages of Open-Ended Questions May result in too much irrelevant detail Possibly losing control of the interview May take too much time for the amount of useful information gained Potentially seeming that the interviewer is unprepared Possibly giving the impression that the interviewer is on a "fishing expedition Time-consuming Success highly dependent on analyst's human relations skills May be impractical due to location of interviewees
Benefits of Closed Interview Questions Six benefits are Saving interview time Easily comparing interviews Getting to the point Keeping control of the interview Covering a large area quickly Getting to relevant data
- 97 -
KSOU
Disadvantages of Closed Interview Questions Four drawbacks of closed interview questions include Boring for the interviewee Failure to obtain rich detail Missing main ideas Failing to build rapport between interviewer and interviewee
Bipolar Questions Bipolar questions are those that may be answered with a yes or no or agree or disagree. Bipolar questions should be used sparingly. Probing Questions Probing questions elicit more detail about previous questions. The purpose of probing questions is - to get more meaning, to clarify, to draw out and expand on the interviewee's point. Question Pitfalls Avoid leading questions, those that imply an answer. Leading questions tend to guide interviewees into responses apparently desired by the interviewer. These questions should be avoided to reduce bias and improve reliability and validity. Avoid doublebarreled questions, asking two questions at once. These questions should be avoided because interviewees may answer only one question, leading to difficulties in interpretation. Question Sequencing There are three basic ways of structuring interviews:
- 98 -
KSOU
1. Pyramid structure starts with closed questions and working toward openended questions. It begins with very detailed, often closed questions. Expands by allowing open-ended questions and more generalized responses. Is useful if interviewees need to be warmed up to the topic or seem reluctant to address the topic. 2. Funnel structure - starts with open-ended questions and working toward closed questions. It begins with generalized, open-ended questions. Concludes by narrowing the possible responses using closed questions. Provides an easy, non-threatening way to begin an interview. Is useful when the interviewee feels emotionally about the topic 3. Diamond - starts with closed, moving toward open-ended, and ending with closed questions. A diamond-shaped structure begins in a very specific way. Then more general issues are examined. Concludes with specific questions. Is useful in keeping the interviewee's interest and attention through a variety of questions. Recording the Interview Interviews can be recorded with tape recorders or notes. Audio recording should be done with permission and understanding. Advantages of Audio Recording the Interview The four advantages are: Providing a completely accurate record of what each person said Freeing the interviewer to listen and respond more rapidly Allowing better eye contact and better rapport Allowing replay of the interview for other team members
- 99 -
KSOU
Disadvantages of Audio Recording the Interview The four disadvantages are: Possibly making the interviewee nervous and less apt to respond freely Possibly making the interviewer less apt to listen since it is all being recorded Difficulty in locating important passages on a long tape Increasing costs of data gathering Advantages of Note Taking During Interviews Keeping the interviewer alert Aiding recall of important questions Helping recall of important interview trends Showing interviewer interest in the interview Demonstrating the interviewer's preparedness Disadvantages of Note Taking During Interviews Losing vital eye contact Losing the train of conversation Making the interviewee hesitant to speak when notes are being made Causing excessive attention to facts and too little attention to feelings and opinions Before conducting the Interview contact the interviewee and confirm the interview, dress appropriately, arrive a little early, affirm that you are present and ready to begin the interview. Interviewing Dos and Donts
- 100 -
KSOU
Do Don't Assume an answer is finished or leading nowhere Reveal verbal and nonverbal clues Use jargon Reveal personal biases Talk more than listen Assume anything about the topic or the interviewee Tape record (take notes instead) Dress appropriately Be courteous Listen carefully Maintain control of the interview Probe Observe mannerisms and nonverbal communication Be patient Keep interviewee at ease Maintain self-control Finish on time
Body language the nonverbal information we communicate. Facial disclosure Eye contact Posture
Fact finding - The first step is to identify the information you need. Develop a factfinding plan. Software helps you gather and analyze facts; however, it cannot perform fact-finding for you. Who, What, When, Where, and How? Who performs the procedures within the system?
- 101 -
KSOU
What is being done? Where are operations being performed? When is a procedure performed? How is a procedure performed? Another important question Why?
Interview Report A report consists of the entire details about the interview should be generated for further references. Write as soon as possible after the interview Provide an initial summary, then more detail Review the report with the respondent
- 102 -
KSOU
Unit 8 Information Gathering Techniques - II

Questionnaires A special-purpose document that allows the analyst to collect information and opinions from respondents. Questionnaires are useful in gathering information from key organization members about attitudes, beliefs, behaviors, characteristics. Questionnaires are valuable if organization members are widely dispersed, many members are involved with the project, exploratory work is needed, problem solving prior to interviews is necessary. Questionnaire design One of the best ways to reduce error when conducting a sample survey is to carefully design the questionnaire to be used. There are several important considerations that must be kept in mind when designing a questionnaire. Questionnaires are an inexpensive way to gather data from a potentially large number of respondents. Often they are the only feasible way to reach a number of reviewers large enough to allow statistically analysis of the results. A well-designed questionnaire that is used effectively can gather information on both the overall performance of the test system as well as information on specific components of the system. If the questionnaire includes demographic questions on the participants, they can be used to correlate performance and satisfaction with the test system among different groups of users. It is important to remember that a questionnaire should be viewed as a multi-stage process beginning with definition of the aspects to be examined and ending with interpretation of the results. Every step needs to be designed carefully because the final results are only as good as the weakest link in the questionnaire process. Although questionnaires may be cheap to administer compared to other data collection methods, they are every bit as expensive in terms of design time and interpretation.
- 103 -
KSOU
The steps required to design and administer a questionnaire include: Defining the Objectives of the survey Determining the Sampling Group Writing the Questionnaire Administering the Questionnaire Interpretation of the Results
This document will concentrate on how to formulate objectives and write the questionnaire. Before these steps are examined in detail, it is good to consider what questionnaires are good at measuring and when it is appropriate to use questionnaires. What can questionnaires measure? Questionnaires are quite flexible in what they can measure, however they are not equally suited to measuring all types of data. We can classify data in two ways, Subjective vs. Objective and Quantitative vs. Qualitative. When a questionnaire is administered, the researchers control over the environment will be somewhat limited. This is why questionnaires are inexpensive to administer. This loss of control means the validity of the results are more reliant on the honesty of the respondent. Consequently, it is more difficult to claim complete objectivity with questionnaire data then with results of a tightly controlled lab test. For example, if a group of participants are asked on a questionnaire how long it took them to learn a particular function on a piece of software, it is likely that they will be biased towards themselves and answer, on average, with a lower than actual time. A more objective usability test of the same function with a similar group of participants may return a significantly higher learning time. More elaborate questionnaire design or administration may provide slightly better objective data, but the cost of such a questionnaire can be much higher and offset their economic advantage. In general, questionnaires are better suited to gathering reliable subjective measures, such as user satisfaction, of the system or interface in question.
- 104 -
KSOU
Questions may be designed to gather either qualitative or quantitative data. By their very nature, quantitative questions are more exact then qualitative. For example, the word "easy" and "difficult" can mean radically different things to different people. Any question must be carefully crafted, but in particular questions that assess a qualitative measure must be phrased to avoid ambiguity. Qualitative questions may also require more thought on the part of the participant and may cause them to become bored with the questionnaire sooner. In general, we can say that questionnaires can measure both qualitative and quantitative data well, but that qualitative questions require more care in design, administration, and interpretation. When to use a questionnaire? There is no all encompassing rule for when to use a questionnaire. The choice will be made based on a variety of factors including the type of information to be gathered and the available resources for the experiment. A questionnaire should be considered in the following circumstances. When resources and money are limited. A Questionnaire can be quite inexpensive to administer. Although preparation may be costly, any data collection scheme will have similar preparation expenses. The administration cost per person of a questionnaire can be as low as postage and a few photocopies. Time is also an important resource that questionnaires can maximize. If a questionnaire is self-administering, such as a e-mail questionnaire, potentially several thousand people could respond in a few days. It would be impossible to get a similar number of usability tests completed in the same short time. When it is necessary to protect the privacy of the participants. Questionnaires are easy to administer confidentially. Often confidentiality is the necessary to ensure participants will respond honestly if at all. Examples of such cases would include studies that need to ask embarrassing questions about private or personal behavior. When corroborating other findings.
- 105 -
KSOU
In studies that have resources to pursue other data collection strategies, questionnaires can be a useful confirmation tools. More costly schemes may turn up interesting trends, but occasionally there will not be resources to run these other tests on large enough participant groups to make the results statistically significant. A follow-up large scale questionnaire may be necessary to corroborate these earlier results. Question ordering The order in which questions are asked can affect the responses to the questions. One reason for this is that respondents try to answer questions in a consistent fashion. As an example, we consider an example originally discussed. An experiment involved asking two questions: 1. Do you think the United States should let Communist newspaper reporters from other countries come in here and send back to their papers the news as they see it? 2. Do you think a Communist country like Russia should let American newspaper reporters come in and send back to America the news as they see it? In surveys conducted in 1980, when question 1 was asked first, 54.7 percent of respondents answered yes to question 1 and 63.7 percent answered yes to question 2. When question 2 was asked first, 74.6 percent answered Errors of non-observation occur because the elements in a sample are respondents sense of fair play led more respondents to approve of Communist reporters being allowed to report news in the United States as they see it when they had first approved of U.S. reporters doing the same in Communist countries. We should also point out that a respondents reaction to a question can be set by asking preliminary questions dealing with the same topic and that the first question asked is often thought of differently from questions that follow. For instance, the responses to a question about government spending might be very favorable to increased government spending if the question is preceded by several questions emphasizing useful services provided by the government. In contrast, the responses might be opposed to increased government spending if the question is preceded by several questions emphasizing government waste and inefficiency. As an example of how the first question asked can be thought of
- 106 -
KSOU
differently from the questions that follow, when questions ask the respondent to supply ratings, the first question tends to be given the most extreme rating. For instance, when people are asked to rate the appeal of resort hotels based on descriptive materials, if the first hotel seems appealing it would likely be rated higher than other appealing hotels that are subsequently rated. On the other hand, if the first hotel is not appealing, it would likely be rated lower than other equally unappealing hotels that are subsequently rated. In addition, the ordering of question responses can also influence survey results. Often, the first choice (or first several choices) in a list of choices are more likely to be selected than are later choices. Moreover, if a choice is long, complicated, or difficult to understand or interpret, the choice that precedes the difficult choice is likely to be selected. In order to reduce the impact of question ordering and response ordering, one strategy is to vary the orders of questions and/or responses presented to different respondents. Another approach is to carefully describe the context in which each survey question was asked in the analysis of the survey results.
Writing the Questionnaire If the preceding steps have been faithfully executed, most of the questions will be on obvious topics. Most questionnaires, however, also gather demographic data on the participants. This is used to correlate response sets between different groups of people. It is important to see whether responses are consistent across groups. For example, if one group of participants is noticeably less satisfied with the test interface, it is likely that the interface was designed without fair consideration of this group's specific needs. This may signify the need for fundamental redesign of the interface. In addition, certain questions simply may only be applicable to certain kinds of users. For example, if one is asking the participants whether they find the new tutorial helpful, we do not want to include in our final tally the responses of experienced users who learned the system with an older tutorial. There is no accurate way to filter out these responses without simply asking the users when they learned the interface.
- 107 -
KSOU
Typically, demographic data is collected at the beginning of the questionnaire, but such questions could be located anywhere or even scattered throughout the questionnaire. One obvious argument in favor of the beginning of the questionnaire is that normally background questions are easier to answer and can ease the respondent into the questionnaire. One does not want to put off the participant by jumping in to the most difficult questions. We are all familiar with such kinds of questions. It is important to ask only those background questions that are necessary. Do not ask income of the respondent unless there is at least some rational for suspecting a variance across income levels. There is often only a fine line between background and personal information. You do not want to cross over in to the personal realm unless absolutely necessary. If you need to solicit personal information, phrase your questions as unobtrusively as possible to avoid ruffling your participants and causing them to answer less than truthfully.
Question Types Questions are designed as either Open-ended or Closed Open questions and closed questions When an open question is posed, the respondent is allowed to formulate any answer that he or she wishes. Open questions try to anticipate the response you will get. Well suited for getting opinions and useful in explanatory situations. On the other hand, a closed question requires one of several predetermined choices (such as a, b, c, or d) or requires a single numerical response (such as the number of years a respondent has spent in his or her current job position). Closed questions are used when all the options may be listed and when the options are mutually exclusive. Closed
- 108 -
KSOU
questions are advantageous because it is easy to summarize and analyze the responses to such questions (especially when a computer is used). On the other hand, open questions allow the respondent to express ideas and nuances that the designer of the questionnaire may not have considered. However, it might be very difficult to summarize and interpret the responses to open questions because the responses cannot be easily quantified. yes to question 1 and 81.9 percent answered yes to question 2. What kind of questions do we ask? In general, there are two types of questions one will ask, open format or closed format. Open format questions are those that ask for unprompted opinions. In other words, there are no predetermined set of responses, and the participant is free to answer however he chooses. Open format questions are good for soliciting subjective data or when the range of responses is not tightly defined. An obvious advantage is that the variety of responses should be wider and more truly reflect the opinions of the respondents. This increases the likelihood of you receiving unexpected and insightful suggestions, for it is impossible to predict the full range of opinion. It is common for a questionnaire to end with and open format question asking the respondent for her unabashed ideas for changes or improvements. Open format questions have several disadvantages. First, their very nature requires them to be read individually. There is no way to automatically tabulate or perform statistical analysis on them. This is obviously more costly in both time and money, and may not be practical for lower budget or time sensitive evaluations. They are also open to the influence of the reader, for no two people will interpret an answer in precisely the same way. This conflict can be eliminated by using a single reader, but a large number of responses can make this impossible. Finally, open format questions require more thought and time on the part of the respondent. Whenever more is asked of the respondent, the chance of tiring or boring the respondent increases.
- 109 -
KSOU
Closed format questions usually take the form of a multiple-choice question. They are easy for the respondent, give. There is no clear consensus on the number of options that should be given in an closed format question. Obviously, there needs to be sufficient choices to fully cover the range of answers but not so many that the distinction between them becomes blurred. Usually this translates into five to ten possible answers per questions. For questions that measure a single variable or opinion, such as ease of use or liability, over a complete range (easy to difficult, like to dislike), conventional wisdom says that there should be an odd number of alternatives. This allows a neutral or no opinion response. Other schools of thought contend that an even number of choices is best because it forces the respondent to get off the fence. This may induce the some inaccuracies for often the respondent may actually have no opinion. However, it is equally arguable that the neutral answer is over utilized, especially by bored questionnaire takers. For larger questionnaires that test opinions on a very large number of items, such as a music test, it may be best to use an even number of choices to prevent large numbers of no-thought neutral answers. Closed format questions offer many advantages in time and money. By restricting the answer set, it is easy to calculate percentages and other hard statistical data over the whole group or over any subgroup of participants. Modern scanners and computers make it possible to administer, tabulate, and perform preliminary analysis in a matter of days. Closed format questions also make it easier to track opinion over time by administering the same questionnaire to different but similar participant groups at regular intervals. Finally closed format questions allow the researcher to filter out useless or extreme answers that might occur in an open format question. Whether your questions are open or closed format, there are several points that must by considered when writing and interpreting questionnaires: 1. Clarity: This is probably the area that causes the greatest source of mistakes in questionnaires. Questions must be clear, succinct, and unambiguous. The goal is to eliminate the chance that the question will mean different things to different people. If the designers fails to do this, then essentially participants will be answering different questions.
- 110 -
KSOU
To this end, it is best to phrase your questions empirically if possible and to avoid the use of necessary adjectives. For example, it asking a question about frequency, rather than supplying choices that are open to interpretation such as: Very Often Often Sometimes Rarely Never
It is better to quantify the choices, such as: 1. Every Day or More 2. 2-6 Times a Week 3. About Once a Week 4. About Once a Month 5. Never There are other more subtle aspects to consider such as language and culture. Avoid the use of colloquial or ethnic expressions that might not be equally used by all participants. Technical terms that assume a certain background should also be avoided.
2. Leading Questions: A leading question is one that forces or implies a certain type of answer. It is easy to make this mistake not in the question, but in the choice of answers. A closed format question must supply answers that not only cover the whole range of responses, but that are also equally distributed throughout the range. All answers should be equally likely. An obvious, nearly comical, example would be a question that supplied these answer choices: 1. Superb 2. Excellent 3. Great 4. Good 5. Fair
- 111 -
KSOU
6. Not so Great A less blatant example would be a Yes/No question that asked: Is this the best CAD interface you have every used? In this case, even if the participant loved the interface, but had an favorite that was preferred, she would be forced to answer No. Clearly, the negative response covers too wide a range of opinions. A better way would be to ask the same question but supply the following choices: 1. Totally Agree 2. Partially Agree 3. Neither Agree or Disagree 4. Partially Disagree 5. Totally Agree This example is also poor in the way it asks the question. It's choice of words makes it a leading question and a good example for the next section on phrasing.
3. Phrasing: Most adjectives, verbs, and nouns in English have either a positive or negative connotation. Two words may have equivalent meaning, yet one may be a compliment and the other an insult. Consider the two words "child-like" and "childish", which have virtually identical meaning. Child-like is an affectionate term that can be applied to both men and women, and young and old, yet no one wishes to be thought of as childish. In the above example of "Is this the best CAD interface you have every used?" clearly "best" has strong overtones that deny the participant an objective environment to consider the interface. The signal sent the reader is that the designers surely think it is the best interface, and so should everyone else. Though this may seem like an extreme example, this kind of superlative question is common practice. A more subtle, but no less troublesome, example can be made with verbs that have neither strong negative or positive overtones. Consider the following two questions: Do you agree with the Governor's plan to oppose increased development of wetlands?
- 112 -
KSOU
Do you agree with the Governor's plan to support curtailed development of wetlands? They both ask the same thing, but will likely produce different data. One asks in a positive way, and the other in a negative. It is impossible to predict how the outcomes will vary, so one method to counter this is to be aware of different ways to word questions and provide a mix in your questionnaire. If the participant pool is very large, several versions may be prepared and distributed to cancel out these effects. 4. Embarrassing Questions: Embarrassing questions dealing with personal or private matters should be avoided. Your data is only as good as the trust and care that your respondents give you. If you make them feel uncomfortable, you will lose their trust. Do not ask embarrassing questions. 5. Hypothetical Questions: Hypothetical are based, at best, on conjecture and, at worst, on fantasy. I simple question such as: If you were governor, what would you do to stop crime? This forces the respondent to give thought to something he may have never considered. This does not produce clear and consistent data representing real opinion. Do not ask hypothetical questions. 6. Prestige Bias: Prestige bias is the tendency for respondents to answer in a way that make them feel better. People may not lie directly, but may try to put a better light on themselves. For example, it is not uncommon for people to respond to a political opinion poll by saying they support Samaritan social programs, such as food stamps, but then go on to vote for candidates who oppose those very programs. Data from other questions, such as those that ask how long it takes to learn an interface, must be viewed with a little skepticism. People tend to say they are faster learners than they are. There is little that can be done to prevent prestige bias. Sometimes there just is no way to phrase a question so that all the answers are noble. The best means to deal with prestige bias is to make the questionnaire as private as possible. Telephone interviews are better than person-to-person interviews, and written questionnaires mailed to participants are even better still. The farther away the critical eye of the researcher is, the more honest the answers.
- 113 -
KSOU
Response options and screening questions When a question is posed, sometimes the respondent would like to answer by stating that he or she has no opinion or does not know how to answer. Therefore, when constructing a questionnaire, one must decide whether a no opinion option will be included among the responses to the various questions. Generally, no opinion responses provide little useful information, and, therefore, such responses are often not allowed. On the other hand, it does not seem reasonable to require a response when the respondent may not have the information needed to intelligently formulate a response. As a general rule, when a question requests an opinion about a subject that everyone (or almost everyone) is familiar with, a no opinion option is not allowed. For instance, a question about whether federal income taxes are too high might be posed without a no opinion option. On the other hand, a question whose answer requires a specialized background or very specific knowledge might be posed with a no opinion option. For example, a question about a little known and seldom used tax provision would probably include a no opinion option. A common strategy is to use screening questions. Such questions are posed in order to determine whether or not a respondent has enough knowledge or information to answer the main question. If a respondent does not know enough to answer the main question, the main question is skipped. If a respondent does have the needed background, he or she is asked to answer the main question and this main question is posed without a no opinion option. Besides deciding whether to include a no opinion option, one must decide how many options will be employed. Because middle ground responses often give respondents an easy out, questions are often posed without a middle ground or neutral option. For instance, the question: For instance, in a market research study we might ask the open question: attempts to elicit a response on one side of the taxation issue or the other with no neutral response allowed. If we believe that it will be too difficult for many respondents to choose one side or the other, then more response options should be included. In general, however, it is a good idea to keep the number of response options as small as possible.
- 114 -
KSOU
Wording of questions The language and phrasing used in constructing questions is also an important consideration. Seven basic principles of question construction: 1. Be clear and precise. A question must be understandable and must elicit a precise answer. For instance, the question How many cola drinks do you consume? is too vague. A better version would be: Here is a 16 ounce bottle of a cola drink. If all of the cola you drink came in 16 ounce bottles, how many would you consume in a week? State a number. 2. Response choices should not overlap The response choices should not overhand should be exhaustive. lap and should cover all relevant possibilities. 3. Use natural and familiar language. Questions should be phrased using words and expressions that respondents will understand. For instance, the question, Do you think that every public building should be equipped with a bubbler?, will be understood in Wisconsin because in that state a water fountain is called a bubbler, but this question will not be understood elsewhere in the United States. 4. Do not use words or phrases that Do not use wordings that suggest what show bias. the answer to a question should be (that is, do not use loaded questions). In addition, questions should be asked in a balanced way. For instance, the question, Do you favor the death penalty? should be asked in the more balanced form, Do you favor or oppose the death penalty? 5. Avoid double-barreled questions. Double-barreled questions are questions that ask the respondent to answer two questions at the same time. In your opinion, are taxes in the United States too high or too low? slow paced and are too expensive?, contains two questions. They should be separated.
- 115 -
KSOU
6. State explicit alternatives. For instance, if we wish to investigate the desirability of DSS satellite systems, the question, Would you purchase a DSS satellite system?, does not supply as much information as the question, If you currently subscribe to cable television and DSS satellite television were available to you, would you: 1. subscribe to cable only, 2. purchase a DSS satellite system only, 3. subscribe to cable and purchase a DSS satellite system. 7. Questions should meet criteria of Questions must measure what the validity and reliability. researcher is trying to measure (validity) and responses should be able to be replicated by other researchers (reliability). When designing questions one must keep in mind that people do not emember facts very well. Also, people do not determine frequencies by counting. Rather, they determine a rate for a shorter period and then multiply (for instance, I consume 3 cases of soft drinks per month, which when multiplied by 12 gives a yearly consumption of 36 cases). Finally, people telescope easily remembered events so that they believe that they occurred in a shorter period of time than they actually did. On the other hand, events that are difficult to remember are believed to have occurred longer ago than they actually did. The speed of completion of open-ended questions are slow, where as close-ended questions are fast. Exploratory nature of the open-ended questions are high compared to closed questions. Breadth and depth of the closed questions are low, but for open-ended questions they are high. Ease of operation is easy in open-ended, where as for closed it difficult. Ease of analysis if difficult for open-ended where as for closed it is easy. Questionnaire language should be simple, specific, free of bias, not patronizing, technically accurate, addressed to those who are knowledgeable, appropriate for the reading level of the respondent. Questionnaires must be valid and reliable. Reliability of scales refers to consistency in response, getting the same results if the same questionnaire was administered again under the same conditions. Validity is the degree to which the question measures what the analyst intends to measure. Formatting the Questionnaire
- 116 -
KSOU
Good response rates can be achieved with consistent control of questionnaire Format Style Meaningful ordering Clustering of questions Questionnaire format when designing - allow ample white space, allow enough space for responses to be typed for open-ended questions, ask respondents to clearly mark their answers, use objectives to help determine format, be consistent in style. Meaningful ordering of questions is must. Most important questions go first, similar topics should be clustered together, randomization of questions tries the patience of respondents, and controversial questions should be positioned after less controversial questions. Web Form Questionnaires Controls (fields) used on Web forms Single line text box Scrolling text box, used for one or more paragraphs of text Check box for yes-no or true-false answers Radio button for mutually exclusive yes-no or true-false answers Drop-down menu for selection from a list Submit or Clear buttons Methods of Administering the Questionnaire Methods of administering the questionnaire include Convening All concerned respondents together at one time Personally administering the questionnaire Allowing respondents to self-administer the questionnaire Mailing questionnaires Administering over the Web or via email
- 117 -
KSOU
Electronically Submitting Questionnaires Administering a questionnaire electronically has many benefits Reduced costs Collecting and storing the results electronically Free-format questionnaire A questionnaire designed to offer the respondent greater latitude in the answer. A question is asked, and the respondent records the answer in the space provided after the question. Fixed-format questionnaire A questionnaire containing questions that require selecting an answer from predefined available responses. Can be efficient for large audiences But hard to guarantee responses, or fairness Can use free format, but hard to analyze Fixed format may include: Advantages Often can be answered quickly People can complete at their convenience Relatively inexpensive way to gather data from a large number Allow for anonymity Responses can be tabulated quickly Multiple choice (Y/N or A/B/C/..) Rating (5-point from strongly agree to strongly disagree) Ranking (importance, or % or time)
Disadvantages
- 118 -
KSOU
Return rate is often low No guarantee that an individual will answer all questions No opportunity to reword or explain misunderstood questions Cannot observe body language Difficult to prep
Types of Fixed-Format Questions Multiple-choice questions Rating questions Ranking questions
Rank the following transactions according to the amount of time you spend processing them. ___%new ___ % order cancellations ___ % order modifications ___ % payments customer orders
The implementation of quality discounts would cause an increase in customer orders. ___StronglyAgree ___ Agree ___ No opinion ___Disagree ___ Strongly disagree
Is
the
current
accounts
receivable
report
that
you
receive
useful? ___Yes
___ No
- 119 -
KSOU
Developing a Questionnaire 1. Determine what facts and opinions must be collected and from whom you should get them. 2. Based on the facts and opinions sought, determine whether free- or fixed-format questions will produce the best answers. 3. Write the questions. 4. Test the questions on a small sample of respondents. 5. Duplicate and distribute the questionnaire.
Questionnaire design is a long process that demands careful attention. A questionnaire is a powerful evaluation tool and should not be taken lightly. Design begins with an understanding of the capabilities of a questionnaire and how they can help your research. If it is determined that a questionnaire is to be used, the greatest care goes into the planning of the objectives. Questionnaires are like any scientific experiment. One does not collect data and then see if they found something interesting. One forms a hypothesis and an experiment that will help prove or disprove the hypothesis. Questionnaires are versatile, allowing the collection of both subjective and objective data through the use of open or closed format questions. Modern computers have only made the task of collecting and extracting valuable material more efficient. However, a questionnaire is only as good as the questions it contains. There are many guidelines that must be met before you questionnaire can be considered a sound research tool. The majority deal with making the questionnaire understandable and free of bias. Mindful review and testing is necessary to weed out minor mistakes that can cause great changes in meaning and interpretation. When these guidelines are followed, the questionnaire becomes a powerful and economic evaluation tool.
- 120 -
KSOU
Unit 9 Information Gathering Techniques - III

The art of prototyping has evolved from the use of pen-and-paper layout charts to being the basis for Evolutionary Prototyping, a full methodology for developing software systems. While prototyping is discussed in introductory systems analysis and design courses, students gain a better appreciation of the technique by actually developing different types of prototypes. For example, prototyping is an excellent vehicle for demonstrating the overlapping of phases in the SDLC. This paper reviews the ways in which prototyping may be used in the system development life cycle and then presents examples of how prototyping can be infused into an undergraduate course in systems analysis and design. Students can develop discovery and user-interface prototypes using HTML and JavaScript modules. The development of functional prototypes using a scripting language and MS Access is also presented. Prototyping A prototype is a working physical model of a system or a subsystem. Generally, the analysts (or information consultants) objective is to gather information about the users requirements from the bottom up by allowing the user to interact with the prototype. In
- 121 -
KSOU
effect, the prototype serves as a preliminary version of the system or component from which requirements are extracted and on which subsequent versions are based. A prototype is an excellent tool for analyzing and designing an interactive application and/or a user interface and to support object-oriented system development. During the analysis stage, prototyping can be used to replace or supplement logical modeling, particularly when the users are uncomfortable with abstract models. Prototyping is valuable on projects with long development times because the user gets to see something physical. Prototyping is an excellent tool when the requirements are highly uncertain or too abstract to specify, or when no comparable system has been previously developed. Generally, if reaching a solution calls for simulation, experimentation, or incremental evaluation, prototyping might be a reasonable choice. During the analysis stage, prototyping can be used to replace or supplement logical modeling. Variations on the standard prototyping approach include evolutionary prototyping, incremental prototyping, and middle-out prototyping Creating a large, complex system from the bottom up can be very difficult, and integrating subsystem prototypes can prove almost impossible because there is no clear way (short of a parallel top-down logical or data model) to visualize subsystem relationships. Prototyping is not a good choice for algorithm-driven projects that involve heavy calculation. Prototyping can bias the systems analysis process in subtle ways. Because the prototype is developed on a computer, the system will almost certainly be implemented on a computer and manual alternatives are unlikely to be considered. Because it is a working model, people will inevitably think of the prototype as the solution. A related danger is that the system will never be developed properly because the prototype seems too good. Prototypes generally lack security, auditing, and other controls, and data integrity may be difficult to ensure. Additionally, prototypes are often inefficient and difficult to maintain. For example, it is difficult to trace the ripple effects that result from modifying a prototype, and that affects maintainability. Economy of scale is another problem; prototypes that test well sometimes fail when the number of users is dramatically increased.
- 122 -
KSOU
Before creating a prototype, it is necessary to at least partially define the problem and gather preliminary information. Also, it may be necessary to perform a preliminary analysis and/or create logical models to help plan and (later) to supplement the prototype. Prototyping is a powerful, bottom up alternative or supplement to logical modeling. The basic idea is to build a reasonably complete, working, physical model (or prototype) of the system. As a minimum, the analyst can use screen painters, menu builders, and report generators to prepare a slide show of sample screens, dialogues, and reports. In a more complete prototype, preliminary working versions of the systems programs are created using a fourth-generation language, spreadsheets, database software, or a similar end-user tool. Prototype is a preliminary, working, physical model of a system, a subsystem, or a program. Prototyping is the act of creating a prototype. Discovery Prototyping Prototyping, or discovery prototyping, tends to use very specialized tools, and may define and refine prototypes with direct user involvement. Can be part of a RAD development approach. Highly iterative; helps clarify requirements. Easy to omit quality and performance requests. The act of building a small-scale, representative or working model of the users requirements in order to discover or verify those requirements. Prototyping is an information-gathering technique. Prototypes are useful in seeking user reactions, suggestions, innovations, and revision plans. Two main problems with the SDLC: Extended time required to go through the development life cycle. User requirements change over time. So prototyping may be used as an alternative to the systems development life cycle. Advantages:
- 123 -
KSOU
Can experiment to develop understanding of how system might work Aids in determining feasibility and usefulness of system before development Serves as training mechanism Aids in building test plans and scenarios May minimize time spent on fact-finding
Disadvantages: Developers may need to be trained in prototyping Users may develop unrealistic expectations Could extend development schedule
Use of prototyping in software development methodologies Specification-based methodologies, such as traditional structured methodologies, use "throwaway" prototypes. Throwaway prototypes are developed for a specific, limited purpose and then discarded. This type of prototype can be used for different purposes in each of the phases of software development. In the Planning Phase Demonstration prototypes are developed to portray the user interface of the proposed system. The purpose is to provide a "vivid demonstration" of proposed software to managers and customers to garner support for the project. In the Analysis Phase Discovery prototypes are used as an aid in determining user requirements. Allowing users to experiment with a prototype interface helps to refine requirements that were specified as the basis for the prototype's construction and elicit new requirements that may have been overlooked. Feasibility prototypes also are used in the analysis phase to evaluate new technology such as new software development tools or aspects of the proposed system architecture. In the Design Phase User-interface prototypes are used to design the format of screens and reports and to design the human-computer dialogue. Feasibility/Performance prototypes are used to evaluate the design of system components such as database
- 124 -
KSOU
systems and schema, network architecture, algorithms, and system controls. These types of prototypes are particularly valuable when developing an innovative system or when using a new technology. In the Implementation Phase Feasibility/Performance prototypes are used for the same purposes as in the design phase but would typically be more finely focused. Prototypes can also be used in the implementation phase to begin training users before the system is fully functional and to cross-test system components by comparing system test results to those obtained from corresponding prototypes. Prototype-based methodologies are centered on the development of an evolutionary prototypethat would initially contain a minimal set of high priority features and then "is augmented and changed as new requirements are discovered" [14, p.174]. The prototype ultimately becomes the system. These methodologies perform "the analysis, design, and implementation phases concurrently and all three phases are performed repeatedly in a cycle until the system is completed" [4, p. 11]. Examples of this type of methodology are Boehm's Spiral Model and Rapid Application Development (RAD). In addition to developing an evolutionary prototype, prototype-based methodologies can incorporate throwaway prototypes much the same as the specification-based methodologies. In prototype-based methodologies throwaway prototypes (most likely Feasibility/Performance prototypes) would be constructed for special purposes as adjuncts to the evolutionary prototype. The prototyping process The prototyping process can be viewed as a loop. Following problem definition and preliminary analysis, a first draft of the prototype is created. The user then interacts with the prototype and identifies its strengths and weaknesses. Assuming that the first draft is less than totally acceptable, the prototype is modified to reflect the users suggestions and the user interacts with the new, improved version. The refine-and-test cycle continues until the user is satisfied that the prototype meets his or her requirements. During the refine-and-test cycle, the emphasis is on quick turnaround, with changes made on the spot or within at most a few days. Instead of conceptualizing needs, the users work with and react to the prototype and the analyst observes and interprets their reactions.
- 125 -
KSOU
To many people, manipulating a working model seems more natural than answering questions in an interview or trying to link an abstract model to reality. Sometimes, the prototyping process continues until a finished system emerges. Usually, however, the purpose of the prototype is to clarify the systems requirements. The tasks and queries performed by the prototype demonstrate what the system must do and translate into processes. Screens, dialogues, menus, reports, files, and databases map to the required logical data structures. Once the requirements are defined, design begins and the prototype is discarded. Variations on the standard prototyping approach include evolutionary prototyping, incremental prototyping, and middle-out prototyping. Prototype Development Guidelines Guidelines for developing a prototype are: Work in manageable modules. Build the prototype rapidly. Modify the prototype in successive iterations. Stress the user interface. The basic steps are: 1. Identify the users information and operating requirements. 2. Develop a working prototype that focuses on only the most important functions, using a basic database. 3. Allow the user to use the prototype, discuss requested changes, and implement the most important changes. 4. Repeat the next version of the prototype with further changes incorporated until the system fully meets the user requirements.
Identify user requirements Analyze prototype

- 126 -
KSOU
input, processing, output Implement prototype Final conversion

Post Implementation
Revise through iterative process Maintenance
Figure 9.1 System development life cycle with Prototyping
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front. When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified. There are a few different approaches that may be followed when using the Prototyping Model: creation of the major user interfaces without any substantive coding in the background in order to give the users a "feel" for what the system will look like. development of an abbreviated version of the system that performs a limited subset of functions, development of a paper system (depicting proposed screens, reports, relationships etc.), or use of an existing system or system components to demonstrate some functions that will be included in the developed system. Prototyping is comprised of the following steps:
- 127 -
KSOU
Requirements Definition/Collection. Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements. Design. Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype. Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding. Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer. Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient. System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornerstone for the fully functional system. Four Kinds of Prototypes: The four conceptions of prototypes are : Patched-up prototype. Non-operational scale model. First-of-a-series(First full-scale model). Prototype that contains only some of the essential system features. Patched-up prototype
- 128 -
KSOU
This is a working model with all the features but is inefficient Users can interact with the system Storage and retrieval of data may be inefficient Workable but inefficient May contain only basic features Non-operational scale model A non-operational scale mode is one which is not operational, except for certain features to be tested Prototype input and output First full-scale model Create a pilot system An operation model Useful when many installations of the same information system are planned An example is a system to be installed in one location, tested and modified as necessary, and later implemented in other locations
Selected Features Prototype Prototype which contain only some of the essential system features An operational model that includes some, but not all, of the final system features With the acceptance of these features, later essential features are added Some menu items are available System is built in modules These are part of the actual system
- 129 -
KSOU
Prototype advantages Potential for changing the system early in its development Opportunity to stop development on an unworkable system Possibility of developing a system that closely addresses users needs and expectations Prototype disadvantages Managing the prototyping process is difficult because of its rapid, iterative nature. Requires feedback on the prototype Incomplete prototypes may be regarded as complete systems. Problems/Challenges associated with the Prototyping Model Criticisms of the Prototyping Model generally fall into the following categories: Prototyping can lead to false expectations. Prototyping often creates a situation where the customer mistakenly believes that the system is "finished" when in fact it is not. More specifically, when using the Prototyping Model, the pre-implementation versions of a system are really nothing more than one-dimensional structures. The necessary, behindthe-scenes work such as database normalization, documentation, testing, and reviews for efficiency have not been done. Thus the necessary underpinnings for the system are not in place. Prototyping can lead to poorly designed systems. Because the primary goal of Prototyping is rapid development, the design of the system can sometimes suffer because the system is built in a series of "layers" without a global consideration of the integration of all other components.
Initial User Reactions Reactions must be gathered from users There are three types
- 130 -
KSOU
User suggestions Innovations Revision plans The Users Role The users role is honest involvement. Three ways the user is involved: Experimenting with the prototype. Giving open reactions to the prototype. Suggesting additions to and/or deletions from the prototype.
Prototype Evaluation Systems analysts must work systematically to elicit and evaluate users' reactions to the prototype Three ways the user is involved Experimenting with the prototype Giving open reactions to the prototype Use a prototype evaluation form Suggesting additions to and/or deletions from the prototype Prototyping on the Web Prototyping on the Web can help to facilitate the prototyping process by Allowing users at a distance review the prototype and send comments Allowing users to review the prototype when they have time, and on any machine that has Internet capabilities The analyst does not have to install the software on the users computer
Prototyping vs. conventional approaches
- 131 -
KSOU
Conventional systems analysis and design relies on various models of the system, and the logical analysis and physical design stages are clearly distinguished. Prototypes, in contrast, are generally created using a fourth generation language(Fourth-generation language- A non-procedural language that generates the appropriate source or executable code from a programmers definition or description of a logical operation.) or an application generator(Application generator (generator, program generator) - A program that starts with information in graphical, narrative, list, or some other logical form and generates the appropriate source or executable code.) using a mix of programming and systems analysis skills because analysis, design, and programming activities are often intermixed and difficult to distinguish. Prototyping is (by its very nature) iterative. The process starts with a set of partial requirements, and new or expanded requirements are continuously incorporated into the system based on user feedback. Consequently, Prototyping is a cyclic process. The requirements can be viewed as floating, or dynamic. In contrast, conventional systems analysis and design calls for a full and complete set of requirements, and the requirements are typically frozen at the end of each stage in the system development life cycle. Over the last decade prototyping has become a very valuable technique in software development methodologies. It is important that information systems students understand the various types of prototypes used and the roles they play in a SDLC. This paper suggests that this goal is better achieved by having students develop various types of prototypes. A set of prototypes to be developed as assignments in an undergraduate course in systems analysis and design and the software required for their implementation was presented.
UNIT 10
SYSTEM ANALYSIS TOOLS - 1
Data flow diagram
Today, systems design focuses on function of the system and later deciding the requirements for the physical implementation the system. Data flow diagram (DFD) is
- 132 -
KSOU
one of the tools used by systems analyst for system analysis. It represents the essential functions of an information processing system in a highly abstract way using a minimum set of symbols. A data flow diagram are used to represent several components of any system including its sources, destinations, processes, data storages as well interaction between these components. Data flow diagrams can be used both to describe existing system and to design new system. In other words, a data flow diagram is a process-oriented graphical representation of a system. According to Hoffer, George and Valacich, a DFD "is a picture of the movement of data between external entities and the processes and data stores within a system." The data flow diagrams are the basis of structured systems analysis. A data flow diagram acts as a bridge between users and systems developers. Thus a data flow diagram is a: Graphical representation that eliminates thousands of words; Logical representations that represents WHAT a system does, rather than physical models showing HOW it does it; Hierarchical representation illustrating systems at any level of detail and Jargonless representation that allow user to clearly understand and review the system. Data flow diagram being one of the most popular analysis tools avoids the cost of: User/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system. Having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes. Systems inefficiencies because a system gets "computerized" before it gets "systematized". Being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope.
Data Flow Diagram Symbols

- 133 -
KSOU
A data flow diagram uses four basic symbols external entity, data flow, process and data store. There are two conventions in for data flow diagram. One developed by Yourdon and De Marco and the other developed by Gane and Sarson. The only difference between them is the symbols used. The Gane and Sarson convention uses labelled straight arrows (vectors) for the data. It uses rectangles with rounded corners and a vertical long axis for the processes. Processes may have a reference number at the top in a small ruled off section. A data store is an open-ended rectangle with the long axis horizontal. Sources / sinks are shadowed squares, with a bold black outline behind them. This representation is also called the LST method. The Yourdon convention use circles for the process, and the term process bubble has arisen from this use; the extra identification information given in LST is often absent. A straight heavy line (sometimes double) is a used data store. The data flow lines are arched and free flowing, again with arrowheads for direction. Table 10.1 illustrates these conventions. DeMarco & Yourdon Convention Gane & Sarson Convention
External Entity
3.1
Process
Data Flow
- 134 -
KSOU
Data Store
Table 10.1: DFD Symbols
External Entity
External entity refers to any person, place or anything that performs the activity of sending or receiving data from the system without performing any information processing. External entity can be a source or a sink. A source is an entity from which data is received into the system. A clerk who enters data into a Billing system is a source. A sink is an entity, which receives data from the system. A customer who receives an invoice from an Billing system is a sink. However, in some cases the same entity can be both a source and a sink. For example, a customer is the source of an order and a sink for an invoice. In simpler terms, external entities are called sources if they are external to the system and provide data to the system, and sink if they are external to the system and receive information from the system. Entity name should be represented through a noun.
Data Flow
Data flow represents the flow of data between processes, data stores and external entities. A data flow also depicts direction of data flow within system, which is indicated by the arrowhead with the name that uniquely describes the contents of the flow next to it. Data flows cannot go between data store and data stores because some processing needs to be carried out before data can be stored in a data store - this may be simple processing like validation or updating records but it must be processed before it can be moved from one data store to another.
- 135 -
KSOU
Data flows cannot go between external entity and data store because it needs to be processed - we do not want a situation where people from outside of the organization can access or change data in our data stores directly without going through our processes - we may want external users to be able to access certain parts of our data but we will always want to control the way they do it. Thus, Data can flow from external entity to process, process to external entity, process to store and back and finally from process to process. Similarly data cannot flow from external entity to external entity, external entity to store, store to external entity and store to store
- 136 -
KSOU
Process
Process is the main building block of a data flow diagram. A process depicts the activities within a system that transforms data. Data may either exist within the system, or has just been received from an external entity. Thus, a processes represent data oriented activities performed within the organization. Process name should be represented through a verb, which clearly indicates what processing takes place on the data received by the process. For a process to be complete, it needs to have both an input and an output. Data Store A data store illustrates where information is held within the system. Data stores are represented using open-ended rectangles, which contain an identifier and the data stores name. A data store can be viewed as a computer file, a manual record in a filing cabinet, a pile of documents of one type, or a wall chart. It is a collection of related information - a telephone book, patient records, student records even a shopping list can all be viewed as data stores. Data stores receive information for storing and also provide data for further processing. Direct flows of information between two data stores are not possible. A data store is passive. It does not suddenly jump up and throw data to another data store.
Logical and Physical Data Flow Diagram

A logical data flow diagram describes the processes or activities that occur within the given system and the flow of data into and out of these processes. A logical data flow diagram does not specify by whom, how and where the activities have been conducted. A logical data flow diagram focuses on the business and how the business operates. It is not concerned with how the system will be constructed.
- 137 -
KSOU
A physical data flow diagram shows how the system will be implemented including the hardware, software, files, and people involved. A physical data flow diagram extends the information portrayed in context diagram by including all the internal entities participate in the processes. Thus, a logical data flow diagram contains information about the business and the physical data flow diagram contains information about the computerized system.
- 138 -
KSOU
Developing logical and physical data flow diagrams

The logical data flow diagram should be composed before the physical data flow diagram. The data flow diagram from the old system can be used as a basis for creating the data flow diagram for the new system to ensure that important features from the old system remain in the new one. Once the logical data flow diagram for the new system is created, it can be used as a basis to create a physical data flow diagram for the new system. The physical data flow diagram should be created after the logical data flow diagram. It should contain the following information: Manual processes Processes for adding, deleting, changing, and updating records Data entry and verifying processes. Validation processes for ensuring accurate data input Sequencing processes to rearrange the order of records Processes to produce every unique system output Intermediate data stores Actual file names used to store data Controls to signify completion of tasks or error conditions.
Advantages of logical data flow diagram include: It provides better communication with users because it is centered on the business activities the workers are involved with. It is more stable systems because the they are based on business events and not on a specific technology It helps analyst to have a better understanding of the business It is both flexible and easy to maintain because the technologies behind the new system will change more often than the technologies used to power the system. Advantages of physical data flow diagram include: It helps in categorizing manual and automated processes. The processes are defined in detail. The processes are sequenced.
- 139 -
KSOU
Names of files and printouts are identified.
Physical data flow diagrams are usually more complex than logical data flow diagrams because of the many data stores present in a system.
- 140 -
KSOU
Advantages and disadvantages of data flow diagram

The advantages of data flow diagram include: 1. It helps technical and non-technical users to easily understand systems design. 2. It helps in validating the correctness of the system. It is therefore easy to determine whether requirements are correct. The probability of a better system is increased. 3. It allows the analyst to abstract to whatever level of detail is required so that it is possible to examine a system in overview and at a more detailed level. 4. It specifies the system at a logical level rather than a physical level i.e. it shows what the system will do rather than how it will be done. 5. It helps to understand the inter-relatedness of systems and subsystems of the system. 6. It provides a means of analysis of a proposed system to determine if the necessary data and processes have been defined.
The disadvantages of data flow diagram include:

1. If the system to be deigned is a large system then, it is time consuming and complex task to produce all necessary levels of data flow diagram to represent such a system.
2. It can be difficult to read, understand and appreciate the flow of data and processing activities at a first glance. 3. No standardization of the symbols has been made. Thus different models use different symbols for structuring a data flow diagram.
- 141 -
KSOU
Steps for constructing a data flow diagram

The steps for constructing a data flow diagram are: Identify and list all external entities providing inputs to the system and / or receiving outputs from system. Identify the central objective of the system. Create a context diagram with the central objective of the system being at centre . Indicate external entities sending and receiving data flows to the system. Identify different processes, data flows and data stores to be included within the system boundary for further decomposition. Identify the data connections between different processes. Confirm the identified requirements through the concerned personnel. Trace and record what happens to each of the data flows entering the system (data movement, data storage, data transformation/processing) Verify all data flows have a source and destination. Verify data coming out of a data store goes in. Redraw the to simplify the design if possible. Review the constructed and simplified diagram.
Decomposing / Levelling a data flow diagram

A complex system such as the real systems used in industries cannot be described in a single data flow diagram. Instead analysis of such systems can be done through a hierarchically related set. The set depicts the decomposition of the system into successively finer detail. Thus the whole system represented through a single data flow diagram often called a context diagram is further partitioned into lower-level diagrams that are uniquely identified by number. The numbering scheme follows these conventions: Each child diagram takes the number of the corresponding bubble on its parent diagram. Bubbles on the child diagram are identified through a decimal point and a sequential number to the diagram number. Thus every bubble number shows its place in the hierarchy of transformations and permits its ancestry to be traced to the top.
- 142 -
KSOU
The process of dividing or portioning a single data flow diagram into number of lowerlevel diagrams is called levelling or decomposition.
Context data flow diagram A context data flow diagram or context diagram is the broadest data flow diagram. A Context data flow diagram represents a system at a high level of detail in terms of its inputs from external entities and its outputs to external entities. It is also known as an Overview or Level 0 DFD. A context diagram comprises one process (bubble) for the entire system, together with the external entities and the data flows that pass between them and the system. The context diagram does not contain any data stores. The main objective of the context diagram is to identify and examine the interfaces between the external entities and the system. The context diagram is considered to be the most general diagram and the broadest possible conceptualization of the system. Note: Some authors consider the context diagram to differ from level 0 i.e. the next level. In such cases level 0 diagram is also called a physical data flow diagram and the lower levels i.e. level-1, level-2, etc, are called logical data flow diagrams. Level 1 data flow diagram A level 1 data flow diagram depicts the system in more detail form as represented by a context data flow diagram. It depicts how input enters the system, how processes transform the input and how the output leaves the system. A level 1 diagram must have exactly the same inputs and outputs as the context diagram. The data stores and all external entities are included in the Level 1 Diagram. In a level 1 data flow diagram flows are connected to and from the actual processes. It can also include lower-level data flows.
- 143 -
KSOU
Thus, a level 1 diagram represents a breakdown of the activities that make up the system. Each of the processes are numbered as 1, 2, 3, 4 and so on. Level 2 data flow diagram A level 2 diagram may exist for every or some of the processes of a level 1 diagram. It represents the process of a level 1 diagram at a more detailed level. In appearance it is the same as a level 1 diagram but differs in notation. If the level 1 process being considered has the identifier 1, then the level 2 processes will be identified as 1.1, 1.2, 1.3, 1.4, etc. A level 2 diagram cannot produce output or receive input that are not produced or received by the corresponding process at level 1. In other words, all the inputs and output received and sent by a process at level 1 must also be shown by a corresponding process of level 2.
- 144 -
KSOU
Note The levelling or decomposition of a data flow diagram can be done until the processes represented are logically simple (until they cannot further be broken down). Advantages of levelling The advantages of levelling or decomposing a data flow diagram are: It enhances the readability. It is easier to identify errors before design. It reduces clustering. It represents a system at required degree of detail.
DFD Levelling Example -1 Precision Tools sells a line of high-quality woodworking tools. When customers place orders on the companys Web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse, which fills the order. When the order is shipped, the customer is billed. The system also produces various reports, such as inventory reports for Accounting. Draw a context diagram for the order system Draw a level 0 diagram for the order system
Identify Entities, Process, Data Stores & Data Flow

Entities Customer Warehouse Accounting
Processes Check Status Issue Status Messages Generate Shipping Order Manage Accounts Receivable
- 145 -
KSOU
Produce Reports
Data Stores D1 Pending Orders D2 Accounts Receivable
- 146 -
KSOU
Data
Flows Order In-Stock Request Order Data Status Data Status Message Shipping Order Order Data Invoice Shipping Confirmation Payment Accounting Data Accounts Receivable Data Order Data Inventory Reports
- 147 -
KSOU
DFD Levelling Example -2 A system is required which allows a user to input an unordered list of integer numbers into a computer. The system will store these numbers in the main store of the computer where they are to be sorted by the system into ascending numeric order and re-stored. Finally the system is to print out the list for the user. (a) Draw a context diagram for this problem. (b) Draw a level 1 data flow diagram for this problem.
User
Unordered
List
of
Ordered
Printed List
of
Number System
User
Fig 10.3: Context DFD for Number System
Get List of Numbers

1
Sort Fig. 10.2 Level 0 DFD for Order System Numbers
into Ascending Order

- 148 -

2 Unordered List of Numbers 1 User User Unordered List of Integer Numbers Ordered List of Numbers
KSOU
Print List of Numbers

3 2 Printed Ordered List of Numbers
- 149 -
KSOU
DFD Levelling Example 3 Consider a typical DVD rental system. Assuming the required external entities, data stores, processes and data flows (a) Draw a context diagram for this system. (b) Draw a flow diagram for this Fig 10.4: Level 1 DFD for Number System level 1 data sytem.
Customer DVD Store DVD Rental System 0 Hire Invoice Check Available Payment Issue Invoice
Fig 10.5: Context DFD for DVD rental system
DVD Store Available Reply Available Video / audio Store Send/Receive request Customer Hire Invoice
- 150 -
KSOU
Payment Details Payment 2.0 Cash Credit card Check/Reply for availability 1.0
Fig 10.6: Level 1 DFD for DVD rental system
- 151 -
KSOU
DFD Levelling Example 4 Given a context data flow diagram for an order processing system as illustrated in figure 10.7, construct a level 1 data flow diagram for the same.
Order Order Reject Notice Picking List Completed Order Payment Invoice Commission Bank Deposit Cash Receipts Entry
- 152 -
Fig 10.7: Context DFD for Order processing
KSOU
For the above given context diagram the level 1 data flow diagram is illustrated below in figure 10.8 Guidelines for Constructing Data Flow Diagrams Data flow diagrams are constructed using a top-down approach. In the top-down approach, analyst begins at a broadest level and then explodes each piece of the preceding level until the system is completely specified. Today, most of the systems are being designed using reuse based engineering techniques i.e. system development are based on a system already in operation. Therefore, in the majority of cases it is impractical to ignore totally the existing system. For the systems analyst, examining the existing system offers an opportunity to become familiar with current practice, and also to gain the user's confidence. The development of a DFD will assist with this understanding. A current physical DFD shows what happens to data within the current system, how it is processed, where and by whom. Guidelines for Constructing a Context Diagram Read the problem from start to end a finite number of times and analyze what the system actually does. Make a list of external entities. An external entity may be a person or place. The external entities either provide some input to the system or receive some output from the system. However not all persons and places mentioned in problem be external entities. Once external entities are identified, establish the flows that need to be sent and received to or from the system. Once all the above steps are followed, the context diagram can be drawn for the given problem.
Guidelines for Fig 10.8: Level 1 DFD for Order processing Constructing a system Data flow
Level 1 Diagram
Take each sentence of the problem and decide if it is background information or if it is an activity that must be represented by a process in the diagram. Verbs in a sentence represent a process.
- 153 -
KSOU
Make a list of all processes that exist in the problem. Group the processes so that you end up with approximately 3 to 10 processes. A level 1 or level 2 data flow diagram must contain a minimum of 3 processes and a maximum of 7 to 9 processes. In most of the situations, a level 1 diagram will rarely contain less than 5 processes while a level 2 diagram will have fewer.
Identify and list all the data flows. The data flows are normally documents. However, some times they can also be phone calls, physical items. Identify and list data stores. Data stores are normally the files or databases used to store the information. Once all the above said components are identified a level 1 data flow diagram can be drawn. After drawing the level 1 diagram, make sure that it is fully connected. Finally, validate the level 1 diagram against the context diagram to ensure that they are consistent.
Guidelines for Constructing a Level 2 Data flow Diagram For each level 1 process make a list of sub-processes, each one of which will become a process on the corresponding level 2 diagram. Once all the components required for a level 2 diagram are identified a level 2 data flow diagram can be drawn. Validate the level 2 diagram against the level 1 diagram to ensure that they are consistent.
Step by step DFD Construction An Example

In the following example, a data flow diagram will be created after reading each sentence about Bebop Records Co.s method of receiving and filling orders. Bebop Records is a mail-order company that distributes CDs and tapes at discount price to record-club members. When an order-processing clerk receives an order form, he or she verifies that the sender is a club member by checking the Member file. If the sender is not a member, the clerk returns the order along with a membership application form. If the customer is a member, the clerk verifies the order item data by checking the Item file. Then the clerk enters the order data and saves it to the Daily Orders file. The clerk also prints an invoice and shipping list for each order, which are forwarded to Order Fulfillment.
- 154 -
KSOU
- 155 -
KSOU
FIRST SENTENCE: Bebop Records is a mail-order company that distributes CDs and tapes at discount price to record-club members. RESULT: initial title
Bebop Records
SECOND SENTENCE: When an order processing clerk receives an order form, he or she verifies that the sender is a club member by checking the Member file.
- 156 -
KSOU
THIRD SENTENCE: If the sender is not a member, the clerk returns the order along with a membership application form.
FOURTH SENTENCE: If the customer is a member, the clerk verifies the order item data by checking the Item file.
- 157 -
KSOU
FIFTH SENTENCE: Then the clerk enters the order data and saves it to the Daily Orders file.
- 158 -
KSOU
SIXTH SENTENCE: The clerk also prints an invoice and shipping list for each order, which are forwarded to Order Fulfillment.
Errors in data flow diagram construction

Common errors that arise in constructing a data flow diagram include: Forgetting to include a data flow or pointing an arrowhead in the wrong direction: This would lead to a process lacking either input or output. Remember that processes must have both input and output. Connecting Data stores and external entities to each other: Data stores and external entities cannot be connected directly. If required, they must be connected only through a process. This is analogous to a database that does not interact directly with the user without the help of an intermediary program. The user may input data, but the data will always be processed before it is stored or outputted. Incorrectly labeling processes or data flow: The labeling of process and data flows should be done as specified in the standards listed earlier in the unit. Including more than nine processes on a data flow diagram: A data flow diagram not should have more than seven to nine processes. This creates a cluttered diagram. If more than nine are required, the diagram will have to be exploded further into another child diagram. Omitting data flow: If a process requires input from multiple data sources, make sure all of the sources are included. Not having the same input and output in the child diagram that is in the parent diagram: During decomposition all the inputs and output received and sent by a process at level 1 must also be shown by a corresponding process of level 2. Evaluating Data Flow Diagrams for Correctness Data flow diagrams can be evaluated to determine the correctness. Errors, omissions and inconsistencies can occur for several reasons, including mistakes in drawing the
- 159 -
KSOU
diagrams. But the presence of what appears to be an error may in fact point out a deficiency in the system or a situation in which users are not aware of how certain processes operate. These questions are useful in evaluating data flow diagrams: Are there any unnamed components in the data flow diagram (data flows, processes, stores, inputs or outputs)? Are there any data stores that are input but never referenced? Are there any processes that do not receive input? Are there any processes that do not produce output? Are there any processes that serve multiple purposes? If so, simplify by exploding them into multiple processes that can be better studied). Are there data stores that are never referenced? Is the inflow of data adequate to perform the process? Is there excessive storage of data in a data store (more than the necessary details)? Is the inflow of data into a process too much for the output that is produced? Are aliases introduced in the system description? Is each process independent of other processes and dependent only on the data it receives as input?
UNIT 11
SYSTEM ANALYSIS TOOLS 2 Case Studies
Case Study 1: Order Processing System Precision Tools sells a line of high-quality woodworking tools. When customers place orders on the companys Web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse,
- 160 -
KSOU
which fills the order. When the order is shipped, the customer is billed. The system also produces various reports, such as inventory reports for Accounting. Draw a context diagram for the order system Draw a level 0 diagram for the order system
To draw a context diagram the first step is to identify Entities, Processes, Data Stores & Data Flows of the given system. Accordingly, by reading the case study of the Precision Tools, we can identify the following Entities, Process, Data Stores & Data Flow:
Entities Customer Warehouse Accounting
Processes Check Status Issue Status Messages Generate Shipping Order Manage Accounts Receivable Produce Reports
Data Stores D1 Pending Orders D2 Accounts Receivable
- 161 -
KSOU
Data Flows Order In-Stock Request Order Data Status Data Status Message Shipping Order Order Data Invoice Shipping Confirmation Payment Accounting Data Accounts Receivable Data Order Data Inventory Reports
For the above (Figure 11.1) context diagram, the equivalent level 0 data flow diagram is illustrated in figure 11.2
- 162 -
KSOU
Case Study 2: Online University Registration System The system should enable the staff of each academic department to examine the course offered by their department, add and remove course, and change the information about them (e.g., the maximum number of students). It should permit students to examine currently available courses, add and drop courses to and from their schedules, and examine the course for which they are enrolled. Department staff should be able to print a variety of reports about the courses and the students enrolled in them. The system should ensure that no student takes too many course and that students who have any unpaid fees are not permitted to register. (Assume that a fees data store is maintained by the university's financial office that the registration system accesses but does not change.) For the above case study draw a context diagram and illustrate the process of levelling of the context diagram.
Context diagram
Fig. 11.2 Level 0 DFD for Order System
Department Staff Course information Course offerings

- 163 -
KSOU
Students
0
Course Registration System Enrollment information Student schedules
Fig. 11.3 Context diagram Online
- 164 -
KSOU
Level 0 data flow diagram
3
Course Enrollment Reports D3 Enrollments D2 Course Offerings D1 Fees Course Offering 2 List Course Offering Changes 1 Maintain department course offerings Course Offerings
Available courses Maintain student enrollments Course Offering Updates Available courses
Available course request Available courses Course enrollment Student schedule Students
Course information
Fee Payment History
Student Enrollment Report Request Student Enrollment Report Dept Staff Enrollment information
Fig. 11.4 Level 0 DFD for Online Registration System
- 165 -
Course enrollment request
Student schedule
KSOU
- 166 -
KSOU
Level 1 data flow diagram for process 1

Dept. Staff Produce course offering list Add new course Department ID Department ID D2 Course Offerings Course to delete Course modifications Course Offering List Request Course offering list New Course information New Course Delete course Modify
Fig. 11.5 Level 1 DFD for Online Registration System - 1 - 167 -
KSOU
existing courses Course to delete Course modifications Existing Course information 1.1 1.2 1.3 1.4
- 168 -
KSOU
- 169 -
KSOU
Obtain current schedule D1 Fees D3 Enrollments Delete course schedule D2 Course Add course to schedule Produce course offering list Course to add to enrollment 2.3 Available Course Request Available Courses 2.1
from
Offerings
Available courses 2.2 Fee payment history
Course enrollment add
Course to delete Course to delete Students

- 170 -
Student enrollment information
2.4
schedule request StudentCurrent schedule
Course enrollment addFig. 11.6 Level 1 DFD for Online Registration System - 2
KSOU
- 171 -
KSOU

Dept. Staff Obtain report type D2 Course Offerings Report type Course offering information Generate requested report 3.1 3.2 Report Request D3 Enrollments Enrollment information Requested report
Fig. 11.7 Level 1 DFD for Online Registration System - 2 - 172 -
KSOU
- 173 -
KSOU
Case study 3 - Hoosier Burger's food ordering system

Hoosier Burger is a well-known restaurant. It has decided to use an information system that takes customer orders. After collecting the orders it sends that information to kitchen. The current inventory levels in the kitchen are monitored for the status. Finally, reports are generated by the system for restaurant manager. For the above case study draw a context diagram and illustrate the process of levelling of the context diagram into level 0.
Context diagram
0 Customer Customer Order Receipt Kitchen Restaurant Manager Food Order Management Reports Food ordering system
- 174 -
KSOU
- 175 -
KSOU
Level 0 diagram Receive and transform customer order 1.0 Customer Customer Order Receipt Kitchen Restaurant Manager Food Order Management Reports 2.0 3.0 Receive and transform customer order Receive and transform customer order Goods Sold Inventory Data D1 Inventory File D2 Goods Sold File 4.0 Produce management reports Daily goods sold amount Daily inventory depletion amount Formatted goods sold data Formatted inventory data
- 176 -
KSOU
- 177 -
KSOU
Case Study 4: A Real Estate Inc. (AREI) A Real Estate Inc. (AREI) sells houses. People who want to sell their houses sign a contract with AREI and provide information on their house. This information is kept in a database by AREI and a subset of this information is sent to the citywide multiple-listing service used by all real estate agents. AREI works with two types of potential buyers. Some buyers have an interest in one specific house. In this case, AREI prints information from its database, which the real estate agent uses to help show the house to the buyer (a process beyond the scope of the system to be modeled). Other buyers seek AREIs advice in finding a house that meets their needs. In this case, the buyer completes a buyer information form that is entered into a buyer database, and AREI real estate agents use its information to search AREIs database and the multiple-listing service for houses that meet their needs. The results of these searches are printed and used to help the real estate agent show houses to the buyer. For the above scenario draw a context diagram and a level 0 data flow diagram.
Context diagram
Sellers AREI System House information Buyer information House Information 0 Buyers House information House
- 178 -
KSOU
Information Multiple Listing Service
- 179 -
KSOU

Sellers Maintain house seller information D2 Sales Contracts House information Generate requested report 1 2 Sales Contract D3 Offered Houses House information Buyer information form D1 Multiple Listing Services File House information Sales Contract House information
- 180 -
KSOU
House information House information Buyers House information request D4 Buyers Buyer information
- 181 -
KSOU
- 182 -
KSOU
Case study 5 Apartment Rental System

Consider a Apartment Rental System. The context diagram for such a system is given below (fig ). Draw a level 0 data flow diagram, level 1 data flow diagram for process 2 and level 2 data flow diagram for process 2.1
Lease, Payments Bank Deposit Lease Cash Report Receipts, Notices Tenant Bank External Manager 0 Apartment Rental System
- 183 -
KSOU
- 184 -
KSOU
1 2 3 Tenant New Tenant Process Collection Process Delinquent Process
Lease D1 Tenant File Tenant Info Payments Bank Bank Deposit Receipt External Manager Cash Report D1 Tenant File Unpaid Charges Delinquency Report Tenant Info Delinquencies Copy of lease Notice
- 185 -
KSOU
Deposit Checks Rent Checks 2.1 2.2 Collect Security Deposit Collect
- 186 -
KSOU
Rent Deposit Receipts Payment Receipts Unpaid Charges Bank Deposit Bank Deposit D1 Tenant File Tenant Info Tenant Info Cash Report
- 187 -
KSOU
- 188 -
KSOU
Level 2 data flow diagram for process 2.1 Bank Deposit Bank Deposit 2.1.2 Update Tenant File Deposit Info D1 Tenant File Update Info 2.1.3 Create Receipt Tenant Info Receipt
Deposit Check 2.1.1 Make
UNIT 12
SYSTEM ANALYSIS TOOLS - 3
Data Dictionary
. A data dictionary is one of the techniques used by system analyst to analyze the data flows and data stores in data-oriented systems. A data dictionary can be considered to be reference work of data about data itself i.e. a data dictionary is a metadata. A data dictionary not only collects the data but also coordinates and confirms what a data term means to different hierarchy of users in an enterprise or organization. Data dictionary can be enormous in size. A data dictionary can be used invaluable resource to design for the a variety of reasons, some of them include: It is used as a means of documentation. It can be used to eliminate redundancy. It can be used to process specification. Data flow diagram constructed can be verified by using it. Its servers as an initial guideline or base for developing input forms, output screens and reports.
B.Tech (CSE) - 189 -
KSOU
Thus, a data dictionary is a catalogue of all data used in an application, which acts as a single point reference of data repository of an organization.
Data Repository
A data repository is a central storehouse of the system. It used to store information about the systems data. Apart from holding information about system data, a data repository also contains project information including: Project requirements and deliverables. Procedural logic used. Screen and report design. Relationships between the different entries.
The each piece of data stored in the data repository is called a data element. It can also be referred to as a data item or field. Data elements can be combined to form records. Records are also called data structures. A record is a meaningful combination of related data elements that is included in a data flow or retained in a data store. Every data element in the data dictionary is used to provide comprehensive information about the data and processes that make up the system.
Thus a data repository defines and describes all data elements and meaningful combinations of data elements. Every data dictionaries contains a data flow, data structures, data elements and data stores. Data flow Every data flow in the systems must be defined with descriptive information and its composite structure or elements. Defining a data flow should include information like: ID, which is an identification number used to identify each data flow.
- 190 -
B.Tech (CSE)
KSOU
Label or a data flow name, a text that should appear on the data flow diagram i.e the data flow label used on a data flow diagram. Brief descriptions of the data flow. Source or origin of the data flow. The source or origin of the data flow may be an external entity or a process or a data flow from a data store. Sink or Destinations of the data flow, which can be an external entity or a process or a data flow into a data store. The type of the data flow. A data flow may be a record that enters into a system or leaves a file i.e. the input. It can also contain a report or a form. Sometimes, a data flow can be used internally between processes within the system also.
Alternate name(s) of the data element or data structure. The volume and frequency per unit of time. For instance records per week, per month, yearly, etc. Comments and further description or notations about the data flow.
For example consider an order processing system. A data repository may contain the following information about a customer order data flow as illustrated in table 12.1. Name Description customer master and item files and to produce an order record. Source / Origin Destination Type Data Structure Volume/Time Comments External Entity, Customer Process 1.0, Add Customer Order Screen Order Information 25 per hour An order record contains information for one customer order. The order may be received by mail, fax, or by telephone.
Table 12.1: Data repository entries for customer order data flow
Customer Order Contains customer order information and is used to update the
B.Tech (CSE)
- 191 -
KSOU
Data Structures A data structure is a combination of related data elements that is included in a data flow or retained in a data store. In simpler terms, data structures are a group of smaller structures and elements. Data structures are represented using algebraic notations. Some of the commonly used algebraic notations are depicted in table 12.2. Symbol = (Equal to) + (Plus) { } (Curly braces) [ ] (Square braces) () (Parentheses ) Consists of And Repeating element or group of elements Either/or situation Optional element Meaning
Table 12.2: Algebraic notation
A data structures may be either logical data structure or physical data structure. A logical data structures is used to indicate the composition of the data familiar to the user. A physical data structure includes elements and information necessary to implement the system. For example, data structure for the Delivery Note can be represented as Delivery Note = Order Number + Order Date + {Order Items} + Total + (Tax) + Shipping + Order Total + Vendor Number + Vendor Name + Address + Telephone A data structure may also contain smaller structural records. For example name can be further defined as first name, middle name and last name. Similarly address can be further defined as door no, street no, city, state, country, zip code. Data Elements
B.Tech (CSE)
- 192 -
KSOU
A data element, also called a data item or field, is the smallest piece of data in a data repository. Data elements can be together to form records or data structures. The attributes recorded in the data repository for each data element includes: ID, which is an identification number used to identify data element. It is an optional attribute. Data element name or label, it should be what the element is commonly called in most programs or by the major user of the element . Alias, synonyms for data elements.
B.Tech (CSE)
- 193 -
KSOU
Brief descriptions of the data element. Type, which indicates whether data element is base or derived. A base element is one that has been initially keyed into the system. A derived element is one that is created by a process, usually as the result of a calculation or some logic.
Length of the data element. Some data elements like social security number, zip code and telephone number can be of fixed length. While some data elements like name of customer, item, etc can be of variable length. Default value for the data element can be specified. It is an optional attribute. Acceptable values which includes the domain and validity rules of the data elements . For example consider an order processing system. A data repository may contain the following entries about order number data element as illustrated in table 12.3. Name Alias Description Length Input Format Output Format Default Value Continuous/Discrete Type Base or Derived Upper Limit Lower Limit Comments Order number Order Id Used to identify order given to vendor 8 10 (6) 10 (6) -Continuous Numeric Derived <999999 >0000 It is a key field.
Table 12.3: Data repository entries for order number data element
However, if the length of the data element is too small, there are possibilities of data being truncated and inturn affects the system output. So, possible care must be taken
B.Tech (CSE)
- 194 -
KSOU
about the length of the field. Input and output formats should be included, using coding symbols.
B.Tech (CSE)
- 195 -
KSOU
Data Store A data store typically contains both base elements and derived elements. Data stores are created for each different data entity. Normally, the data flow base elements are grouped together and a data store is created for each unique group. A data flow depicts only a part of the collective data known as the user view. However, this view cannot be used to test different data flow structures to arrive at a complete data store description. Hence documenting the data store information is essential. Typical characteristics of a data store that are stored in the data repository includes: ID, which is an identification number used to uniquely identify a data store.
Data store name or label, a descriptive text that should appear on data store. Alias, synonym or alternate name for the data store file. A short description of the data store. File Type, which indicates whether data store is manual or computerized. File format, It is applicable only if the file is computerized, the file format designates whether the file is a database file or the format of a traditional flat file. Record size
Maximum & average size of the record. Percentage growth / year. This is used to predict the required storage space. Data set name, used to specify the file or table name if known. Data structure name Primary and secondary key data elements found in the data structure Comments and further description about the data store.
For example consider an order processing system. A data repository may contain the following entries about Customer Master data store as illustrated in table 12.4. ID Name
B.Tech (CSE)
DS1 Customer Master

- 196 -
KSOU
Alias Description File type File format Record size Maximum Size Average Size % Growth / year Data Set Data Structure Primary key Secondary key Comments
Client File Contains customer information Computer Database 500 45,800 41,500 8% Customer Customer record Cust id Cust name, Cust addr It is a key file that keeps tracks of customer data.
Table 12.4: Data repository entries for customer master data store
B.Tech (CSE)
- 197 -
KSOU
Structured English
Structured English is the use of the English language with the syntax of structured programming. In other words, Structured English is a technique used to describe algorithmic procedures and is sometimes considered an alternative to flowcharts. Structured English aims at getting the benefits of both the programming logic and natural language. Program logic helps to attain precision while natural language helps in getting the convenience of spoken languages. Thus, structured English is a rigid subset of the English language omitting adjectives, adverbs, compound and complex sentences, all verb modes except imperative and most punctuation. Common keywords used in Structured English START, BEGIN, END, STOP, DO, WHILE, DO WHILE, FOR, UNTIL, DO UNTIL, REPEAT, END WHILE, END UNTIL, END REPEAT, IF, IF THEN, ELSE, IF ELSE, END IF, THEN, ELSE THEN, ELSE IF, SO, CASE, EQUAL, LT, LE, GT, GE, NOT, TRUE, FALSE, AND, OR, XOR, GET, WRITE, PUT, UPDATE, CLOSE, OPEN, CREATE, DELETE, EXIT, FILE, READ, EOF, EOT
Structured English Control Constructs Structured English like any other programming language posesses three standard control constructs namely

sequence selection iteration
B.Tech (CSE)
- 198 -
KSOU
Apart from these it also has primitive actions. These constructs permit the specification of any system. Primitive Actions Primitive Actions are used to inform the reader of what must be done as opposed to when it is to be done . Normally primitive actions are expressed as imperative statements, Example : READ-FILE STOCK-DETAILS. Primitive actions should be concise in that it should avoid usage of vague words (e.g. process / handle) rather it must contain a strong verb to identify the function and must explicitly state the object of the statement, which is selected from the data dictionary
Sequences Sequences represent actions taking place in sequence without interruption. They are defined by the successive appearance of a set of primitive actions Selection constructs Selection constructs are used to describe a series of alternative policies from which only one is selected. For example IF.. ELSE and CASE are two commonly used selection constructs. Syntax IF <condition> THEN<statement (s)> ELSE <statement (s)> ENDIF
KSOU
SELECT <Expression> CASE 1 IF <condition> THEN <statements> CASE 2 IF <condition> THEN <statements> Examples Example 1: Simple IF..THEN and IF..THEN..ELSE IF overtime_hours are greater than 24 THEN ask the supervisor to review the employee_time_card END-IF IF a customer_order_total is greater than $400 THEN IF customer_balance is > 60 days past due THEN hold the customer_order send reminder letter ELSE process the customer order END-IF ELSE process the customer order END-IF Example 2: CASE SELECT the dollar amount that applies: CASE 1 IF the planned expenditure > $10,000 THEN send expense_justification to corporate headquarters CASE 2 IF the planned expenditure >= $1000 and <= $10,000 THEN send expense_justification to plant manager CASE 3 IF the planned expenditure < $1000 THEN send expense_justification to area supervisor Iteration Construct Iteration construct are used to repeatedly perform a series of within some bounds. DO WHILE, DO UNTIL construct or a REPEAT UNTIL construct are the two commonly used iterative constructs. Syntax
B.Tech (CSE)
- 200 -
KSOU
DO <statement (s)> UNTIL <condition> REPEAT UNTIL < condition> <statement (s)> END- REPEAT UNTIL DO WHILE <condition> <statement (s)> END-DO WHILE
Examples Example 1: DO..UNTIL DO READ next Inventory Record BEGIN IF If Quantity in stock is less than reorder point THEN GENERATE Order END IF UNTIL end of file (Inventory)
Example 2: DO..WHILE DO-WHILE there are overtime_pay_records Read a record Add overtime_hours to overtime_hours_total Add overtime_pay to overtime_pay_total END-DO-WHILE
Example 3: REPEAT-UNTIL REPEAT-UNTIL all invoice line-items are extended Multiply quantity_shipped by item_cost to get item_extended_cost
KSOU
Add item_extended_cost to total END-REPEAT-UNTIL NOTE: Format of Structured English uses indentation used in programming languages.
Structured English does not initialize variables, open and close files, or find related records in separate files.
Guidelines for writing Structured English
The following guidelines can be used when writing Structured English:

Statements should be clear and unambiguous Use one line per logical element All logic should be expressed in operational, conditional, and repetition blocks Logical blocks should be indented to show relationship Keywords should be capitalized
Inventory Processing An Structured English Case Study

Given a level 1 data flow diagram for a maintain inventory process of an inventory processing system as illustrated in figure 12.1. Write the corrosponding Structured English for all the process specified in the DFD.
Supplier Inventory D1 1.1 Update Inventory Added 1.2 Update Inventory Used
KSOU
Stock on Hand Qty Added Counts Products Amounts Used
B.Tech (CSE)
- 203 -
KSOU
Figure 12.1: Level 1 DFD for maintain inventory
Structured English for Process 1. 1 : Update Inventory Added DO READ next invoice-item-record (info from supplier) Find matching inventory-record Add Quantity from invoice item record to quantity in stock on inventory-record UNTIL end of file (invoice-item from supplier) Structured English for Process 1. 2 : Update Inventory Used DO READ next Stock-item-record (from stock list) FIND matching inventory-record SUBTRACT Quantity-used from Stock-item-record from quantity in stock on inventory-record UNTIL end of file (stock list)
B.Tech (CSE)
- 204 -
KSOU
Decision table
Structured English is not suitable to represent complicated logic having several different conditions because it becomes difficult to understand. To overcome this drawback decision tables are used. A decision table is a matrix representation of the logic of a decision. It specifies all the possible conditions and the resulting actions in a tabular form. It is best suited for making complicated decision logic. Thus, a decision table can be viewed as tabular with conditions and actions and an indication under which conditions, which actions must be performed. Decision tables are typically divided into four quadrants as depicted in the table 12.5.
Condition Stub a list of all possible conditions that can arise within the process Action Stub a list of all possible actions that occur within the process
Rules contains selectors which identify Action Entries indicators which select the actions to be performed
Table 12.5 : Decsion table structure
Each decision in the condition stub corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives i.e rules. Each action is a procedure or operation to be performed based on the rules. The action entries specify whether or in what order the action is to be performed for the set of condition alternatives the entry corresponds to. Decision tables vary widely in the way the condition alternatives and action entries are represented. Some decision tables use simple true/false values to represent the alternatives
KSOU
to a condition i.e similar to an if-then-else strcuture, some tables may use numbered alternatives i.e similar to an switch case strcuture and some tables even use fuzzy logic or probabilistic representations for condition alternatives. Similarly, action entries can simply represent whether an action is to be performed or in more advanced decision tables, the sequencing of actions to perform.
B.Tech (CSE)
- 206 -
KSOU
Procedure for Creating Decision Tables
Name the conditions and values each condition can assume. For instance some conditions values can be just yes or no and some may have many values called an extended entry. Name all possible actions that can occur Create exhaustive set of rules considering every possible combination of conditions must be represented. Some rules may be redundant or make no sense that can be altered later. Total number of rules is the product of number of values for all the conditions. i.e. Number of rules = number of values for condition 1 X number of values for condition 2 X ..X number of values for condition n
Define the actions for each rule. If an action doesnt make sense create an impossible row for that action. If the action is not known place a ? for that rule. Simplify the table by removing any rules with impossible actions
Banners restaurant A decision table case study Banners restaurant has two categories of employees. First, an employee who will be paid based on monthly salary (S). Second, who based on hours worked (H). There are three types of hours worked, less than 40, exactly 40 and more than 40. If (S) employees who work for 40 hours or less than 40 hours or more than 40 hours, they will be paid on monthly-based. If (H) employees and work less than 40 hours, the system will calculate hourly wage and an absence report must be produced. If (H) employees who has worked exactly 40 hours, the system will pay hourly wage. If (H) employees and work more than 40 hours, the system will hourly calculate wage and also calculate for overtime. The decision table for the above case study is illustrated in table 12.6.
Rules
KSOU
X Produce absence report X
Calculate overtime X X X Calculate hourly wage X X X Pay base salary

KSOU
Action >40 >40 40 40 <40 <40 Hours worked H S H S H S Employee type 6 5 4 3 2 1 Condition
KSOU
Table 12.6 : Decsion table for Banners restaurant
Produce absence report Calculate overtime Calculate hourly wage Pay base salary Action Hours worked Employee type Condition Rules
B.Tech (CSE)
- 210 -
KSOU
X X X
>40 40 <40 H H H S 4 3 2 1
The above table can further be simplified as illustrated in the table 12.7.
KSOU
Table 12.7 : Simplified decsion table for Banners restaurant
B.Tech (CSE)
- 212 -
KSOU
Decision table variants

There are three variants of the decision table. They are

Limited Entry Decision Table Mixed Entry Decision Table Extended Entry Decision Table
A limited entry decision table contains only the binary selectors Yes (Y) & No (N) and the catch all selector in the rules quadrant. In the action entries, it contains only the action selector symbol X. A mixed entry decision table contains only the binary selectors Yes (Y) & No (N) and the catch all selector in the rules quadrant. In the action entries quadrant, indicators other than symbol X appear. A extended entry decision table contains selectors in the rules quadrants that are no longer simply binary (Yes (Y) or No (N)) but may take on specific values or ranges of values. Note: Decision tables can also be used to specify additional decision-related information like:

If actions for a rule are more complicated and cant be conveyed in one or two lines of text. If some conditions depend on other conditions i.e. nested conditions. Use numbers to indicate sequence rather than just Xs where rules and action stub intersect.
Advantages of a decision table

Simple and easy to understand. Enhances readability. Alternatives are shown side by side. Cause & effect relationship is shown, thus permitting easier user validation.
- 213 -
B.Tech (CSE)
KSOU
Possible to check that all combinations of conditions have been considered thereby ensuring the completeness. Decision tables allow you to check for the completeness, consistency, and redundancy of logic. Aids in analysis of structured decisions.
Decision tree
A decision tree is a decision support tool that uses a tree-like model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. Decision trees are used when complex branching occurs in a structured decision process. They are also useful when it is essential to keep a string of decisions in a particular sequence. Another use of decision trees is as a descriptive means for calculating conditional probabilities. A decision tree can be used as an alternative to decision table. It uses a tree structure which show conditions and actions within a problem. The root of the tree represents the name of the process; the nodes represent the conditions and the leaves represents the actions to be performed. A decision tree consists of three types of nodes Decision nodes which are represented by squares Chance nodes represented by circles End nodes represented by triangles Draw the decision tree using squares to represent decisions and circles to represent uncertainty. Evaluate the decision tree to make sure all possible outcomes are included. Calculate the tree values working from the right side back to the left. Calculate the values of uncertain outcome nodes by multiplying the value of the outcomes by their probability (i.e., expected values).
Steps to build a decision tree
B.Tech (CSE)
- 214 -
KSOU
The following figure 12.2 illustrates the structure of a decision tree.
1 2 6 3 5 4 Condition 1 Condition 2 Action 1 Action 4 Action 2 Action 3 Condition 3 Condition 4
Figure 12.2: Decision tree structure B.Tech (CSE) - 215 -
KSOU
A policy for Premium Airlines : Accumulating Miles For Awards, as explained by Glen Curtis (marketing manager) - A decision tree case study The traveler will be awarded the miles actually flown. If the actual mileage for the leg was less than 500 miles, the traveler will get 500 miles credit. If the leg was exactly or more than 500 miles and the trip was made on Saturday, the actual mileage will be multiplied by 2. If the trip was made on Tuesday, the multiplication factor is 1.5. If this is the ninth leg traveled during the calendar month, the mileage is doubled no matter what day, and if it is the seventeenth leg traveled, the mileage is tripled. Figures 12.3 and 12.4 illustrates the decision tree for the above case study. Note figure 12.4 is simplified vesrion of decision tree in figure 12.3
B.Tech (CSE)
- 216 -
KSOU
Mileage for the leg 2 1 3 3 5 5 7 7 9 9 4 8

10== 11
<500 >= 500 6 Credit 500 miles Double mileage 1.5 times Double mileage Triple mileage Normal mileage Saturday? Yes No Tuesday Trip?
KSOU
Yes No 9th leg in month? Yes No 17th leg In month? Yes No
B.Tech (CSE)
- 218 -
KSOU
Figure 12.3: Decision tree structure for Premium Airlines
Mileage for the leg 2 1 3 5 7 9 4 8

10 11
<500 >= 500 6 Credit 500 miles Double mileage

KSOU
1.5 times Double mileage Triple mileage Normal mileage Saturday Tuesday 9th leg in month 17th leg In month Not Saturday Not Tuesday Not 9th leg in month Not 17th leg In month
B.Tech (CSE)
- 220 -
KSOU
Figure 12.4: Decision tree structure for Premium Airlines (Simplified)
B.Tech (CSE)
- 221 -
KSOU
Advantages & disadavantages of a decision tree The advantages of using decision tree include

It is easy to understand and interpret It can map nicely to a set of business rules It can be applied to any real world problems It makes no prior assumptions about the data It has ability to process both numerical and categorical data It can be combined with other decision techniques.
The disadvantages of using decision tree include

Output attribute must be categorical Limited to one output attribute Decision tree algorithms are unstable Trees created from numeric datasets can be complex
Advantages of decision tree over decision table First, it takes advantage of the sequential structure of decision tree branches so that the order of checking conditions and executing actions is immediately noticeable.
Second, Conditions and actions of decision trees are found on some branches but not on others, which contrasts with decision tables, in which they are all part of the same table. Those conditions and actions that are critical are connected directly to other conditions and actions, whereas those conditions that do not matter are absent. In other words it does not have to be symmetrical. Third, compared with decision tables, decision trees are more readily understood by others in the organization. Consequently, they are more appropriate as a communication tool.
Deciding Among the Analysis Tools The decision of using a particular tool for system analysis depends upon number of factors or criteria. Table 12.8 illustrates how decision can be taken by analyst among Structured English, Decision Tables, and Decision Trees. Similarly there are occasions where decision has to be made between Decision Tables and Decision Trees which is illustaed in Table 12.9
KSOU
Best Best Third Best Checking Consistency and Completeness Best Third Best Best Transforming Conditions and Actions into Sequence Best Third Best Second Best Determining Conditions and Actions Decision Trees Decision Tables Structured English Criteria
B.Tech (CSE)
- 223 -
KSOU
Table 12.8: Deciding Among Structured English, Decision Tables, and Decision Trees
Worst Best Easier to manipulate Worst Best More compact Best Worst Making decisions Best Worst Portraying simple rules Worst Best Portraying complex logic Decision Trees Decision Tables Criteria
B.Tech (CSE)
- 224 -
KSOU
Table 12.9: Deciding Between Decision Tables and Decision Trees
Module 5 Unit 13 Input Design

Systems design is the process of developing specifications for a candidate system that meet the criteria established in systems analysis. A major step in design is the preparation of input and the design of output reports in a form acceptable to the user. Inaccurate input data are the most common cause of errors in data processing. Errors entered by data entry operators can be controlled by input design. Input design is the process of converting user-oriented inputs to a computer based format. Input Design Process identifies system inputs and review logical requirements. Select appropriate GUI controls. Design, validate and test inputs using some combination of: Layout tools (e.g., hand sketches, spacing charts, or CASE tools), Prototyping tools (e.g., spreadsheet, PC DBMS, 4GL). As necessary design source documents Data capture is the identification and acquisition of new data at its source. Source documents forms used to record business transactions in terms of data that describe those transactions. Data entry is the process of translating the source data or document (above) into a computer readable format.
Data Processing
Data processing is all processing that occurs on the data after it is input from a machine readable form. In batch processing, the entered data is collected into files called batches and processed as a complete batch. In on-line processing, the captured data is processed immediately. In remote batch processing, data is entered and edited on-line, but collected into batches for subsequent processing.. Batch processing simplifies data communications and other processes, but means that inventory and other reports are not accurate in real time.
B.Tech (CSE)
- 225 -
KSOU
Input Implementation Methods Taxonomy

Select the best strategy to get quality data into the system in a timely and accurate manner. That is Good & Fast or Fast & Good but almost never cheap. System boundary is the edge of accessible information. Keyboard Mouse Touch Screen Point-of-sale terminals Sound and speech Automatic data capture Optical mark recognition (OMR) Bar codes
Optical character recognition (OCR) Magnetic Ink Electromagnetic transmission Smart cards Biometric
Taxonomy for Computer Inputs Keyboard Data is usually captured on a business form that becomes the source document for input. Data can be collected real-time. Data is entered via keyboard. This is the most common input method but also the most prone to errors.
- 226 -
B.Tech (CSE)
KSOU
Data can be collected into batch files (disk) for processing as a batch, in old processing method. Data is processed as soon as it has been keyed, in new processing method.
Mouse Data is usually captured on a business form that becomes the source document for input. Data can be collected real-time. Used in conjunction with keyboard to simplify data entry. Mouse serves as a pointing device for a screen. The use of a mouse is most commonly associated with online and real-time processing. The data is processed immediately.
Touch Screen Data is usually captured on a business form that becomes the source document for input. Data can be collected real-time. Data is entered o a touch screen display or handheld device. Data entry users either touch commands and data choices or enter data using handwriting recognition. On PCs, touch screen choices are processed same as above. On handheld computers, data is sorted on the handheld for later processing as a remote batch.
Point of Sale Data captured as close to the point of sale as humanly possible. No source documents
B.Tech (CSE)
- 227 -
KSOU
Data is often entered directly by the customer or by an employee directly interacting with the customer Data is almost always processed immediately as a transaction or inquiry
Sound Speech Data is captured as close to the source as possible, even when the customer is remotely located Data (and commands) is spoken. This technology is not as mature and is much less reliable and common than other techniques. Data is almost always processed immediately as a transaction or inquiry. Data is captured as close to the source as possible, even when the customer is remotely located Data is entered using touch-tones (typically from a telephone). Usually requires rigid command menu structure and limited input options. Data is almost always processed immediately as a transaction or inquiry.
Optical Mark Data is recorded on optical scan sheets as marks or precisely formed letter, numbers, and punctuation It eliminates the need for data entry. Data is almost always processed as a batch.
B.Tech (CSE)
- 228 -
KSOU
Magnetic Ink Data usually prerecorded on forms that are completed by the customer. The customer records additional information on the form. A magnetic ink reader reads the magnetized data. The customer-added data must be entered using another input method. Data is almost always processed as a batch.
Electromagnetic Data is recorded directly on the object to be described by data. Data is transmitted by radio frequency Data is almost always processed immediately.
Smart Card Data is recorded directly on a device to be carried by the customer, employee, or other individual that is described by that data. Data is read by smart card readers. Data is almost always processed immediately.
Biometric Unique human characteristics become data Data read by biometric sensors. Primary applications are security and medical monitoring Data is processed immediately.
B.Tech (CSE)
- 229 -
KSOU
Input Design Objectives and Guidelines

Data Input Techniques includes capture and validate data at source, reduce the information float (time from beginning of Capture to end of Entry), Reduce input volume (codes, scanners), Streamline data entry if hard to scan, SKU must be keyed. e.g. poor quality labels, heavy boxes/fixed counter scanner. Key Tasks in Input Design are list system inputs with data content. Examine the output requirements. Design and prototype input methods include, input controls & security, Identify devices and mechanisms.
Define the appropriate format and media for a computer input. Explain the difference between data capture, data entry, and data input. Identify and describe several automatic data collection technologies. Apply human factors to the design of computer inputs. Design internal controls for computer inputs. Select proper screen-based controls for input attributes that are to appear on a GUI input screen. Design a web-based input interface. Input Design Objectives The quality of system input determines the quality of system output. Well-designed input objectives: Effectiveness. Accuracy. Ease of use. Consistency. Simplicity. Attractiveness.
Control the amount of input: minimize the quantity of data for input (labor costs) and avoid duplication in data collection (several forms containing the same data) and data entry. Avoid processing delays (lengthy credit approval) due to extra steps in data preparation and entry (computing sales totals), by designing appropriate procedures, source documents, and turnaround documents and data entry methods.
B.Tech (CSE)
- 230 -
KSOU
Avoid errors in data: ensure accuracy through controlling the amount of input, designing forms that ensure accurate completion, selecting the appropriate data entry medium, and using input validation techniques. Keep the process simple: do not include too many error controls.
Input Design Guidelines Capture only variable data, not data that can be looked up. Do not capture data that can calculate or stored in computer programs as constants. Extended Price, Federal Withholding, etc. Use codes for appropriate attributes.
Form Design
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 by the user. Form design follows analyzing forms, evaluating present documents, and creating new or improved forms. Since the purpose of a form is to communicate effectively through forms design, there are several requirements- Include instructions for completing the form. Minimize the amount of handwriting. Data to be entered (keyed) should be sequenced top-to-bottom and left-to-right. Use designs based on known metaphors. Form Design make forms easy to fill out: to reduce errors, speed completion, facilitate data entry, form flow (top to bottom, left to right), form sections: logical grouping of info, form captions: Captions tell the person completing the form what to put on a blank line, space, or box. Ensure that forms meet the intended purpose: effectiveness (specialty forms), assure accurate completion: (row & column totals), keep forms attractive: uncluttered, enough space to fill, fonts and line weights to separate categories, ask each item of data only once. The seven sections of a form are: Heading, Identification and access, Instructions, Body, Signature and verification, Totals, Comments. Captions may be line caption, putting the caption on the same line or below the line, boxed caption, providing a box for data instead of a line, vertical check off, lining up choices or alternatives vertically, horizontal check off, lining up choices or alternatives horizontally.
B.Tech (CSE)
- 231 -
KSOU
Guidelines for good form design Make forms easy to fill out Ensure that forms meet the purpose for which they are designed Design forms to assure accurate completion Keep forms attractive
To make forms easy to fill out, First, design forms with proper flow, from left to right and top to bottom, second, group information logically using the seven sections of a form, third, provide people with clear captions. Captions tell the person completing the form what to put on a blank line, space, or box. To reduce error rates associated with data collection, forms should be designed to assure accurate completion. Design forms to make people do the right thing with the form. To encourage people to complete forms, systems analysts should keep forms attractive. To be more attractive, forms should look uncluttered, and elicit information in the expected order. Aesthetic forms or usage of different fonts within the same form can help make it more attractive. Computer printer entries require a minimum of 1/6-inch spacing between lines. Handwritten entries require approximately 1/4 inch. When forms are completed by either hand or by a printer, allow about 1/3-inch intervals between lines. Make sure that each form in use fulfills its specific purpose. The specified purpose is integral to organizational functioning. Prevent duplication of information collected and the forms that collect it. Designing effective forms, deciding on how to get forms reproduced in the most economical way, establishing stock control and inventory procedures that make forms available when needed, at the lowest possible cost forms a good form design. To be more attractive, forms should look uncluttered, and elicit information in the expected order. Aesthetic forms or usage of different fonts and line weights within the same form can help make it more attractive. Numerous microcomputer form design software is available. Features of electronic form design software: Ability to design paper, electronic, or Web- based forms. Form design using templates. Form design by cutting and pasting familiar shapes and objects. Features of electronic form design software, facilitates completion through the use of software enables broadcasting of electronic forms, permits sequential routing of forms, assists form tracking, encourages automatic delivery and processing, and establishes security for electronic forms.
Screen Design
KSOU
Source Document Design Flow follows data capture sequence, internal vs External Document Quality and appearance; Cost of using a document is greater than the cost of the form itself. Screen follows Form, Form follows Function. Screens should be attractive - not too much stuff at one time. Information displayed in a logical order - follow the form. Screens should be consistent - titles, layout, F keys, buttons, terms. Messages should be specific - help, not error messages. Messages stay on screen until next user input. Use special effects sparingly (no blinking!). Feedbacks regarding delays are important e.g. progress bar. Prototype screens with users usability testing. 3 Types of Screen Design Data Entry Process Control Graphical User Interfaces Data Entry Screen Design Restrict user access. Provide a caption for every field. Show sample formats for values. Require an ending keystroke for every field- except for single character fields? - may break rule for high volume data entry. Dont require use of special characters. Dont require leading zeroes to fill or trailing zeroes for decimals. Display default values and be careful using them! Display acceptable values whenever possible e.g. on screen help, pull down lists, check boxes, buttons. Provide method to exit without recording values. Provide opportunity to confirm action for non-recoverable, low volume transactions only. Provide means to move among fields cursor defaults to left-right, top-bottom. You can override this. Design screen layout to match source document. Allow for people to make mistakes and change their minds. Allow for searching.
Process Control Screen Design Users can enter commands using interactive input , Menu Screens, Prompt Screens, Graphical User Interfaces Uses graphics such as windows, menus and boxes to allow users to communicate with the system Double clicking, Right clicking, Keyboard shortcuts for expert users, To reap advantage, must have common look and feel. Guidelines for good screen design
B.Tech (CSE)
- 233 -
KSOU
First, keep the screen simple Second, keep the screen presentation consistent Third, facilitate user movement among screens Finally, create an attractive screen
Displaying a few necessary basic commands using windows or hyperlinks is another way to keep screens simple. For the occasional user, only 50 percent of the screen should contain useful information. For the regular user, up to 90 percent of the screen may contain information. Simplistic design includes maximizing or minimizing the window size as needed. Clicking the right mouse button is often used to display more options for the window. Consistency is achieved by displaying information in the same area or by grouping information logically. Consistency means using the same terms and acronyms on several screens Guidelines for facilitating movement include: Scrolling the screen back and forth Calling up another screen for more detail Using onscreen dialogue through the prompts Web pages may use buttons or commands to facilitate scrolling and screen movement Character-based screens scroll by displaying new screens, using standard function keys GUI screens should not scroll Web screens often scroll
To make the screen attractive use different thickness of separation lines between subcategories, Inverse video and blinking cursors. Icons which are pictorial onscreen representations symbolizing computer actions. Different combinations of colors, Different type fonts, Icons are used in graphical screens to run programs and execute commands. Graphical User Interface (GUI) is used in conjunction with a mouse for making selections and entering data.
B.Tech (CSE)
- 234 -
KSOU
GUI controls
Common GUI Controls Uses Text boxes o When the input data values are unlimited in scope Radio buttons o When data has limited predefined set of mutually exclusive values Check boxes o When value set consists of a simple yes or no value List boxes o When data has a large number of possible values Drop down lists o When data has large number of possible values and screen space is too limited for a list box Combination boxes o To provide user with option of selecting value from a list or typing a value that may or may not appear in the list Spin boxes o When need to navigate through a small set of choices or directly typing a data value.
Advanced Controls (mostly Windows interfaces) are: Drop down calendars Slider edit controls Masked edit controls Ellipsis controls Alternate numerical spinners Check list boxes
B.Tech (CSE)
- 235 -
KSOU
Check tree boxes
The five most legible foreground/background color combinations for display monitors are Black on yellow, Green on white, Blue on white, and White on blue, and Yellow on black.
Extending Input Design to Web

Guidelines for creating intranet and Internet input pages Use a variety of text boxes, push buttons, radio buttons, drop-down lists, and other GUI features Provide clear instructions Include radio buttons when users must make a bipolar choice Use check boxes to test conditions to true or untrue Use a logical entry sequence for fill-in forms Include two basic buttons: Submit and Clear Create a feedback screen that lists error messages if a form has not correctly been filled out Provide a scrolling text box if you are uncertain how much text will be entered If the form is lengthy, divide it into several simpler forms on separate pages
Input controls
The number of inputs should be monitored to minimize risk of lost transactions. For batch processing, Use batch control slips. Use one-for-one checks against post-processing detail reports. For on-line systems, Log each transaction as it occurs to a separate audit file. Validate all data Existence checks, Data-type checks, Domain checks, Combination checks, Self-checking digits, Format checks.
B.Tech (CSE)
- 236 -
KSOU
Input Control ensure data is correct, complete, secure, audit trail- transaction logging in computer file - initials, stamps in paper documents - control number references, workflow - Lotus Notes, computer security - access to programs & files, physical security - paper, tapes, microfilm, etc. - access and borrowing privileges - offsite storage & records retention. Input Controls Keep track of the number of inputs. Account for each input document, Cross check totals where possible, save transactions to a log file in case of disaster. Validate Data make sure required fields have been entered, Limit & Range checks, Field Relationship checks, Check digits, Format checks. Screen-Based Controls are Labels, Text Boxes, Option Buttons, Check Boxes, List Boxes, Combo Boxes. Label Controls Displays text. The user cannot enter text. Use Label Controls when you want to present information that the user will not be able to change. Examples: Labels for other Controls, Calculated Fields that should not be altered by the user. Text Boxes - The user types the data. Use text boxes when you cant provide the user with a meaningful list of values from which to choose or when values are unlimited. Examples: Customer Name, Temperature to Convert to Celsius, Product Number. If text data is large, such as a product description, use Memo Box. Option Button Controls Also called Radio Buttons. User selects one option from a small number of predefined, mutually-exclusive options. One of the options will be the default option when the control first appears. Examples: Number of Apartment Bedrooms. Check Box Controls- User selects one of only two options: Yes or No (Check Mark or No Check Mark). One of the options will be the default option when the control first appears. Make sure Check Box options are truly Yes/No and create captions that clearly indicate this. Examples: Doctors Office questions Have you ever had measles? Have you ever had meningitis? Are you now or have you ever been a Communist? List Box Controls -select from a list of predefined, mutually-exclusive options. Use when number of items in list is too large for a group of option buttons or when limited screen space prohibits the use of a group of option buttons. Scroll bars appear when list is too long. Default list item is usually highlighted. Examples: U.S. States, Zodiac Sign. Combo Box controls combination of a List Box & a Text Box. Use Combo Boxes when the user can choose from a list of possible options OR type an option of his choosing. Examples: Font Sizes, Favorite Ice Cream Flavor. For Screen-Based Controls, Focus on Fewer Errors - which control is likely to cause fewest input errors? Group related controls, align them vertically, and give them a clear caption. Provide ToolTips whenever possible. Use Drop-Down List Boxes when screen
B.Tech (CSE)
- 237 -
KSOU
space is limited. Make sure Check Box options are truly Yes/No. Adhere to industry screen design standards. Controlling forms include making sure that each form in use fulfills its specific purpose, Deciding on reproduceing forms in the most economical way, establishing stock control and inventory procedures that make forms available when needed, at the lowest possible cost, preventing duplication of information collected and the forms that collect it, designing effective forms. Input Validation Checking the transaction: to ensure that the transaction is not invalid (incomplete, unauthorized, out of order) Batch Controls: batch size, batch count, batch totals Transaction Validation
Inventory system should not accept the addition of a new item with the same stock number as an existing one. Transactions having no relation to the system may also be submitted (payroll transaction to inventory system). Acceptable input may be submitted by an unauthorized user
Sequence Tests: serial numbers to identify Missing items (cheques) The order of transactions (deposits vs withdrawals) Completeness Tests: automatic guidance in POS systems; keyboard locks or systems waits indefinitely until correct data are entered. Checking the transaction data Existence Tests: Some fields are designed not to be left blank (quantity of item in a sales order), whilst others can be empty (patient insurance number).
KSOU
Limit and Range Tests: to verify the reasonabless of data. Limit tests validate either minimum or maximum values; range tests validate both. Combination Tests: validate that several items jointly have acceptable values; the value of one element determines whether other values are correct. Duplicate Processing: process data more than once, either on different equipment or in different ways.
Modifying the Transaction Data Automatic Correction of Errors Check Digits: Transcription errors Types of Input Text Numbers Selection box Input Validation Completeness check Format check Range check Check digit check Consistency check Database check
Tools for Input Design and Prototyping

There are number of old and new tools are available for input design
B.Tech (CSE)
- 239 -
KSOU
Old Tools Record Layout Charts Display Layout Charts
Newer Prototyping Tools Microsoft Access CASE Tools Visual Basic Excel Visio
Module 5 Unit 14 Output Design

Computers output is the most important and direct source of information to the user. Efficient, intelligible output design should improve the systems relationships with the user and help in decision making. Output Design and Prototyping Objectives are to distinguish between internal, external, and turnaround outputs, differentiate between detailed, summary, and exception reports. Identifying several output implementation methods. Differentiate among tabular, zoned, and graphic formats for presenting information. Distinguish among area, bar, column, pie, line, radar, donut, and scatter charts and their uses. Describe several general principles that are important to output design and to design and prototype computer outputs. Motivation for output design is outputs, present information to system users and justification for the system. Goals of output design are:
B.Tech (CSE)
- 240 -
KSOU
Communicate: Match the representation to the capabilities of the user (i.e., make relationships clear) Economize: Do the most with the least amount of cues (i.e., reduce cognitive load of the user) Organize: Present pertinent information to system users that is easy to read and easy to use
Types of Output:
Internal output an output intended for system owners and system users within an organization. Detailed report an internal output that presents information with little or no filtering o Example: A listing of all customers Summary report an internal output that categorizes information for managers o Do not have to wade through details. o Increasingly presented in graphical formats using charts o Example: A count of customers by region Exception report An internal output that filters data to report exceptions to some condition or standard. o Example: A listing of customers with past due accounts
External outputs an output that leaves the organization. Intended for customers, suppliers, partners, or regulatory agencies.
Turnaround documents an external output that may re-enter the system as an input
B.Tech (CSE)
- 241 -
KSOU
Most bills and invoices include a stub to be returned by the customer with payment.
Implementation Methods for Outputs
Printed output Tabular output presents information in columns. Zoned output places text and numbers into designated areas
Screen output Graphic output is the use of pictorial charts to convey information and demonstrate trends and relationships that cannot be easily seen in tabular formats.
Point-of-sale terminals Multimedia E-mail Hyperlinks Microfilm or microfiche
Chart Types The different charts available are: Line charts show one or more series of data over a period of time. They are useful for summarizing and showing data at regular intervals. Each line represents one series or category of data.
B.Tech (CSE)
- 242 -
KSOU
Area charts are similar to line charts except that the focus is on the area under the line. That area is useful for summarizing and showing the change in data over time. Each line represents one series or category of data. Bar charts are useful for comparing series or categories of data. Each bar represents on series or category of data. Column charts are similar to bar charts except that the bars are vertical. Also, a series of column charts may be used to compare the same categories at different times or time intervals. Each bar represents one series or category of data. Pie charts show the relationship of parts to a whole. They are useful for summarizing percentages of a whole within a single series of data. Each slice represents one item in that series of data. Donut charts are similar to pie charts except that they can show multiple series or categories of data, each as its own concentric ring. Within each ring, a slice of that ring represents one item in that series of data. Radar charts are useful for comparing different aspects of more than one series or category of data. Each data series is represented as a geometric shape around a central point. Multiple series are overlaid so they can be compared. Scatter charts are useful for showing the relationship between two or more series or categories of data measured at uneven intervals of time. Each series is represented by data points using either different colors or bullets.
Taxonomy for Computer-Generated Outputs Printer Detailed, summary, or exception information printed on hard-copy reports for internal business use. Business transactions printed on business forms that will eventually be returned as input business transactions
B.Tech (CSE)
- 243 -
KSOU
Business transactions printed on business forms that conclude the business transactions.
Screen Detailed, summary, or exception information displayed on monitors for internal business use. Business transactions displayed on monitors in forms or windows that will also be used to input other data to initiate a related transaction. Business transactions displayed on business forms that conclude the business transactions.
Point-of-Sale Terminals Information printed or displayed on special-purpose terminals dedicated to specific internal business functions. Information printed or displayed on a special-purpose terminal for the purpose of initiating a follow-up business transaction. Information printed or displayed on special-purpose terminals dedicated to customers.
Multimedia (audio or video) Information transformed into speech for internal users. Information transformed into speech for external users who respond with speech or tone input data. Information transformed into speech for external users.
B.Tech (CSE)
- 244 -
KSOU
E-mail Displayed messages related to internal business information. Displayed messages intended to initiate business transactions Displayed messages related to business transactions.
Hyperlinks Web-based links to internal information that is enabled via HTML or XML formats. Web-based links incorporated into Web-based input pages to provide users with access to additional information. Web-based links incorporated into Web-based transactions.
Microfiche Archival of internal management reports to microfilm that requires minimal physical storage space. Not applicable unless there is an internal needs to archive turnaround documents. Not applicable unless there is an internal need for copies of external reports.
Output Design Guidelines
Outputs should be simple to read and interpret. o Include a title, Date and time stamp. Include sections and headings to segment information. Clearly label all fields and columns. Include legends for all abbreviations. Include only required information. Online provide methods to expand and contract information. Report the information in a
B.Tech (CSE)
- 245 -
KSOU
format that does not have to be manually edited. Information should be balanced across the page or screen. Provide for easy navigation. Avoid computer jargon and error messages. The timing of outputs is important. o This can affect how the output is designed an implemented The distribution of (or access to) outputs must be sufficient to assist all relevant users. o The choice of implementation method affects distribution. Outputs must be acceptable to the system users who will receive them. o Systems analyst must understand how the recipient plans to use the output
Output Design Process Identify system outputs and review logical requirements. Specify physical output requirements. As necessary, design any preprinted forms. Design, validate and test outputs using some combination of: Layout tools (e.g., hand sketches, spacing charts, or CASE tools, Prototyping tools (e.g., spreadsheet, PC DBMS, 4GL), Code generating tools (e.g., report writer). Output Bias Once a project is completed, the systems analyst signs off, but his/her influence is long lasting. Mostly the information on which the decision makers base their decisions is determined by what the analysts perceive is important to the business. The presentations of output can be unintentionally biased in the following three ways: How information is sorted e.g. items at the beginning of an alphabetically sorted list receives more attention. Setting of acceptable limits may bias output if the limit is too low or too high, or is the range of exceptions output too narrow or too wide, e.g. if `3 days late' payment is considered `bad', then the number of `bad' customers would be very high. Choice of graphics:
B.Tech (CSE)
- 246 -
KSOU
Bias can occur in the selection of the graphic size, its colour, the scale used, and the type of graphic.
Methods for Avoiding Bias

Work with users, so they can point out the bias. Be aware of the sources of bias. Use interactive design of output for greater flexibility. Train users to rely on multiple output for conducting `reality tests' on system output.
Report Design
Report Design Principles and Design Issues are: Page Size - Today the page sizes of choice are standard (8" x 11") and legal (8" x 14"). Page Orientation- Portrait orientation is often preferred because it is oriented the way we orient most books and reports; however, landscape is often necessitated for tabular reports because more columns can be printed. Page Headings- At minimum, page headers should include a recognizable report title, date and time, and page numbers. Report Legends - A legend is an explanation of abbreviations, colors, or codes used in a report. In a printed report, a legend can be printed on only the first or last page. On a display screen, a legend can be made available as a pop-up dialogue box. Column Headings - Column headings should be short and descriptive. Avoid abbreviations or include a Report Legend. Heading Alignments - Alignment should be tested with users for preferences with a special emphasis on the risk of misinterpretation of the information. Column Spacing - If columns are too close, users may not properly differentiate between the columns. If they are too far apart, the user may have difficulty following a single row. Rule of thumb is to use 3-5 spaces between each.
B.Tech (CSE)
- 247 -
KSOU
Row Headings - The first one or two columns should identify data that differentiates each row. Rows should be sequenced in a fashion that supports their use. Frequently rows are sorted on a numerical key or alphabetically. Formatting - Data is often stored without formatting characters to save storage space. Outputs should reformat data to match the users norms. Control Breaks - Groups of rows should be logically grouped in the report. The transition from one group to the next is called a control break and is frequently followed by subtotals for the group. End of Report - The end of a report should be clearly indicated to ensure that users have the entire report.
Paper quality, type and size
Steps in designing output reports with a Computer-Aided software tool -Determine the need for the report. -Determine the users. -Determine the data items to be included. -Estimate the size of the report. -Determine the report title. -Number the pages of the report. -Include the preparation date on the report. -Label each column of data appropriately. -Define variable data. -Review prototype reports.
B.Tech (CSE)
- 248 -
KSOU
Screen Output Design Guidelines to facilitate the screen design are as follows : Keep the screen simple: o The display screen should be simple and show only what is necessary. Create an attractive screen: o If users find screens appealing, they are likely to be more productive, to need less supervision and to make fewer errors. Keep the screen presentation consistent: o Screens can be kept consistent by locating information in the same area each time a new screen is accessed. o Information that logically belongs together should be consistently grouped together. Facilitate user movement among screens: o Make it easy to move from one screen to another. o Web based forms facilitate movement with the use of hyperlinks. Design an attractive screen. Screen Design Considerations are: Size - The designer should consider the lowest common denominator. The default window size should be less than or equal to the worst resolution display in the user community. Scrolling - On-line outputs have the advantage of not being limited by the physical page. This can also be a disadvantage if important information such as column headings scrolls off the screen. If possible, freeze important headings at the top of a screen. Navigation - Users should always have a sense of where they are in a network of on-line screens. Users also require the ability to navigate between screens. Partitioning - In Windows, zones are forms within forms. On the Internet, frames are pages within pages. Information Hiding - On-line applications offer capabilities to hide information until it is either needed or becomes important. Techniques include drill-down and pop-up dialogue boxes.
B.Tech (CSE)
- 249 -
KSOU
Highlighting - Highlighting can call users attention to erroneous data, exception data, or specific problems. Highlighting can also be a distraction if misused. Printing- Always provides users the option to print a permanent copy of the report.
Objectives The objectives of screen output design are Effectiveness Accuracy Ease of use Consistency Simplicity Attractiveness Effectiveness: Forms are created to serve one or more purposes; recording, processing, storing and retrieving information for business. Accuracy: Error rates associated with collecting data drops sharply if the forms are designed to ensure accurate completion. Ease of Use: To reduce errors, speed completion and facilitate the entry of data, it is essential that forms be easy to fill in. Forms should be designed with proper flow (from left to right and top to bottom). Logical grouping of information makes it easy for people to fill out forms correctly. The seven main sections of a strong form are: 1. Heading 2. Identification and Access 3. Instructions 4. Body 5. Signature and verification 6. Totals 7. Comments
B.Tech (CSE)
- 250 -
KSOU
Controlling Forms Businesses often have a forms specialist who controls forms. Basic duties for controlling forms: Make sure that each form fulfils a specific purpose. Prevent duplication of the information that is collected and of the forms that collect it. Deciding how to get forms reproduced in the most economical way. Establishing stock control and inventory procedures that make forms available when needed at the lowest possible cost. A unique form number and revision date should be included on each form. Form Design Guidelines Make forms easy to fill out. Ensure that the forms meet the purpose for which they are designed. Design the forms to ensure accurate completion. Keep the forms attractive.
Color can draw attention for form design to communicate organization, indicate status, reveal relationships, add accents to an uninteresting display facilitate subtle discriminations in complex displays, and evoke emotional reactions. Human vision: rods (peripheral) and cones (fovea, or center), blue and yellow more visible further out than red/green. Color Guidelines Use color conservatively Limit the number and amount of colors (4/7 rule) Recognize the power of color to speed or slow tasks Color coding should appear automatically to support the task Color coding should be under user control Be consistent in color coding Be alert to common expectations about color codes Use color changes to indicate status changes Use color in graphic displays for greater information density Avoid confusing color pairs such as red/green, red/blue, yellow/purple, magenta/green Heavy use of saturated colors can cause afterimages, shadows or depth effects Brown and green are poor choices for background colors Orange/red and orange/yellow are easy to confuse Warm colors appear larger than cool colors
- 251 -
B.Tech (CSE)
KSOU
Color in combination with black or white is often better than 2 colors Use light, saturated colors to emphasize, darker destructed colors to de-emphasize Black on white more readable than white on black.
Icon Design An icon is an image, picture, or symbol representing a concept. Icons are small, usually 64X64 pixels (actual size depends on screen resolution). Icons take advantage of powerful human visual pattern perception. Claims for superiority of icons not universally accepted. Icons for objects are more intuitive than icons for actions. Too many different icons can be distracting and confusing. Icons that are too complex can be distracting and confusing. Icon design should be considered in context of overall screen appearance and complexity growing use of Tool Bars (employing even smaller icons). Represent the object or action in a familiar manner. Make icons stand out from the background. Ensure a selected icon is visible from unselected icons. Design the movement animation. Icons combined with text labels are most effective. Extending output design to web Design principles must be used when designing Web sites. These include: Using professional tools, Studying other sites, Using Web resources, Examining the sites of professional Web site designers. Guidelines for creating intranet and Internet input pages Use a variety of text boxes, push buttons, radio buttons, drop-down lists, and other GUI features Provide clear instructions Include radio buttons when users must make a bipolar choice Use check boxes to test conditions to true or untrue Use a logical entry sequence for fill-in forms Include two basic buttons: Submit and Clear
B.Tech (CSE)
- 252 -
KSOU
Create a feedback screen that lists error messages if a form has not correctly been filled out Provide a scrolling text box if you are uncertain how much text will be entered If the form is lengthy, divide it into several simpler forms on separate pages
Module 5 UNIT 15 Database or File Design

A Data Is a Known facts that can be recorded and have an implicit meaning. A database is a computerized collection of information that is arranged in a manner which makes it easy to retrieve information. A DBMS is a set of software programs that controls the organization, storage, management, and retrieval of data in a database. DBMS are categorized according to their data structures or types. It is a set of prewritten programs that are used to store, update and retrieve a Database. The DBMS accepts requests for data from the application program and instructs the operating system to transfer the appropriate data. When a DBMS is used, information systems can be changed much more easily as the organization's information requirements change. New categories of data can be added to the database without disruption to the existing system. Organizations may use one kind of DBMS for daily transaction processing and then move the detail onto another computer that uses another DBMS better suited for random inquiries and analysis. Overall systems design decisions are performed by data administrators and systems analysts. Detailed database design is performed by database administrators. Database servers are computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with generous memory and RAID disk arrays used for stable storage. Connected to one or more servers via a high-speed channel, hardware database accelerators are also used in large volume transaction processing environments. DBMSs are found at the heart of most database applications. Sometimes DBMSs are built around a private multitasking kernel with built-in networking support although nowadays these functions are left to the operating system. The database systems are required for data management problem.
Database Design
B.Tech (CSE)
- 253 -
KSOU
Database design is the process of creating a design for a database that will support the organizations operations and objectives.
B.Tech (CSE)
- 254 -
KSOU
A data base system should have built-in capabilities to meet the objectives of data independence, reliability, compatibility, structural adaptability, integrity, recoverability, and security. These requirements are major constraints on database design. Design Objectives A good database design enables performance, security, correctness, and a presents the user with an illusion of intelligence. This may sound like a set of high expectations for a database. If you are the only one using your database, then you can certainly relax your standards. However, this article will attempt to explain how security and correctness can be including in the design of any database. No standard exists to compare one database structure with another to evaluate the quality of a given design. There is no reference database design or popular handbook of database structural solutions. This lack of a standard creates a common dilemma: large amounts of time and money are spent to produce a computer program only to find it is supported by an inadequate database design. The only recourse for this dilemma is to redesign the database and hopefully produce a better design or live with the design you have. The good news is, modern hardware will cover most design flaws by simply covering over the problem with amazing speed. All good DBMS's should guarantee the following attributes: Atomicity
Should not be able to execute half of an operation Either all or none of the effects of a transaction are made permanent
Consistency There should be no surprises in the world, e.g., gpa > 4.0, balance < 0, cats should never have more than 1 tail! The effect of concurrent transactions is equivalent to some serial execution Use constraints, triggers, active DB elements (context-free)
Isolation Concurrency control Transactions should not be able to observe the partial effects of other transactions Use locks (whole relations or individual tuples?)
B.Tech (CSE)
- 255 -
KSOU
Durability
If power goes out, nothing bad should happen Once accepted, the effects of a transaction are permanent (until, of course, changed by another transaction) Use logs
Relational Database Design Phases 1. Building the logical data model - process of constructing a model of the information used in an organization based on the relational data model but independent of a particular DBMS or other physical considerations 2. Building the physical database design - process of producing a description of the implementation of the database on a particular DBMS Objectives of Good Relational Database Design: There are many distinct objectives that you must achieve in order to design a good, sound, structured database. You can avoid many of the problems you may encounter by keeping the following objectives in mind and constantly focus on these whilst designing your database. Represent the data and the relationships between data required from the database application. Provide a data model that supports any transactions required on the data. Specify a minimal design that is appropriately structured to achieve the stated performance requirements for the database application. The database supports both required and ad hoc (unplanned) information retrieval. The database must be designed to store the data necessary to support information requirements defined during the design process and any possible ad hoc queries that may be posed by the users. The tables are constructed properly and efficiently. Each table in the database must represent a single subject only and should be composed of relatively distinct fields which keep redundant data to an absolute minimum and should be identified throughout the database by a field with unique values. Data integrity is imposed at the field, table and relationship levels . These levels of integrity help guarantee that the data structures and their values will be valid and as accurate as possible at all times. The database should support business rules relevant to the organization it is designed for. The data must provide accurate information that is always meaningful to the business.
B.Tech (CSE)
- 256 -
KSOU
The database should lend itself to future growth and development . The database structure should be easily modifiable and expendable as the information requirements of the business continue to change and grow. You may find it difficult at times to fulfill all of these objectives, but you'll certainly be pleased with your final database design structure once you've met them.
Benefits of Good Database Design The time that you invest in designing a sound, well structured database is time well spent. Good database design saves you time in the long run because you do not have to spend time constantly revamping a quickly and poorly designed structure. You gain the following benefits when you apply good design techniques: The database structure is easy to modify and maintain . Modifications you make to a table or field will not adversely affect other tables or fields in the database. The data is easy to modify. Changes that you make to the value of a given field will not adversely affect the values of other fields within the table. Furthermore, a well-designed database keeps duplicate fields to an absolute minimum, so you typically modify a particular data value in one field only. Information is easy to retrieve. You should be able to create queries easily due to well constructed tables and the relationships between them are correctly established. End-User applications are easy to develop and build . You can spend more time on programming and addressing the data manipulation tasks at hand, instead of working around the inevitable problems that will arise when you work with a poorly designed database. Problems Resulting from Poor Design A myriad of problems can manifest themselves as a result of poor database design: The database and/or application may not function properly. Data may be unreliable or inaccurate. Performance may be degraded. Flexibility may be lost.
Conventional files and DBMS

All information systems create, read, update and delete data. The data are stored in files and in databases. Files are collections of similar records; a database is the collection of interrelated files. Therefore, the records in each file must allow for some representation of the relationship between files think of them as "pointers" to records in other files. In a file environment, data storage is built around the applications that will use the files such as a mail program; in a database environment, applications will be built around the integrated database.
B.Tech (CSE)
- 257 -
KSOU
Conventional files are relatively easy to design and implement because they are normally based on a single application or information system. However, such files may duplicate data stored elsewhere. Files are also often inflexible, and difficult to scale up if needs change. Historical collections of files that are used but may not be useful for current needs called a "legacy system" are candidates for "re-engineering" that is converting the data into a more flexible, appropriate model, such as that provided by a database system. The advantages of a database model are the ability to share the same data across multiple applications and systems. The data base technology independent of the actual interrelated collection of files is more flexible in storing and updating data. As such, the end-user may be able to use the data in new ways, not specifically designed into the database is equal to "data independence". Additionally, new data (new fields, even) can be added without affecting existing programs. With this increased power come some drawbacks. Database technology is often more complex than file technology. To address this concern, special software, called a database management system (DBMS) is required. Using a DBMS will increase the cost of a project because it requires greater analysis and programming to be effective (hence more time spent by analysts, database administrators, and programmers to learn and use the DBMS). Sharing data means more people can have access to them; as well as submitting the data to more communications technology. Failures or problems can be introduced by the greater number of people using the data (by accident or design) and technology if not applied correctly can add problems (such as the "deadly embrace" when two peoples computers believe each has exclusive use of the data and the computer ends up locking everyone out). To be effective and efficient, then, a database must be carefully designed. The end product, the technical blueprint of the design, is called a database schema. The design phase translates the data models that were developed for the system users during into data structures supported by the chosen database technology. Subsequent to the database design phase, system builders will construct those data structures using the language and tools of the selected technology. A file contains groups of records used to provide information for operations, planning, management and decision making. Types of files are: Master files Table files Transaction files Work files Report files Files can be used to store data for an indefinite period of time or temporarily for a specific purpose. Master files and table files are used to store data for a long period. Temporary files are usually called transaction files, work files or report files. When records are physically in order in a file, then the file is called sequential. When files are stored on direct-access devices (e.g disk), then the options are expanded. Records can be sorted logically using linked lists. Linked lists are obtained by using a set of pointers.
B.Tech (CSE)
- 258 -
KSOU
Direct-access devices permit access to a record by going directly to its address. Hashing is the process of calculating an address from the record key. An index is different from a pointer, since it is stored in a file separate from the data file. Files can be organized in the following ways: Sequential organization. Linked lists. Hashed file organization. Indexed organization. Indexed-Sequential organization.
The Pros and Cons of Conventional Files

Pros: Conventional files are relatively easy to design and implement because they are normally based on a single application or information system. Historically, another advantage of conventional files has been processing speed. Cons: Duplication of data items in multiple files is normally cited as the principal disadvantage of file-based systems. A significant disadvantage of files is their inflexibility and nonscalability.
Database Concepts
Anyone who works with databases should be fluent in the terminology. Below is a list of major concepts that one should know. Reality The real world itself is referred to as reality. Data It is the piece of information collected about people, places or events. Metadata It is the information that describes data. Entity An object or event about which the data is collected is called an entity. Relationships These are associations between entities. Attribute It is some characteristic of an entity. Fields Fields are common both to files and databases. A field is the implementation of a data attribute. Fields are the smallest unit of meaningful data to be stored in a file or database.
B.Tech (CSE)
- 259 -
KSOU
There are four types of fields: Primary keys, Secondary keys, Foreign keys Descriptive keys. Primary keys are fields whose values identify one and only one record in a file. These are unique values. Secondary keys are alternative identifiers for a database; a single file in a database may have only one primary key, but it may have several secondary keys Foreign keys are pointers to the records of a different file in a database. Foreign keys are how the database links the records of one type to those of another type. Descriptive fields are any other fields that store data. Records Fields are organized into a unit, called a record. Like fields, records are common to files and databases. A record is a collection of fields arranged in a predefined format. During systems design, records will be classified either as fixed-length or variable-length records. Most database systems impose a fixed-length record structure, meaning that each record instance has the same fields, same number of fields, and same logical size. Variablelength record structures allow different records in the same file to have different length. Because there is more programming involved and more possible danger to the data, variable-length fields are to be avoided in the traditional DMBS. When a computer programs reads a record in a database, it actually is retrieving a group or block of records at a time. This means the computer does not have to access the hard drive as often (which is very time consuming for a computer). A blocking factor is the number of logical records included in a single read or write operation. The block is also called a physical record. Today, the blocking factor is usually determined and optimized by the chosen database technology, but in some situations the programmer may be allowed to fine tune that blocking factor for better performance.
Key Data items used to identify records. Some Entity-Relationship Diagrams (E-R diagram)
B.Tech (CSE)
- 260 -
KSOU
Here a rectangle represents an entity and a diamond represents a relationship `1' or `M' indicates that whether the relationship is one or many. Using an E-R Diagram to represent the relationships between the Physicians, Patients, Treatments and Prescriptions.
Files and Tables Similar records are organized into groups called "files". A file is the set of all occurrences of a given record structure. In a database system, a file corresponds to a set of similar records, usually called a table. A table is the relational database equivalent of a file. Some special purpose files are master files that contain records that are relatively permanent, not likely to change. The values of the fields that are the specific data in a field may change over its lifetime, but the individual records are likely to remain permanently. A transaction file contains records that describe the organization events such as logon and use records. These data have a limited utility: when useful theyre available
B.Tech (CSE)
- 261 -
KSOU
on-line, when no longer useful, they are "archived" stored to some permanent medium and removed from active systems. Some organizations may keep copies of useful historical data called "document files"; "audit files" are special records of updates to other files, especially mater and transaction files. For example, say a payroll system has been adjusted without authority. The audit file helps track down the differences between the original, correct version and the new, altered one. Databases Databases provide the technical implementation of entities and relationships. Think of a database as the collection of everything an organization considers valuable, represented in some form permitted by the technology. Such important objects need to be protected and managed. Data Architecture: an organizations data architecture is comprised of the files and databases that store all of the organizations data, the file and database technology used to store the data, and the organizational structure set up to manage the data resource. Operational Databases support specifically the day-to-day operations and transactions of the information system. For example, in a library setting, circulation records are a form of operational database. To control access to and manipulation of files, some organizations spin off selected fields into a "data warehouse" that end-users can access. To use the data in the warehouse effectively, there are special software applications (fourth-generation programming languages, query tools (e.g., Brio), and decision support tools) are used to generate reports and analyses from the data warehouse. In larger organizations, there may be a staff of database specialists administered by different people, depending on their role. A data administrator is responsible for data planning, definition, architecture and management. Database architecture refers to the database technology including the database engine, database management utilities, database CASE tools for analysis and design, and database application development tools. The control center of the architecture is its DBMS. The DBMS (database management system) is specialized computer software to create, access, control, and manage the database. The core of the database is its "database engine" the actual algorithms and programming that make it possible create, read, update, search, and delete records. The systems analyst, or database analyst, designs the structure of the data in terms of record types, fields contained in those record types, and relationships that exist between record types. These are defined in the DBMS using its own special language, called a data definition language or DLL. The DLL is used by the DMBS to establish the physical record types, fields, and structural relationships. Additionally, the DDL defines the "views" of the database. Views restrict the portion of the database that may be used or accessed by different users and programs. DDLs record the definitions in a permanent data repository that end-users usually cannot access. Consider a payroll database. The manager of the payroll unit may have access to every staff members employment record. However, we do not want to let everyone see each others salary history or even let all members of the payroll staff see the data that isnt necessary to their job. Thus the managers view might be all fields and all tables; the payroll staff may see only an others pay rate (and not annual salary); while
B.Tech (CSE)
- 262 -
KSOU
the same system may permit staff members to see all of their own record but none of another persons. Some data dictionaries include formal, special software that helps the database specialist track metadata the data about the data such as record and field definitions, synonyms, data relationships, validation rules, help message, and so on. Finally, the manipulation of the data in the database is formalized according to a data manipulation language or DML. The DML is used to create, read, update, and delete records in the database, and to navigate between different records and types of records. The DBMS and DML hide the details concerning how records are organized and allocated to disk. For example, when the end-user clicks on a button that says "Next Record" the user does not know what happens on the disk the "next record" could actually be stored at another location or be assembled from several databases. The user will see only a single record on screen, without having to be informed of all the other behind-the-scenes work performed by the computer to create the record. Relational Databases There are several models of organizing data that can be called "databases." Early forms of DBMS used hierarchies of files or networks with indexes to organize the files. A relational database is different: it is built on a mathematical model of data as if all data were stored in a spreadsheet styled file of columns and rows. Files are seen as having "two-dimensional tables, rows and columns known as relations. All rows are records; all columns are fields. The DBMS is the top-level concept of data. A DDL defines what data and what types of data are valuable to a company (e.g., "Last name" should have up to 25 characters and be stored in a field called "lastname"). A DML determines what can happen to the data in the computer ("delete all records for lastname is Smith"; add a new record for a person whose lastname is Jones). When someone looks for data, the two-dimensional data relationship permits the user to ask questions of the database. For instance, the RDBS permits users to say "list all people whose salary is greater than $50,000 and who live in Chicago". To the computer, this question is interpreted as "retrieve all rows from the file where the column city is equal to Chicago and the column salary is greater than $50,000." There are many database software products: so many that the industry has moved towards a common language for users, called SQL or Structured Query Language. SQL executes the DML and DLL for the user. SQL supports queries by the user, as well as creating, deleting, and maintenance of databases. Some more powerful SQL software products permit saving common user commands as "stored procedures" mini programs embedded in a table that can be called by the application program. Similarly there is the "trigger" which is embedded within a table and it will automatically update the data if related data are updated. Data Analysis Successful databases are those which serve the end-users information needs, are stable, can be manipulated, are robust, shared, and are computationally efficient. These goals constitute "good data" models. As a general rule, the data attributes that describe an entity such as "employee personal information", "monographs", etc. should describe only that entity, not "employees work department". A good data model is essentially nonredundant meaning that each data attribute describes at most only one entity other than
KSOU
foreign keys to which the entity is related. Finally a good model is flexible: it can adapt to future needs without significant impact on current needs. Therefore we must study exactly which data interests us in a process call data analysis. Data analysis is a process that prepares a data model for implementation in a simple, nonredundant, flexible, and adaptive database. The specific technique is called normalization. Normalization is a technique that organizes data attributes such that they are grouped together to form a stable, flexible, and adaptive entities. There are multiple steps in normalization. An entity is in: First normal form or 1NF if there are no attributes that can have more than one value for a single instance of the entity Second normal form or 2NF if it is already in 1NF, and if the values of all nonprimary key attributes are dependent on the full primary key not just part of it Third normal form or 3NF if it is already in 2NF and if the values of its nonprimary key attributes are not dependent on any other non-primary key attributes. There are about 8 normal forms but for most of our purposes, 3NF is sufficient. Steps in database normalization: Remove all repeating groups and identify the primary key. Ensure that all non-key attributes are fully dependent on the primary key. Remove all transitive dependencies. The network data structure can be seen as an extended form of the hierarchic data structure. In a hierarchic data structure, a child record has exactly one parent; while in a network structure, a child record can have any number of parents (including zero). Two types of records: parent child A child record occurrence must have a parent record occurrence; deleting a parent record occurrence requires deleting all its child record occurrences. File Design The most fundamental entities for a data model would be designed as "master" or "transaction" record. A master file is typically fixed-length records. "Associative entities" from the data model are typically joined into the transaction records for form variable length records (based on the one-to-many (1:M) relationship). Other files are added as necessary to fill-out the organizations information need. Note that file access and organization are important decisions for the designer. Should the file be accessed "sequentially" or "randomly"? This decision will impact the overall design and use of the system. Database Design The data model may have to be divided into multiple data models (recall the idea of "decomposition") to reflect database distribution and database replication decisions . Data Distribution refers to the distribution of specific tables, records and/or fields to different physical databases. Data Replication refers to the duplication of specific tables, records, and/or fields to multiple physical databases.
B.Tech (CSE)
- 264 -
KSOU
Note that in the logical design of the system, each sub-model or view should reflect the data to be stored on a single server. Database Schema The design of the database is depicted in a model called the database schema. The database schema is the physical model or blueprint of the database. It represents the technical implementation of the logical data model. The RDBMS schema defines the database structure in terms of tables, keys, indexes, and integrity rules. It should include details about the capabilities, terminology, and constraints of the selected DBMS. Transforming the logical data model into a physical relational database schema rules and guidelines includes the following: Each fundamental, associative, and weak entity is implemented as a separate table: The primary key is identified and implement as an index into the table The secondary keys are implemented as their own index into the table Each foreign key will be implemented as such Attributes will be implemented with fields The fields correspond to columns in the table. For each attribute you will want to identify the data type (alphanumeric, Boolean, logical, numeric (integer, double, float)), size of the field (eg., 25 characters); null or non-null (if a field have a value before the record can be stored to disk, it is a "non-null" field, otherwise it may be a "null"); domains (identify the DMBS that can automatically edit data to ensure that fields contain legal data), and default (what is the default value to be set automatically by the program if the user does not enter a value?). In a data dictionary, each of these elements is defined. Some fields, such as salary, will have acceptable ranges pre-programmed to avoid no salary or illegal ones. This kind of range checking during input is called "data validation" or "domain integrity". The data files themselves have relationships among each others which must be maintained. This is called data and referential integrity; three types are considered here. Key integrity means each table should have a primary key (which may be concatenated). For example, in a staff list, the "lastname" field may be the key. [A concatenated primary key might be "lastname" + "firstname" + "middleinitial" fields.] Primary keys are never null. Domain integrity means controls are designed into the system to ensure that no field takes on a value that is outside the legal values. Referential integrity exists when a foreign key value in one table has no matching primary key in the related table. The mutual-reference between tables must be maintained. To preserve referential integrity, there are different kinds of deletion rules. "No restriction" means any record in the table may be deleted without regard for other tables. "Delete: Cascade" means deletion of a record in the table must automatically be followed by the deletion of a matching record in a related table. For instance, if a person retires from a position, the human resources database will show the termination, but so should any related tables, such as payroll, parking permits, telephone directories, and so on. "Delete: Restrict" means the records in matching tables must first be deleted before the
B.Tech (CSE)
- 265 -
KSOU
data in this table can be deleted. For example, a librarys main collection may delete a holding (say when a book is transferred to a rare materials collection). Circulation records and shelf lists may need to be changed first before the primary database that records the books existence in the main collection is altered to show the transfer. "Delete: SetNull" means all dependent records are set to "NULL". To help clarify the names of fields (something done in the Data Dictionary), some organizations insist that no two fields, regardless of location, have the same name. This is called the role name. A role name is an alternative name for a foreign key that clearly distinguishes the purpose that the foreign key serves in the table.
Planning and Prototyping

Prototyping a database system is the sketching out of main ideas to help shape a schema. It is not a replacement to carefully prepared database schemas. Some software applications will let the designer sketch out the database idea and then help formalize the prototype. Storing the Data One reason the data dictionary outlines the size, type and location of all data is because the database administrator must estimate the size of disk capacities for the project. Database capacity planning can be easily calculated. 1. For each table, sum the field sizes. This creates the record size for the table. 2. For each table, multiply the record size times the number of entity instances to be included in the table. This creates the table size. 3. Sum the table sizes. This makes the database size. 4. Optionally, add a slack capacity buffer (e.g., 10%) to account for unanticipated factors or inaccurate estimates. This is called the anticipated database capacity.
Database Organization
A database, unlike a file, is intended to be shared by many users. There are three main types of logically structured databases: o Relational o Hierarchical o Network Relational Databases A relational database is perceived by the user as a collection of time varying, normalized relations. Time varying means that the set of tuples in any given relation change with time. Each file contains only one record type. The fields have no particular order, left to right. The records have no particular order, top to bottom. Every field is single valued. The records have a unique identifier field or field combination called the primary key.
B.Tech (CSE)
- 266 -
KSOU
Hierarchical Data Structures A hierarchic database consists of an ordered set of trees. What is a tree? Trees in the form of a family tree or genealogical tree trace the ancestry of an individual and show the relationships among the parents, children, cousins, uncles, aunts and siblings. A tree is thus a collection of nodes. One node is designated as the root node; the remaining nodes form trees or sub trees. An ordered tree is a tree in which the relative order of the sub trees is significant. This relative order not only signifies the vertical placement or level of the sub trees but also the left to right ordering. A hierarchical tree can have any number of record occurrences for each record type at each level of the hierarchical tree.
The hierarchical data model has the following constraints: Each hierarchical tree can have only one root record type and this record type does not have a parent record type. The root can have any number of child record types, each of which can itself be a root of a hierarchical (sub) tree. Each child record type can have only one parent record type; thus manyto-many relationships can not be directly expressed between two record types. Data in a parent record applies to all its children's records. Each occurrence of a record type can have any number of occurrences of each of its child record types. The Hierarchical Data Model (HDM) uses the tree concept to represent data and the relationship among data. The nodes of the tree are the record types representing the entity sets and are connected by pointers or links. The relationship between the entities is represented by the structure of the resulting ordered tree.
B.Tech (CSE)
- 267 -
KSOU
Database design guidelines From this basic description, the following database design rules emerge: Each record should contain a unique identifier as the primary key such as an employee ID, a part number, or a customer number. The primary key is typically the column used to maintain each record's unique identity among the tables in a relational database. Databases allow you to use multiple columns for the primary key. When you define a column, you define a SQL data type for the column, such as allowing only numeric values to be entered in the salary column. Assessing user needs and incorporating those needs in the database design is essential to a successful implementation. A well-designed database accommodates the changing data needs within an organization. Each separate data entity should create a master file. A specific data field should exist only on one master file. Each master file or database relation should have programs to Create, Read, Update and Delete the records.
The following are the steps used for the retrieval and presentation of a data: Choose a relation from the database. Join two relations together. Project columns from the relation. Select rows from the relation. Derive new attributes. Index on sort and rows. Calculate totals and performance measures. Present data.
**************
B.Tech (CSE)
- 268 -
KSOU
UNIT 16
PROJECT MANAGEMENT
Project Definition
A project is a unique set of coordinated activities, with definite starting and finishing points undertaken by an individual or organization to achieve some specific objectives within defined time, cost and performance constraints. A project is a group of milestones (or phases or activities or tasks) to accomplish some well-defined objective. Project can also be defined as a temporary endeavor undertaken to create a unique product, service or result. A project ends when its objectives have been reached or the project has been terminated. Projects can be large or small and take a short or long time to complete. A project can also be viewed as a sequence of unique, complex, interrelated activities having a goal or purpose that must be completed by a specific time, within budget and according to specifications or requirements of end users. Projects are different from standard business activities as they Are unique in nature. They do not involve repetitive processes. Every project differs from other project carried out by the same or different organization. Have finite time duration. Projects have well-defined start and end dates identified in the beginning phase of the project itself. Have an approved budget. The organization allocates certain budget for the finical expenditures during the project.
B.Tech (CSE)
- 269 -
KSOU
Use limited resources. The organization allocates required amount of systems, equipments, programmers, labors, etc at the early stage of the project itself. Involve some level of risk. Often projects entail certain level of uncertainty which inturn leads to risk.
An activity or task is the smallest unit of work effort within the project and consumes both time and resources which are under the control of the project manager. A project is a sequence of activities that has a definite start and finish, an identifiable goal and an integrated system of complex but interdependent relationships. A schedule allocates resources to accomplish the activities within a timeframe. The schedule sets priorities, start times and finish times. Every project is constrained by the following three goals as illustrated in figure 16.1: Scope Time Scope goals that tell what work will be done? Time goals that tell how long should it take to complete the project? Cost goals that tell what should it cost? Cost
It is the responsibility of the project manager to balance these three often-competing goals in the organization to succeed in the project. Features of projects Projects are often carried out by a team of people who have been assembled for that specific purpose. this team may be project manager.
Fig 16.1: Project Constraints
The activities of coordinated by a
Project teams may consist of people from different backgrounds and different parts of the organization. In some cases project teams may consist of people from different organizations.
Project teams may be inter-disciplinary groups and are likely to lie outside the normal organization hierarchies.
B.Tech (CSE)
- 270 -
KSOU
The project team will be responsible for delivery of the project end product to some sponsor within or outside the organization. The full benefit of any project will not become available until the project as been completed.
B.Tech (CSE)
- 271 -
KSOU
Project Management
Project Management is the process of planning, monitoring and controlling all aspects of a project. It also involves motivation of the individuals involved in achieving the project objectives on time as per the specified cost, quality and performance. It is a dynamic process that utilizes the required resources of the organization in a structured manner, to achieve the set goals. It is always conducted within a defined set of constraints. Thus, Project management is the application of skills, tools and management process to project activities to meet project requirements. Project Management comprises of A set of skills, specialized knowledge and required amount of experience to eliminate or at least reduce the level risk within the project and to enhance the likelihood of its success. A suite of tools such as planning tools, documentation tools, testing tools, etc., to help project managers to effectively manage the project. A series of management process inorder to monitor and control various activities, resources, cost and quality of the project. Different authors, organizations, project managers, CEOs give different definition for Project Management. Some of these include: The techniques & tools used to describe, control & deliver a series of activities with given deliverables, timeframes & budgets. The methods and disciplines used to define goals, plan and monitor tasks and resources, identify and resolve issues, and control costs and budgets for a specific project. Process of managing or coordinating all elements of a project from start to finish. Project Management is the discipline of organizing and managing resources in such a way that these resources deliver all the work required to complete a project within defined scope, quality, time and cost constraints.
B.Tech (CSE)
- 272 -
KSOU
A controlled process of initiating, planning, executing, and closing down a project. A set of well-defined methods and techniques for managing a team of people to accomplish a series of work tasks within a well-defined schedule and budget.
Project management is the planning and control of events that, together, comprise the project. It aims to ensure the effective use of resources and delivery of the project objectives on time and within cost constraints. Different stakeholders are involved project management. Stakeholders are people who are involved in or affected by project activities. Some of the stakeholder includes: Project sponsor Project manager Project team Support staff Customers Users Suppliers Opponents to the project
The purpose of project management is to achieve successful project completion with the resources available. A successful project is one which: has been finished on time is within its cost budget performs to a technical/performance standard which satisfies the end user.
Importance of Project Management The importance of project management can be visualized from the following two perspectives:
It effectively keeps track or measures the progress achieved towards the objective that needs to be accomplished. It is also used as an aid to optimally use the resources to accomplish our goals.
KSOU
It enables project manager to map out a course of action or work plan It helps all project team members to think systematically and thoroughly Effective project management helps to complete work within time bound.
Project management functions

Knowledge areas are the core to any project management. Knowledge areas are basically those that describe the key competencies that project managers must develop and implement them in the project in order to succeed as a successful project manager. There are nine such key knowledge areas that a project manager must master. The nine knowledge areas can be classified into three categories. First category includes four core knowledge areas leading to specific project objectives. These include scope management, time management, cost management, and quality management. First category includes four facilitating knowledge areas through which the project objectives are achieved. The four facilitating knowledge areas are human resources management, communication management, risk management and procurement management. Finally the third category includes one knowledge area called project integration management that affects and is affected by all of the other knowledge areas. The figure 16.2 illustrates these knowledge areas.
Project objectives specific knowledge areas
Scope Management
Time Management
Cost Management
Quality Management
Project Integration Management
B.Tech (CSE)
- 274 -
KSOU
Project facilitating knowledge areas Human Resource Management Communication Risk Management Management Management Procurement
Figure 16.2 Nine Knowledge Areas focusing Project Management Functions
Project objectives specific functions

Scope Management Defining and managing all the work required to successfully complete the project. Charters should be developed for each project. A formal process should be developed for change management including the estimate in cost of making the change. Scope of the project needs to be clearly defined in the project charter. To avoid scope creep, any changes to scope must be documented and a formal approval must be obtained before changing the scope of the project. Need to determine who can make decisions and differentiate based on magnitude
of decision. Not every project decision should go to the Steering Committee. Time Management Estimating how long it will take to complete work, develop project schedule, and ensure completion. Project Schedule For each project a project schedule should be defined early on. Tasks should be identified down to the task/person level. Project schedule templates (plans for software upgrades, software development etc) should be developed so that project managers have a pool to pull from. All projects that have more than 5 resources and have duration of longer than 1 month should utilize Microsoft Project to develop a project schedule.
B.Tech (CSE)
- 275 -
KSOU
Requirements should be done prior to development work. In areas where business changes are needed, significant time should be allotted to do this.
Include entire project team in planning. This will help minimize tasks being overlooked in the plan.
Break the project into small pieces. Not all functionality has to be delivered with one release.
Time needed for the project by the various resources needs to be better identified. Often the time is underestimated.
Cost Management Preparing and managing a budget Budget guidelines need to be established prior to project Need to determine who has the authority to make certain budget decisions A budget identifying the total cost of ownership of an application should be developed. Some costs that need to be identified and budgeted for are: 1. Consultants as we continue to purchase more applications. Our dependency on consultants will continue. This needs to be budgeted as a recurring cost with each upgrade. 2. Maintenance agreements will be a recurring cost of owning purchased applications. 3. Travel and professional development the skills needed to support these new applications requires staff to learn new technology as well as develop partnerships with other institutions utilizing the same software. This is a recurring cost and should be budgeted for accordingly. Quality Management Ensures the project will satisfy stated or implied needs
B.Tech (CSE)
- 276 -
KSOU
A formal customer sign-off process is needed. Ensure the scope statement has specific measures of success so that it is easier to determine if a project has been successful at meeting the objectives.
Project facilitating functions Human Resource Management Making effective use of people. Knowledgeable resources should be identified for the project team and involved as soon as possible. If staffs are unable to devote time necessary, then tasks should be prioritized. End users should be involved early in the project and updated throughout. If a project requires some special skills (i.e. knowledge of SQL etc..), staff need to have the training made available at the right time. This may be something that should be included in the project plan training assessments of project team. Staff should be given release time for participating in projects spanning a long time or requiring significant staff effort. Clearly define staff roles and responsibilities.
Communications Management Generating, collecting, disseminating, storing project information. A communication plan should be developed to outline what gets communicated to whom and who is responsible for the communication. For example, what information gets communicated to the Steering Committee?
B.Tech (CSE)
- 277 -
KSOU
Sponsor Meetings - regular meetings should be established with sponsor to ensure they are aware of project status. Frequency should be based on project size and turnaround time. The larger the project, the more infrequent (monthly) the meetings should be. Format of agenda should be consistent.
Team Meetings - regular meetings should be established with project team to ensure tasks completed, that they are aware of important deadlines etcAgendas should be developed and minutes should be completed with action items.
Point of Contacts POCs should be identified for major groups (i.e. IT, testers, business areas etc). Sometimes it is difficult to ensure if people read email regarding important dates etcThe POC is responsible for ensuring their area is aware of information relating to them.
Majordomo - mail lists may also be developed so that the project team can communicate freely with each other.
Risk Management Identifying, analyzing, and responding to risks Risks need to be identified prior to project. In addition, procedures on how to handle these risks if they arise need to be documented. A
Staff turnover will most likely occur on projects spanning a long time.
management plan needs to be devised on how new staff will be brought up to speed. Procurement Management Acquiring or procuring goods and services that are needed from outside the organization. It may be necessary to hire outside consultants for larger projects. This may allow implementations to run smoother as the consultants can alert us to issues.
B.Tech (CSE)
- 278 -
KSOU
Project Integration Management Overarching function that affects and is affected by all other knowledge areas. Close interaction with vendor is needed to understand changes with new versions (i.e. what current functionality wont exist in new version). Project Plan should be developed and include: 1. Overview of the project - description, sponsors, stakeholders, deliverables 2. Organizational structure of the project authority of project manager and steering committee, responsibilities and communication for the project, reporting structure of project 3. Management and technical approaches management objectives, project controls (status reports, how to handle changes), risk management, project staffing plan, technology methodologies 4. Scope management plan WBS (work break-down structure) or high level task list, key deliverables 5. Project schedule summary and detailed 6. Budget summary and detailed, assumptions 7. A project should be broken down into small manageable pieces rather than implementing everything at once. Periodic reviews should occur to determine if the project should continue. Miscellaneous Functions Testing 1. Should be detailed scripts should be developed for minimal testing. This doesnt mean that other testing is not also needed. 2. Parallel testing when at all possible, it is best to be able to test the old version in conjunction w/ the new version. This helps identify
KSOU
gaps. 3. Issue list should be maintained throughout project to ensure issues are resolved before implementation or at least be aware that those issues exist. 4. Instances (QA/DEV/Production) when testing, instances need to be compatible to ensure the needed functionality is transferred from one version to the next. 5. Issues found after testing should be included in test scripts to detect in future upgrades/enhancements to the system. Training 6. Evaluations may be needed to determine if there is additional training that is needed. Be careful in assumptions regarding knowledge level of the users. 7. Adequate time should be allowed for training. A common theme in all feedback was that there wasnt enough time for testing. Need to identify a rule of thumb for project managers to use as a guide. 8. QA instance needs to be frozen when training material development starts.
Project Success Factors A project is teamwork. Therefore its success is dependent on several factors. Some of the key factors that can lead a project to be successful include: Top management or executive support to the project team. User involvement in specifying clear, unambiguous requirements and during testing stages. Experienced project manager who has sound managerial and leadership skills required for project.
B.Tech (CSE)
- 280 -
KSOU
Clear business objectives. Project having a minimized narrow scope rather than a maximized broader scope. Usage of standard software infrastructure. Enough amount of resource that are required. Usage of formal methodology for system development. Reliable estimates. A good project team having proper coordination.
Apart from the above key factors, other factors such as small milestones, proper planning, competent staff, and ownership are equally important for the project to succeed.
Causes of Project Failure

Inspite of having project manager, team members and user involvement some projects do not succeed. Some of the causes that lead to project failure are: Failure to establish upper-management commitment to the project. Lack of organizations commitment to the formal methodology of project development. Taking shortcuts through or around the formal methodology that may lead to incorrect results. Poor expectations from management resulting from o Feature creep o Scope creep Premature commitment to a fixed budget and schedule. Usage of improper planning and estimation techniques. Inexperienced project manager or project manager with inadequate people management skills. Failure to adapt to business change. Insufficient resources to carry out the project. Ambiguous or incorrect requirement specification. Poor design, due to lack of technically sound team members. Improper risk management.
B.Tech (CSE)
- 281 -
KSOU
Advantages of Project Management

In built Monitoring/ Sequencing Easy and Early identification of Bottlenecks Activity based costing Identification and Addition of missing and new activities Preempting unnecessary activity/expenditure Timely Completion Assigning tasks Reporting
Better control of financial, physical, and human resources. Improved customer relations. Shorter development times. Lower costs. Higher quality and increased reliability. Higher profit margins. Improved productivity. Better internal coordination. Higher worker morale (less stress).
Project Manager Project manager is the person responsible for supervising a systems project from initiation to conclusion. Project manager works with project sponsors, project teams, and other people involved in projects to meet project goals. A major role of a project manager is to ensure that the project succeeds. Responsibilities of the Project Manager To plan thoroughly all aspects of the project, soliciting the active involvement of all functional areas involved, in order to obtain and maintain a realistic plan that satisfies their commitment for performance. To control the organization of manpower needed by the project.
B.Tech (CSE)
- 282 -
KSOU
To control the basic technical definition of the project, ensuring that "technical" versus "cost" trade-offs determine the specific areas where optimization is necessary. To lead the people and organizations assigned to the project at any given point in time. Strong positive leadership must be exercised in order to keep the many disparate elements moving in the same direction in a co-operative. To monitor performance, costs and efficiency of all elements of the project and the project as a whole, exercising judgement and leadership in determining the causes of problems and facilitating solutions. To complete the project on schedule and within costs, these being the overall standard by which performance of the project manager is evaluated.
Project Manager Skills Project managers need both hard and soft skills. Hard skills include product knowledge and knowing how to use various project management tools and techniques. Soft skills include being able to work with various types of people. Some of the skills required include: Communication skills to listen and communicate ideas and tasks. Organizational skills like planning, goal setting and problem domain analysis. Team-building skills like motivation, showing empathy, etc. Leadership skills like lead by examples, providing vision, work delegation, etc. Coping skills like being flexible, creative, patient and persistent. Technology skills like domain expertise, tool skills, programming skills, experience, project knowledge, etc. Effective project managers provide leadership by example. A leader focuses on long-term goals and big-picture objectives while inspiring people to reach those goals. A manager deals with the day-to-day details of meeting specific goals. Thus project managers often take on both leader and manager roles. Project Management Tools & Techniques Gantt Chart Henry Laurence Gantt (1861-1919) a mechanical engineer, management consultant and industry advisor developed a tool for displaying the progression of a project in the form
KSOU
of a specialized chart called Gantt charts in the second decade of the 20 th century. Gantt charts are being used as a visual tool to show scheduled and actual progress of projects. A Gantt chart is a horizontal bar or line chart which will commonly include the following features: Activities identified on the left hand side;

Time scale is drawn on the top (or bottom) of the chart; A horizontal open oblong or a line is drawn against each activity indicating estimated duration; Dependencies between activities are shown; At a review point the oblongs are shaded to represent the actual time spent (an alternative is to represent actual and estimated by 2 separate lines); A vertical cursor (such as a transparent ruler) placed at the review point makes it possible to establish activities which are behind or ahead of schedule.
A basic sample of Gantt chart is illustrated in figure 16.3 Task Duration Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1 2 3 4 5 6 2 mo. 2 mo. 2 mo. 2 mo. 2 mo. 2 mo.
Fig. 16.3 Gantt Chart Format
The horizontal axis of the Gantt chart is a time scale, expressed either in absolute time or in relative time referenced to the beginning of the project. The time resolution depends on the project - the time unit typically is in weeks or months. Rows of bars in the chart show the beginning and ending dates of the individual tasks in the project. In the above example, each task is shown to begin when the task above it completes. However, the bars may overlap in cases where a task can begin before the completion of another, and there may be several tasks performed in parallel. For such cases, the Gantt chart is quite useful for communicating the timing of the various tasks.
KSOU
For larger projects, the tasks can be broken into subtasks having their own Gantt charts to maintain readability. The strength of the Gantt chart is its ability to display the status of each activity at a glance. While often generated using project management software, it is easy to construct using a spreadsheet, and often appears in simple ASCII formatting in e-mails among managers. In the 1980s, personal computers eased the creation and editing of elaborate Gantt charts. These desktop applications were intended mainly for project managers and project schedulers. In the late 1990s and early 2000s, Gantt charts became a common feature of web-based applications, including collaborative groupware. Some of the poject management tools incorporating Gantt Charts include PRINCE, MacProject and Microsoft Project. Although a Gantt chart is useful and valuable for small projects that fit on a single sheet or screen, they can become quite unwieldy for projects with more than about 30 activities. Larger Gantt charts may not be suitable for most computer displays. A related criticism is that Gantt charts communicate relatively little information per unit area of display. That is, projects are often considerably more complex than can be communicated effectively with a Gantt chart. Gantt charts only represent part of the triple constraints of projects, because they focus primarily on schedule management. Moreover, Gantt charts do not represent the size of a project or the relative size of work elements, therefore the magnitude of a behindschedule condition is easily miscommunicated. If two projects are the same number of days behind schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not represent this difference. Although project management software can show schedule dependencies as lines between activities, displaying a large number of dependencies may result in a cluttered or unreadable chart. Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the time-phased workload (resource requirements) of a project. A related criticism is that all activities of a Gantt chart show planned workload as constant. In practice, many activities (especially summary elements) have front-loaded or back-loaded work plans, so a Gantt chart with percent-complete shading may actually miscommunicate the true schedule performance status.
Work breakdown structure (WBS)

The work breakdown structure (WBS) is a key document in the project it forms the basis of much of the planning, setting budgets, financial control, defining the organization and assigning responsibilities.
KSOU
Breaking the work into manageable units is key to controlling the project. Viewing the project, as a whole can be overwhelming, therefore, breaking the project into small chucks makes it more appealing. It is also possible to identify and delegate work to other members of the project team. The work breakdown structure is illustrated in figure 16.4 Project Task 1 Task 2 Task N Sub Task 1.1 Sub Task 1.2 Work Package 1.1.1 Work Package 1.1.2
Fig 16.4: Work Breakdown Structure Diagram
Each level of the WBS is often called a task. How many levels you have will vary by project, generally the bigger the project the more levels. Up to about 5 is fine. If you have more than this, you should think about initiating sub-projects to deal with legs of the WBS. Anything over 10 levels and the project scope is probably flawed and needs rechecking. At the higher level (top) appear the phases of the project (usually the phases in the project plan). Beneath this are all the tasks that have to be performed to complete the phase. The following figure 16.5 illustrates a WBS for Publish Series.
Publish Series Design jacket Improve manuscript PREPRODUCTION Print Design layout PRODUCTION Advertising campaign Sales drive ROLL OUT
Fig 16.5: WBS for Publish Series
Since WBS is a hierarchical structure, it may also be conveyed in outline form as: Level 1 Task 1 Level 2 Level 3
B.Tech (CSE)
- 286 -
KSOU
Subtask 1.1 Work Package 1.1.1 Work Package 1.1.2 Work Package 1.1.3 Subtask 1.2 Work Package 1.2.1 Work Package 1.2.2 Work Package 1.2.3 Task 2 Subtask 2.1 Work Package 2.1.1 Work Package 2.1.2 Work Package 2.1.3
Each organization uses its own terminology for classifying WBS components according to their level in the hierarchy. For example, some organizations refer to different levels as tasks, sub-tasks, and work packages, as shown in the above outline. Others use the terms phases, entries, and activities. The work breakdown structure is the foundation of project planning. It is developed before dependencies are identified and activity durations are estimated. The WBS can be used to identify the tasks in the CPM and PERT project planning models. Program Evaluation and Review Technique Most of the projects are complex in nature. They require a series of activities, some of which must be performed sequentially and others in parallel with other activities. The collection of series and parallel tasks can be modeled as a network. In 1957 the Critical Path Method (CPM) was developed as a network model for project management and was first used to assist in the development and building of chemical plants within the DuPont Corporation. CPM is a deterministic method that uses a fixed time estimate for each activity. While CPM is easy to understand and use, it does not consider the time variations that can have a great impact on the completion time of a complex project. The Program Evaluation and Review Technique (PERT) is one of the most commonly used network model for project management designed to analyze and represent the tasks involved in completing a given project. PERT was introduced in 1958 following research
B.Tech (CSE)
- 287 -
KSOU
within the Special Projects Office of the US Navy. It was initially used to plan and control the Polaris missile programme which involved the coordination of thousands of contractors. The use of PERT in this case was reported to have cut eighteen months off the overall time to completion. It has the potential to reduce both the time and cost required to complete a project. PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. PERT simplify the planning and scheduling of large and complex projects. It incorporates uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is an event-oriented technique rather than start- and completion-oriented, and is used more in projects where time, rather than cost, is the major factor. It is applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development projects. In any project before beginning the current activity all of its predecessor activities must be completed. Project network models represent activities and milestones by arcs and nodes. PERT originally was an activity on arc (AOA) network, in which the activities are represented on the lines and milestones on the nodes. Over time, some people began to use PERT as an activity on node (AON) network. A PERT chart can have multiple pages with multiple sub-tasks. The milestones generally are numbered so that the ending node of an activity has a higher number than the beginning node. The activities can be labeled with letters along with the expected time required to complete the activity. There are six stages common to both PERT and CPM: Define the project and specify all activities or tasks. Develop the relationships amongst activities. Decide upon precedence. Draw network to connect all activities. Assign time and/or costs to each activity. Calculate the longest time path through the network: this is the "critical path". Use network to plan, monitor and control the project. Define the project and specify all activities or tasks In a project an activity is a task that must be identified and performed to complete the project. The milestones are the events marking the beginning and end of one or more activities. Hence as a first step we need to specify all activities and milestones.
B.Tech (CSE)
- 288 -
KSOU
Develop the relationships amongst activities Once all the activities are identified, the relationship or the order in which the activities must be sequenced for execution are to be identified. The precedence among similar kind of activities must also be identified. This step may be combined with the activity identification step since the activity sequence is evident for some tasks. Draw network to connect all activities Draw a network diagram using the activity relationship information. The network diagram must illustrate the sequence activities that are serial and parallel. In an activityon-arc model, the activities are represented using an arrowed lines and milestones are represented through circles or bubbles. If done manually, several drafts may be required to correctly portray the relationships among activities. Software packages simplify this step by automatically converting tabular activity information into a network diagram. Assign time and/or costs to each activity Once the all activities are connected and represented using network diagram, the time and optionally cost can be indicated. Time is commonly indicated using week (s) as the representational unit for activity completion, but any consistent unit of time can be used. A distinguishing feature of PERT is its ability to deal with uncertainty in activity completion times. For each activity, the model usually includes three time estimates:
Optimistic time: It is the shortest time in which the activity can be completed. Optimistic times are specified to be three standard deviations from the mean so that there is approximately a 1% chance that the activity will be completed within the optimistic time. Most likely time: It is the completion time having the highest probability. Most likely time is different from the expected time. Pessimistic time: It is the longest time that an activity might require. Three standard deviations from the mean is commonly used for the pessimistic time.
PERT assumes a beta probability distribution for the time estimates. For a beta distribution, the expected time for each activity can be approximated using the following weighted average: Expected time = (Optimistic + 4 X Most likely + Pessimistic) / 6 This expected time may be displayed on the network diagram. To calculate the variance for each activity completion time, if three standard deviation times were selected for the optimistic and pessimistic times, then there are six standard deviations between them, so the variance is given by: [(Pessimistic - Optimistic) / 6]2
B.Tech (CSE)
- 289 -
KSOU
Calculate the Critical Path The critical path is determined by adding the times for the activities in each sequence and determining the longest path in the project. The critical path determines the total calendar time required for the project. If activities outside the critical path speed up or slow down (within limits), the total project time does not change. The amount of time that a noncritical path activity can be delayed without delaying the project is referred to as slack time. The objective of critical path analysis is to determine times for the following: ES = Earliest Start Time. This is the earliest time an activity can be started, allowing LS = Latest Start Time. This is the latest time an activity can be started without for the fact that all preceding activities have been completed. delaying the start of following activities which would put the entire project behind schedule. EF = Earliest Finish Time. The earliest time an activity can be finished. LF = Latest Finish Time. The latest time that an activity can finish for the project to S = Activity Slack Time. The amount of slippage in activity start or duration time
remain on schedule. which can be tolerated without delaying the project as a whole. If ES and LS for any activity is known, then one can calculate values for the other three times as follows: EF = ES + t LF = LS + t S = LS - ES or S = LF - EF Analysis of the project normally involves: 1. Determining the Critical Path. The critical path is the group of activities in the project that have a slack time of zero. This path of activities is critical because a delay in any activity along it would delay the project as a whole.
B.Tech (CSE)
- 290 -
KSOU
2. Calculating the total project completion time, T. This is done by adding the activity times of those activities on the critical path. The steps in critical path analysis are as follows: a) Determine ES and EF values for all activities in the project: the Forward Pass through the network. b) Calculate LS and LF values for all activities by conducting a Backward Pass through the network. c) Identify the critical path which will be those activities with zero slack (i.e.: ES=LS and EF=LF). d) Calculate total project completion time. Since the critical path determines the completion date of the project, the project can be accelerated by adding the resources required to decrease the time for the activities in the critical path. Such a shortening of the project sometimes is referred to as project crashing. Use network to plan, monitor and control the project Use the above constructed network model to plan, monitor and control the project so that triple constraints of the projects are satisfied. Make adjustments if needed in the PERT chart as the project progresses. For instance in cases where there are delays, additional resources may be needed to stay on schedule and the PERT chart may be modified to reflect the new situation. PERT Example: A project has been defined to contain the following list of activities along with their required times for completion: Activity No 1. 2. 3. 4. 5. 6. 7. 8. Expected completion time Requirements collection 5 Screen design 6 Report design 7 Database design 2 User documentation 6 Programming 5 Testing 3 Installation 1 Activity
Dependency 1 1 2,3 4 4 6 5,7
B.Tech (CSE)
- 291 -
KSOU
a. Draw a PERT chart for the activities. b. Calculate the earliest expected completion time. c. Show the critical path.
B.Tech (CSE)
- 292 -
KSOU
a. PERT Chart construction Using information from the table the PERT chart in figure 16.6 show the sequence of activities.
1 2 3 4 5 6 8 7
b. Earliest expected completion time calculation

1 2 3 4 5 6 8 7 5 6 7 2 6 5 3 1 TE = 5 TE = 11 TE = 12 TE = 14 TE = 20 TE = 19 TE = 22 TE = 23
Using information from the table, indicate expected completion time for each activity.
Calculate earliest expected completion time for each activity (TE) and the entire project.
B.Tech (CSE)
- 293 -
KSOU
Hint: the earliest expected completion time for a given activity is determined by summing the expected completion time of this activity and the earliest expected completion time of the immediate predecessor. Rule: if two or more activities precede an activity, the one with the largest TE is used in calculation (e.g., for activity 4, we will use TE of activity 3 but not 2 since 12 > 11).
B.Tech (CSE)
- 294 -
KSOU
c. Critical path identification

1 2 3 4 5 6 8 7 5 6 2 6 5 3 1 TE = 5 TE = 11 TE = 12 TE = 14 TE = 20 TE = 19 TE = 22 TE = 23
The critical path represents the shortest time, in which a project can be completed. Any activity on the critical path that is delayed in completion delays the entire project. Activities not on the critical path contain slack time and allow the project manager some flexibility in scheduling.
Module 6 Unit 17 System Design

Introduction Based on the user requirements and the detailed analysis of a new system, the new system must be designed. This is the phase of system designing. It is a most crucial phase in the development of a system. Normally, the design proceeds in two stages: Preliminary or general design Structure or detailed design
B.Tech (CSE)
- 295 -
KSOU
Preliminary or general design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Structure or Detailed design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a blue print of a computer system solution to a given problem having the same components and inter-relationship among the same components as the original problem. Input, output and processing specifications are drawn up in detail. In the design stage, the programming language and the platform in which the new system will run are also decided.
This chapter introduces techniques for the design of interfaces, menus, and databases, based on the requirement specification worked out during the analysis phase (functioning diagram, relationship diagram, data flow diagram...). At the end of this phase, you need to identify the borderline between the computer system and human being and find the answer to the question of how to attain the system's objectives. Focused on the final design specification and the construction, development, and implementation of the solution proposed during analysis and deemed best among any alternatives available.
The overall designing specifications By definition, analysis and design are two separate activities. However, in practice, the two development activities are so intertwined that no one can say exactly when analysis ends and design begins. For example, design ideas are often conceived during the preparation of documents such as Functioning diagrams, Data flow diagrams, Entity relationship diagrams, Data dictionaries, Specification process from the formal specification of user requirements.
B.Tech (CSE)
- 296 -
KSOU
The design of an appropriate information system requires that analysts understand the goals and objectives of management. They must also be sensitive to changes that may occur to these goals and objectives over time in response to shifts in the competitive environment.
Overview of structured design: The lofty goals of Structured design are accomplished through the consistent implementation of specific philosophical views. One of these, functionality, is stressed throughout the practice of Structured design. At the heart of this method is the notion that a program, a group of programs, or a group of systems is nothing more than a collection of functions. Structured design is the result of a desire on the part of its authors to formalize what they consider to be good programming practice. A beneficial side effect for the software engineering is that what is easy to maintain is also relatively easy and inexpensive to construct. Thus, Structured Design is a software design method which closely parallels the current trend in technology toward systems which are once easy to maintain and inexpensive, or at least cost-effective, to construct. The designer must at first see through the programs, modules, and routines and examine relationships. One must temporarily forget about how the systems at hand might be implemented and treat it as a collection of abstractions-logical functions. This gives the software designer a maximum freedom in examining relatively system architectures. The mapping logical functions in to physical modules are delayed until the late stages of design effort. The outstanding unique aspect of Structured Design is that it includes several different ways of evaluating a design. (Another is that only one the design quality criteria into it may be applied to any software design, not just those produced using this method. Structured Design's evaluation criteria challenge software engineers in three ways: The suppression of coding issues, making these issues subservient to design principles. Acceptance of system view and not the local view as key indicator of success or failure Resolution of issues related to finishing the design though application of predetermined value systems.
B.Tech (CSE)
- 297 -
KSOU
Structured design provides two effective means of evaluating software design decisions. One measures the relative effect of the decision on module quality, while the other measures the relative effect of the decision on the relationship between modules. The introduction of Structured Design can only work when it provides all concerned with a common value system, that is, a uniform view of what is or is not desirable in a system. Although the approach may differs from organization to organization, followings are some guidelines to maximize the benefit of introducing Structured Design into an organization: Make it clear from the start that Structured Design is not a remedy for any problems of the organization Obtain support from anyone who may be affected by this change Emphasize the flexibility that Structured Design provides and downplay the misconception that it is restrictive Structured Design development passes through two primary phases: Logical Design development and Physical Design development. Logical Design transforms the dataflow diagrams developed during the Structured Analysis phase into refining the design to reflect the kinds of quality attributes that Structured Design encourages. Physical Design phase involves the modification of the Logical design to accommodate whatever changes necessary As a process, design goes through the following stages: Transformation of the problem model into an initial solution model Embellishment of initial design to include necessary features Transformation of the structured English into pseudocode Evaluation and refinement of the qualities of the design Revise the design to accommodate implementation constraints Design is an exact blueprint of what will be built and a basis for the configuration and content of that blueprint.
System Design Goals and Objectives:

KSOU
Improve Quality and reduce the risk of system failure Establish concrete requirements documentation Focus on Reliability, Flexibility, and Maintainability of system specifications and complete requirements
The design objectives specified in the user implementation model are the quality of the design. The ability of the programmers to implement a high-quality, error-free system depends very much on the nature of the design created by the designer; also, the ability of the maintenance programmers to make changes to the system after it has been put into operation and to the expanded system depends on the quality of the design.
The field of structured design contains a number of guidelines that help designer determine which modules, and which interconnections between the modules will best implement the requirements specified by the systems analysis. The most important guidelines are coupling and cohesion:
Cohesion: is the degree to which the components of a module are necessary and sufficient to carry out one, single, well defined function. In practice, this means that the systems designer must ensure that they does not split essential processes into fragmented modules and the systems designer must ensure that they does not gather together unrelated processes (represented as processes on the DFD) into meaningless modules. The best modules are those that are functionally cohesive. The worst modules are those that are coincidentally cohesive.
Coupling: is the degree to which modules are interconnected with or related to one another. The stronger the coupling between modules in a system, the more difficult it is to implement and maintain the system, because a modification to one module will then necessitate careful study, as well as possible changes and modifications, to one or more other modules. In practice, this means that each module should have simple, clean interface with other modules, and that the minimum number of data elements should be shared between modules.
B.Tech (CSE)
- 299 -
KSOU
As we have seen, the first step of designing a process is to map the essential model of user requirements onto a configuration of processors. Then, within each processor, the designer must decide how to allocate processes and data to different tasks. Finally, we must organize the processes within each task into a hierarchy of modules, using modeling tool. There are several tools and techniques used for designing. These tools and techniques are:

Flowchart Data flow diagram (DFDs) Data dictionary Structured English Decision table Decision tree
Each of the above tools is used for designing a system. Key issues that are to be considered while selecting the Design Strategy: Method of acquisition System functionality Software development Implementations schedule
Structured Design (SD) Nature of SD is achieved (implemented) by dividing the system in independent modules (separate pieces) that can be designed, implemented and modified with no (or little) effect on other modules of the system. Coarse (tho) program structure, based on DFD, is depicted by means of a structure chart. This structure chart, which resembles an organization chart, show relationships between units or modules, and how modules are combined to achieve systems (organization) and design goals. This coarse program structure is then factored, or decomposed, into a fine structure which forms the basic for implementation. In order to choose among alternatives when dividing systems into
B.Tech (CSE)
- 300 -
KSOU
modules, it useful to evaluate the connection between them. If there are few or no connections between modules, then it is easier to understand one module without reference to others. The notion of module independence can be described in terms of coupling and cohesiveness. These concepts were introduced by Edward Yourdon and Larry Constantine who are concerned with goodness of design.
Coupling is the strength of relationships between modules (the degree to which modules are interconnected with or related to one another). The stronger the coupling between modules in a system, the more difficult it is to implement and maintain the system, because a modification to one module will then necessitate careful study, as well as possible changes and modifications, to one or more other modules. In practice, this means that each module should have simple, clean interface with other modules, and that the minimum number of data elements should be shared between modules.
Cohesion is the measure of the strength among the elements in the same module (the degree to which the components of a module are necessary and sufficient to carry out one, single, well defined function). In practice, this means that the systems designer must ensure that they does not split essential processes into fragmented modules and the systems designer must ensure that they does not gather together unrelated processes (represented as processes on the DFD) into meaningless modules. The best modules are those that are functionally cohesive. The worst modules are those that are coincidentally cohesive. High cohesiveness occurs when all of the module parts contribute directly to the purpose or function which the module is supposed to accomplish.
Structured Design as process The phases of design
As discussed above, there are various techniques and tools being used in the analysis and design phases, however, not all of them are suitable for any systems. Even when a
B.Tech (CSE)
- 301 -
KSOU
modelization technique is employed, there are still different levels of complication of that model in different cases. If too few system development tools are used, the systems quality will be worsen, and vice versa, if more tools are used than they are actually needed, resources are wasted. Thus, analysts and designers have to judge to give the right decision of what techniques and tools should be used and to what extent.
The recommended percentage distribution between analysis, design, and implementation is 50%-60% for the analysis and design phases and 40%-50% for the implementation phase. There are three primary design stages: Initiation: This is the form the design takes when it has first been generated.
It is usually not complete, in that some functions overlooked in the analysis may still be missing, error processing is missing, and details of how outputs are produced will also be missing. Abstraction: Derived directly from the initiation results, this design phase
involves the completion of the design. All functions and necessary detail missing in the abstraction phase are incorporated into the design. This is the phase in which we apply coupling and cohesion, obtaining the best design we can given the constraints of time and talent. Instantiation: Based on the abstract design, this phase involves the revision
of the design to make use of specialized operating system features, the use of hardware features rather than software to provide needed services, and the incorporation of any additional functions or features that have been identified as being needed. During this stage the software engineer maked rational compromises with respect to coupling and cohesion in order to attain some performance goal or to meet some external constraint.
These stages are organized into two phases:
B.Tech (CSE)
- 302 -
KSOU
Model of Structured Design is composed of two distinct but related phases. In chronological order, the first is logical design phase and the second the physical desing phase.
Logical Design Phase: The objective of this phase is the development of a design which is directed by an abstract machine and operating environment. This model contains the highest amount of quality and quality components as we were able to incorporate, with the time and talent available.
Purposes Redesigning the existing to reflect the proposed solution Incorporate new features for the system Final performance specification Detailed logical models
Deliverables
The activities which occur during the Logical design phase are the following: Develop the preliminary design: the goal of this task is to create a conceptual
design which will reflect in the analysis package and contain the amount of quality that we can incorporate into it Define the man-machine and machine-machine boundaries on DFD: Using the
level -0 dataflow diagram developed during the logical modeling phase of analysis, identifies which processes or functions will be allocated to hardware, software and manual procedures. Transform E-R-A Model into Relational Model: Each entity and each relation is
transformed into a logical relationship using the Relational Database Model notation and semantics. The relations are integrated into global relational schema. An E-R-A
B.Tech (CSE)
- 303 -
KSOU
Model is a conceptual representation of real world, enterprise objects. It is composed of entities (with their attributes) and relationships between them. Normalize Relational Model: the logical relational schema is transformed into a
normalized schema to provide for logical data access and update integrity. Prepare Database access Model: For each user view a logical data access
specification is created, which defines the process followed in accessing the required data and the logical relations involved. Verify against Normalized Relational Model: Inability to support required data
access will cause the E-R-A Model and the logical relational Model to be refined appropriately. Transform leveled DFDs into first-cut structure chart Refine structure Chart using coupling, cohesion and adding additional
functions, as necessary. Develop pseudo code: the pseudo code for each module describes what the
module does. The basis for most pseudo code is the structured English that was created during the analysis phase. Revise Event Model: Refinement of this model is necessary in order to put it
into a more acceptable form to accommodate the design and implementation perspectives. Revise Relational Model: Bring this view of the system into compliance with
the other revisions and refinements that have taken place. Update Lifecycle Dictionary: One of the outcomes of transforming the
analysis results into an initial design model is that new data elements have to be incorporated. Since Lifecycle Dictionary is the repository for information, it must be updated to reflect new parts of systems, descriptions of each of the modules. Perform consistency check among Structure Charts, pseudo code, Event
Model, E-R diagrams, Relational Model. Ensure that all parts of the design are accurate and mutually supportive.
B.Tech (CSE)
- 304 -
KSOU
Physical Design Phase: The objective of this phase is the creation of a blueprint of the system. This blueprint is complete and correct and accurately describes every aspect of the system to be developed.
Purposes Convert the logical models into a physical model Physical specification A formal feasibility analysis Deliverables
The activities which occur during the Physical design phase are the following: Develop Detailed Design: It is derived from the logical Design by
incorporating considerations of system size, timing constraint, the existence of hardware or software utilities, language features and other implementation considerations. Review Preliminary Design Package: The purpose of this task is twofold. One is
to identify and correct errors and necessary refinements. The other is to ensure that all that is necessary to accomplish the physicalization of the design is present and of sufficient quality to support this next phase. Develop final (build to) Structure Chart. Update Lifecycle Dictionary to reflect physical characteristics: The lifecycle
Dictionary must include the compromises between the desired ( Detail Design) system and the obtainable ( Physical Design) one. The primary inputs or changes at this stage are: the build to Structure chart process, dataflow and data access specifications; the implementation constrains from the packaging criteria; the changes to the Event Model; and the new DBMS data model and its operational characteristics.
B.Tech (CSE)
- 305 -
KSOU
process. -
Revise pseudo code: update the content of the pseudo code, as necessary, in
order to accommodate the changes made to the system design during the packaging
Perform coupling and cohesion analysis Revise Event Model Reconcile all elements of module design package Map to DBMS Data Model: The logical, normalized schema is translated into
an initial DBMS schema. This schema is then refined to take advantage of the unique capabilities of the DBMS being used. The translation process is specific to the particular DBMS Data Model. Each translation starts with a logical relation and converts it into an appropriate DBMS structure. Optimize DBMS schema access costs: Cost models are to determine optimal
access paths to support the user data view requirements. Any modifications to the DBMS schema are verified against the logical relational schema. Revise implementation estimates: This supports the concepts of iterative
estimation refinement that is used in most engineering fields.
Example: From the above library management case study, we realize that the system analysis stage focuses on the logical aspect of the system. It does not consider at all the implementations of the requirements. By contrast, the system design phase immediately considers the ways to set up the professional requirements by using computer.
The inputs of system design phase are the specific requirements which were built in the system analysis phase, including: Function Hierarchy Diagram Data Flow Diagram
- 306 -
B.Tech (CSE)
KSOU
Entity Relationship Diagram
In the system design phase, we have to: 1. Define which functions have to be done by human, and which functions
have to be carried out by computer, so we have DFD system (half-physical) 2. 3. Design database Design the human/computer interface
Unlike the system analysis phase which needs a few tools and technique, mainly for structure building, in the design phase, the choose of using a tool is very flexible. Some tools are used in detail and closely, some other are used more flexibly, and some may never be used. It depends on the requirement of the problem and the experience of the system designer.
With the library management system, the system design phase concentrates on the following main parts: to determine the computer system, to design modules and to design the database. Elements of Structured Design:
Essential Model Environmental Model Behavioral Model Implementation Model

Figure Elements of structured design
B.Tech (CSE)
- 307 -
KSOU
Essential Model: Model of what the system must do. Does not define how the system will accomplish its purpose. Is a combination of the environmental and behavioral model.
Environmental Model: Defines the scope of the proposed system. Defines the boundary and interaction between the system and the outside world. Composed of: Statement of Purpose, Context Diagram, and Event List.
Behavioral Model: Model of the internal behavior and data entities of the system. Models the functional requirements. Composed of Data Dictionary, Data Flow Diagram, Entity Relationship Diagram, Process Specification, and State Transition Diagram. Implementation Model: Maps the functional requirements to the hardware and software. Minimizes the cost of development and maintenance. Determines which functions should be manual vs. automated. Can be used to discuss the costs-benefits of functionality with the users/stakeholders. Defines the Human-Computer Interface. Defines non-functional requirements.
B.Tech (CSE)
- 308 -
KSOU
Tool: Structure Charts
Time Activity
Statement of Purpose Context Diagram Event List DFD ERD Data Dictionary State Transition Diagram Structure Charts
Environmental Model Behavioral Model Implementation Model

Process Specification
Relationship between system analysis and design: A big advantage of using Structured Analysis as a precursor to Structured Design is that nothing developed during the analysis is wasted. Each of the major deliverables from analysis (i.e., dataflow diagrams, data dictionary, structured English, and entityrelationship diagrams) is used in the Structured Design phase to develop one of its major deliverables (i.e., structure charts, design data dictionary, pseudo code, and database design) A poor analysis job is going to cause problems, whether it was done by the same person doing the design or not. Some of the most common failings during structured analysis are shown in figure together with the symptoms they produce during design
Problem Dataflow diagram not balanced Fuzzy process name
Effect on Design Interface Problems Need to repartitioning
B.Tech (CSE)
- 309 -
KSOU
No dictionary Dictionary not correlated with dataflow diagrams Dataflow diagrams not correlated with dictionary Pseudo code not validated Pseudo code dictionary not correlated with
Duplicates and aliasing Duplicates and aliasing and interface problems Duplicates and aliasing and interface problems Logic errors Data aliases, interface problems
Table Problems effecting design process
B.Tech (CSE)
- 310 -
KSOU
Development phase Type of model Process Structured Analysis DataFlow Diagrams Dictionary Pseudocode Information Entity-Relationship Diagram Dictionary Event Event Model Dictionary Event Model Dictionary Structured Design Structure Chart Dictionary Pseudocode Database Design Dictionary Implemented Database Dictionary Queuing Model Dictionary Implementation Code Dictionary
The stages of system design: The activity of design involves developing a series of models, in much the same way that the systems analyst develops models during the systems analysis phase. The most important models for the designer are the systems implementations model and the program implementation model. The systems implementations models divide into a processor model and a task model
The processor model: At this level, the systems designer decides how the essential model should be allocated to different processors and how those processors should communicate with one to another.
As processes must be assigned to appropriate hardware components, data stores must be similarly allocated. Therefore, the designer must decide whether a store will be implemented as a database on this processor or another. Since most stores are shared by many processes, the designer may also have to decide whether duplicate copies of the store need to be assigned to different processors. An important point for designer: processor to processor communication is generally very much slower than communication between processes within the same processor. Thus, the system designer will generally try to group processes and stores that have a high volume of communication within the same processor.
KSOU
During designing a process, the systems designer should raise the following major issues:
Cost: Depending on the nature of the system, the systems designer must choose the most economical solution for each practical case: a single processor implementation or group of processors. Efficiency: The systems designer is generally concerned with the response time for computer systems. Therefore, the designer must choose processor and data storage devices that are fast enough and powerful enough to meet the performance requirements specified in the user implementation model. Security: The end user may have security requirements that dictate the placement of some processor and sensitive data in protected location. Reliability: The end user will normally specify reliability requirements for a new system; these requirements may be expressed in terms of mean time between failure or mean time to repair, or system availability. Alternatively, the designer may decide to implement redundant copies of processes and/or data on multiple processors, perhaps even with spare processors that can take over in the event of a failure. Political and operational constraints: The hardware configuration may also be influenced by political constraints imposed directly by the end user, by other levels of management in the organization and operating all computer system. Tools and Techniques of design The design of information systems requires that systems analysts understand how information flow in an organization, how it relates decision making, and how it contributes to organizational goals and objectives. That is why systems analysis and systems design is inextricably linked. While data are being collected on the problem environment and the analyst is learning about the information needs of the user, rough ideas about the way to improve the information function are being formulated in the analysts mind. The analyst may begin to sketch these ideas as flow charts or data flow diagrams. However, not until all data are collected and information problems are thoroughly analyzed can preliminary ideas about the design of the new system be refined. The analyst can then focus on design specifies such as input/output subsystems, processing, and data base design. Most analyst continue to use structured techniques to
B.Tech (CSE)
- 312 -
KSOU
help them plan system components and their structure, choosing appropriate tools and techniques to aid them in the design process. The completed design should lead efficiency in satisfying users needs and also facilitate maintenance during the life cycle of the system. Each design tool has good features and bad. Selection of design methodology will depend on the background and experience of analysts (designer), the size of the development time, resources allocated to development, the time allowance for the project, and the type of application under development. When choosing a specific tool for a specific task at hand, the following main questions should be considered: Will it help the team arrive at an understanding of the system under development; Is it easy to learn? Easy to use? Will it serve user-analyst communication? What does it cost? What data structures does it use? What data flow and control features does it have? Is the technique manageable?
There are many ways to approach system design and many tools and techniques that contribute to the design process. In this part we will find a discussion of still other methodologies that are comely used by analysts. Many of these are complex, so what appears here is merely a brief introduction to their features, benefits and limitations. Unfortunately, the scope here limits the number of design methodologies that can be presented. In the system development process, many design methodologies already exist, but one of the challenges of systems design is to select tools and techniques that are appropriate for an application under development from the wide range of available options. The main selection that follow: ISDOS, Pseudo code, Structured design, the Jackson Design methodology, HIPO, Warnier or methodology, SADT, Walkthroughs, Entity Relationship model, Data Structure Diagrams, Semantic Data Model and CASE*Method (Oracle).
Object-Oriented Design (OOD):
B.Tech (CSE)
- 313 -
KSOU
Combination of process- and data-oriented approaches. Object-oriented techniques work well in situations where complicated systems are undergoing continuous maintenance, adaptation, and design. There are two ways to model object-oriented systems Coad and Yourdon methodology The Unified Modeling Language
Six ideas characterize object-oriented programming: An object, which represents a real-world thing or event. An object is an instance or occurrence of a class. There are five general types of objects: Tangible things, Roles, Incidents, Interactions, Specifications details. A class, or group of related objects. Class refers to a template for a group of individual objects with common attributes and common behavior. The difference between an Object and a Class is that the class defines shared attributes and behaviors of objects Messages, sent between objects. Interface means the behavior of a class or component that is noticeable from outside the class or component Encapsulation, only an object makes changes through its own behavior. Encapsulation changes the manner in which data is updated by programs because data can only be changed via the services that encapsulate the data Inheritance, a new class created from another class. The two types of classes are involved in any inheritance relationship are the base class and the derived class. Multiple inheritance means there will be multiple occurrences of the base type of class in the inheritance relationship. Polymorphism only occurs where there is inheritance.
B.Tech (CSE)
- 314 -
KSOU
Polymorphism, meaning that a derived class behavior may be different from the base class. Object oriented design is based on a five-layer model: Class/object layer notes the classes and objects Structure layer captures various structures of classes and objects, such as one-to-many relationships and inheritance Attribute layer details the attributes of classes Service layer notes messages and object behaviors Subject layer divides the design into implementation units or team assignments Criteria to determine whether a new class of objects is justified There is a need to remember the object. There is a need for certain behaviors of the object. An object has multiple attributes. A class has more than one object instantiation. Unless it is a base class. Attributes have a meaningful value for each object in a class. Services behave the same for every object in a class. Objects implement requirements that are derived from the problem setting. Objects do not duplicate attributes and services that could be derived from other objects in the system. There are two basic types of structures that might be imposed on classes and objects: Generalization-Specialization structure (Gen-Spec), which connect classto-class Whole-Part structure which are collections of different objects that compose another whole object
Instance connections are references between objects such as associations or relationships indicated by a single line between objects using the same cardinality notation as Whole-Part structures
KSOU
Major Components of Object-Oriented Design Activities: Object-oriented design activities are grouped into four major components: The problem domain component The human interface component The data management component The task management component Methods Services (or methods or procedures) must be analyzed. Activities are Object state analysis, showing changes of state Service specification: creating, storing, retrieving, connecting, accessing, and deleting objects Message specification, consisting of control and data flow
Structure charts: The structure chart is an important technique that helps the analyst design the program for the new system. There are three components in the structured chart: modules, connections between modules, and communication between modules.
Structure chart elements: Module: Denote a logical piece of program Library: Denote a logical piece of program that is repeated in a structure chart
B.Tech (CSE)
- 316 -
KSOU
Loop: A module is repeated Conditional Line: Subordinate modules are invoked by control modules based on some conditions. Control Couple: Communicates that a message or system flag is being passed from one module to another Data Couple: Communicates that data is being passed from one module to another Off Page: Identifies when the part of the diagram are continued on another page of structure chart. On Page: Identifies when the part of the diagram are continued somewhere else on the same page of the structure
Creating a structure chart from a DFD
Following the hierarchy of the DFDs, simply hang modules below their parent modules..
KSOU
1. Identify Modules and Levels 2. Identify Special Connections 3. Add Couples 4. Revise Structure Chart
Information Engineering: The purpose of the information engineering is to investigate the data and data relationships among different disciplines, and then organize those data to match the corporations goals and objectives. A user-driven system is then developed using a topdown approach. The information engineering methodology relates well to the corporate mission. The analyst is expected to relate all the essential information system components and match those functions to corporate objectives before performing data analysis. The link to the corporations goals and objectives adds a high-level, executive, strategic perspective to the methodology. The methodology has a strong data orientation, leading to clearlydefined and documented data and data relationships. It enforces data normalization, which greatly reduces data redundancy and, hence, increases the accuracy and reliability of the database. Information engineering is not a good candidate for designing real-time systems or systems in which the data have a strong time dimension because the methodology is based on a static data model. The information engineering methodology can be viewed as a special case of the system development life cycle introduced in. Relevant tools are covered in problem analysis paradigms, systems analysis, and component design.
B.Tech (CSE)
- 318 -
KSOU
Joint Application Development (JAD ) IBM coined the term joint application design (JAD) in 1970, but some experts prefer joint application development. The key idea to organize a team consisting of major users, managers, and systems analysts (or information consultants) and to charge that team with quickly determining, in an intensive session, the requirements for a proposed new or replacement information system. Bring together the users, managers, and technical personnel to conduct a series of structured intensive information-gathering workshops Enhance the development of a shared understanding among the system stakeholders JAD Session Usually held at a location other than the typical workplace Avoid distracting environment Detailed agenda is a necessity
JAD Team JAD Facilitator Management Sponsor Information Specialists Scribe End Users
JAD Session Tasks and Objectives Identify all stakeholders and clarify executive goal.
B.Tech (CSE)
- 319 -
KSOU
Scope out general requirements from each of the users' perspectives. Reconcile and then summarize each user's view of the product with the executive goal. Define interaction of the product with users, other products or systems, and the organization. Concur on business justification, time box, and cost box for project. Define ways in which users will interact with or use the new product. Collect samples of desired inputs and outputs from users. Stick to business processes first, then drill down for data needed and known.
Prioritize user interaction scenarios by collective user preference and risk. Validate and review the user interaction scenarios. Organize the interactions scenarios, constraints, assumptions, and other requirements into a rigorous Software Requirements Specification.
JAD Advantages Create a sense of involvement Allow for the simultaneous gathering and consolidating of information Resolve discrepancies at early stage
JAD disadvantages Extreme commitment of a large number of employees Might still exclude some important personnel Lack of diplomacy and communication skills among employees
The cost and time associated with data collection, analysis, and requirements definition can be significantly reduced by using the JAD technique. The input from numerous
B.Tech (CSE)
- 320 -
KSOU
people provides different perspectives on the desired system and often generates creative ideas. Because all interested parties are represented on the JAD team, conflicts and discrepancies can be identified and resolved during the problem definition stage. Because they are involved in system planning, the participants feel a sense of system ownership. JAD is particularly suited to projects that face tight time and scheduling constraints, and it is an excellent choice for developing a system from scratch. Sometimes, so many ideas are generated that additional sessions and meetings are needed to resolve the conflicts. Strong or influential users can easily dominate a session, leading to a skewed sense of the users needs. JAD is not a good technique for systems with relatively few inputs and outputs or for highly computational, process-oriented systems. JAD is used to determine the system requirements during the problem definition (or information gathering) phase of the system development life cycle. Often, a preliminary problem definition proceeds the JAD session. JAD can also be used to perform feasibility analysis, cost/benefit analysis, and risk analysis. Often, such design specifications as data flow diagrams, entity relationship diagrams, and system flow diagrams are generated during the JAD session. Joint application design (JAD), also know as joint application development, is a technique for quickly determining system requirements by obtaining input from a representative cross section of interested parties. An ad hoc team composed of major users, managers, and systems analysts (or information consultants) is assembled. The team then meets in an intensive session to gather data, brainstorm, discuss ideas, reconcile differences, identify and prioritize requirements, and generate desirable alternative solutions. The members of a JAD team consist of end users from the relevant business functional areas, managers from those same functional areas, systems analysts or information consultants, and appropriate systems specialists. The moderator or session leader is usually the senior systems analyst or information consultant. A scribe takes notes, records all discussions, and organizes and compiles the necessary documents.
B.Tech (CSE)
- 321 -
KSOU
Develop the JAD workbook The JAD workbook consists of a management definition guide, information relevant to the project, any special criteria or constraints, any assumptions, an overview of existing technology and standards, a statement of the systems scope and objectives, and information about the existing system and/or relevant new technology. The purpose of the workbook is to help the team members understand the proposed project. The design of the workbook should facilitate note taking. JAD Participants: Session leader User Manager Project sponsor Analyst Scribe IS staff
JAD Participant
Description of Role
B.Tech (CSE)
- 322 -
KSOU
Session Leader
organizes and runs the actual JAD session remains neutral on all issues and does not contribute ideas or opinions sets the agenda for the meeting concentrates on keeping to agenda, resolving conflicts, and generating dialogue from participants represents end users perspective with regard to proposed system represents managements perspective with regard to proposed system represents all parties responsible for funding and supporting the development effort analyst participation is limited to observation and listening to better understand the needs of the users and managers responsible for taking notes and recording important information and events relevant to the JAD proceedings responsible for providing clarification on technical questions and issues contribute ideas on technical feasibility of and limitations of proposed system components
User Manager Project Sponsor Analyst Scribe IS Staff
Table 6.1 Description of Role of each JAD Participant
Consider RAD when The software application will run standalone without other system interactions.
Avoid RAD when Application must interact with existing system applications. Optimal performance is mission critical.
B.Tech (CSE)
- 323 -
KSOU
Application performance is not mission critical.
Application development cannot take advantage of high-end IS tools (i.e., 4th generation programming languages).
Application distribution will be narrow (in-house or controlled vertical market).
Application distribution will be wide (horizontal or mass market). Project involves building operating systems (reliability target too high for RAD), or computer games (performance target too high for RAD).
Project scope is significantly constrained.
Application reliability is not mission critical.
Technical feasibility is low due to use of "bleeding" edge technology.
System can be subdivided into multiple independent modules.
The application is mission- or lifecritical.
The required technology is considered The system cannot be modularized (defeats mature (more than one year). parallel development approach).
Table 6.2 Tells when to use and when not to use RAD.
Locate the JAD facilities As a minimum, a conference room large enough to accommodate all the team members and equipped with whiteboards or chalkboards, an overhead projector, and a slide projector must be available. With the emergence of the electronic meeting systems
KSOU
(EMS), group decision support systems (GDSS), and computer aided software engineering (CASE) tools, additional requirements might include computers for conducting an electronic meeting, teleconferencing facilities, and a master station equipped with CASE software. Conduct the JAD session A JAD session is an intensive (typically) two- or three-day meeting of the complete JAD team. Team members are expected to give the JAD session their complete attention, scheduling no other conflicting activities. Preparation Before the JAD session begins, the responsible systems analysts or information consultants must: Define the system scope. Identify the problems, limitations, and constraints. Estimate the resource needs (time, budget, personnel) for developing the system. Identify preliminary costs, benefits, risks, and impacts of the project. Identify the nature and major attributes of the project, the project dependencies, and the project interrelationships. Identify appropriate sub-projects. (The project is sometimes, decomposed into several sub-projects owing to the timing and/or budgetary constraints.) Perform the background analysis necessary to define such key parameters as the number of users, the size of the database, the required throughput, and the minimum acceptable response times. Plan the JAD session. The session
B.Tech (CSE)
- 325 -
KSOU
A JAD session begins with an overview of the material collected during the preparation stage. Once the participants understand the problem, the process of identifying the problems dimensions, possible causes, requirements, and alternative solutions begins. During a JAD session, it is the moderator s responsibility to effectively manage session time, to ensure that the team stays focused on the agenda items, to encourage all team members to participate, and to resolve any conflicts generated during the session. Because the team is composed largely of non-technical personnel, it is important that the systems analysts or information consultants minimize the use of technical terms. Brainstorming The process of soliciting ideas often involves brainstorming. A specific question is raised; for example, the moderator might ask the JAD team to suggest possible causes of a specific problem or sub-problem. The participants are then invited to suggest ideas, and as suggestions are made they are posted for all to see. Ideally, at some point in the brainstorming session, a synergy begins to emerge, with one participants contribution eliciting new and creative suggestions from other participants. The time allocated to a brainstorming session is limited to (perhaps) half an hour, and the time limit is announced to all participants before the session begins. The focus is on soliciting and listing ideas, not on attacking, defending, or investigating those ideas. Often, targets are set; for example, a brainstorming group might be challenged to list 25 possible (direct or contributing) causes of the problem under study. Sometimes, the JAD team is divided into several brainstorming sub-teams, and a friendly competition is launched to see which sub-team can list the most ideas. Following a brainstorming session, the JAD team divides into sub-groups to investigate the ideas on the various lists. Vague or unclear ideas are refined and rephrased. Similar or redundant ideas are categorized and consolidated, and the resulting meta-ideas are reconciled. Meanwhile, other sub-groups might conduct additional brainstorming and/or discussion sessions to consider other sub-problems or identify and resolve conflicts within and between the meta-ideas until, eventually, a consensus is reached. The
B.Tech (CSE)
- 326 -
KSOU
consensus ideas are then tabulated and distributed to the JAD team members for feedback. The session ends with a presentation of the final results. Finalize the JAD report After the JAD session is concluded the responsible systems analysts or information consultants update the necessary documents and prepare a final report that summarizes all discussions, facts, findings, and conclusions. They then construct a plan for action and a schedule for developing the system. If follow-up sessions are required, they collect the required additional information. There is no standard format for a JAD report.
Rapid Application Development (RAD): Rapid application development (RAD) is a system development methodology that employs joint application design (to obtain user input), prototyping, CASE technology, application generators, and similar tools to expedite the design process. Application Development with RAD Approach Use of small, well-trained development teams Construction and review of iterative, evolutionary prototypes Reliance on integrated development tools that support modeling, prototyping, and component re-usability (CASE) Construction and maintenance of a central repository Heavy reliance on interactive requirements and design workshops (JAD) Adherence to rigid limits on development time frames
RAD activities Process Model Data Model
B.Tech (CSE)
- 327 -
KSOU
Parallel Development
Requirements Planning Model Primary Activity prototype requirements Define Data Conversion
User Construction and Complete application development Implement conversion plan Cutover Install application
Design and Model prototype design
data Plan and design Develop data data conversion conversion modules Design Conduct user testing Produce training materials
requirements
Testing Define training End-user Training requirements
application test plan Design training plan
Conduct enduser training
Table 6.3 Shows various activities involved in RAD
Rely on the use of CASE tools and prototyping approach A series of techniques to compress the analysis, design, build, and test phases into a series of short, iterative development cycles Rapid application development promotes fast, efficient, accurate program and/or system development and delivery. Compared to other methodologies, RAD generally improves
B.Tech (CSE)
- 328 -
KSOU
user/designer communication, user cooperation, and user commitment, and promotes better documentation. Because rapid application development adopts prototyping and joint application design, RAD inherits their strengths and their weaknesses. More specifically, RAD is not suitable for mathematical or computationally oriented applications. Because rapid application development stresses speed, quality indicators such as consistency, standardization, reusability, and reliability are easily overlooked. Rapid application development is an alternative to the traditional system development life cycle. The RAD methodology incorporates joint application design and prototyping. CASE technology is often used to speed the development process. Rapid application development (RAD) is a system development methodology that employs joint application design (to obtain user input), prototyping, CASE technology, application generators, and similar tools to expedite the design process. Initially suggested by James Martin, this methodology gained support during the 1980s because of the wide availability of such powerful computer software as fourth-generation languages, application generators, and CASE tools, and the need to develop information systems more quickly. The primary objectives include high quality, fast development, and low cost. Components Rapid application development focuses on four major components: tools, people, methodology, and management. Current, powerful computing technology is essential to support such tools as application generators, screen/form generators, report generators, fourth-generation languages, relational or object-oriented database tools, and CASE tools. People include users and the development team. The methodology stresses prototyping and joint application design. A strong management commitment is essential. Before implementing rapid application development, the organization should establish appropriate project management and formal user sign-off procedures. Additionally,
B.Tech (CSE)
- 329 -
KSOU
standards should be established for the organizations data resources, applications, systems, and hardware platforms. Phases Four phases to implement rapid application development: requirements planning, user design, construction, and cutover. Requirements planningis much like traditional problem definition and systems analysis. RAD relies heavily on joint application design (JAD) sessions to determine the new system requirements. During the user design phase, the JAD team examines the requirements and transforms them into logical descriptions. CASE tools are used extensively during this phase. The system design can be planned as a series of iterative steps or allowed to evolve. During the construction phase, a prototype is built using the software tools described earlier. The JAD team then exercises the prototype and provides feedback that is used to refine the prototype. The feedback and modification cycle continues until a final, acceptable version of the system emerges. In some cases, the initial prototype consists of screens, forms, reports, and other elements of the user interface, and the underlying logic is added to the prototype only after the user interface is stabilized. The cutover phase is similar to the traditional implementation phase. Key activities include training the users, converting or installing the system, and completing the necessary documentation. Variations There are several variations and/or extensions to the rapid application development methodology. An evolutionary approach in which progressive designs go through
B.Tech (CSE)
- 330 -
KSOU
multiple, minimum-length cycles in which successive versions of the system under construction are utilized by the end user. is also called middle-out, bread-boarding, and the iterative design approach. The essence of the evolutionary approach is to have the user (or the manager) and the builder agrees on a small but significant sub-problem, and then to design and develop an initial system to support that immediate need. After a short period of use (a few weeks for instance), the system is evaluated, modified, and incrementally expanded. This cycle is repeated three to six times over the course of a few months until a relatively stable system that supports a cluster of related tasks evolves. The word relatively is important because, although the frequency and extent of system change will decrease or even cease, the system will never be truly stable. In effect, constant change is a conscious strategy. Note that the evolutionary approach requires an unusual level of user (or management) participation. The user is actually the designer, and the system analyst merely implements required changes or modifications. Note also that this approach differs from traditional prototyping because the initial system is real, live, and usable, not just a pilot test. The quick-hit approach is designed to take advantage of recognized high payoff application tasks for which a system can be built very quickly. The basic idea is to gain user cooperation and confidence by rapidly developing a highly usable system. For example, imagine that a company is losing market share to a rival. Imagine further that a preliminary study suggests that the primary factors contributing to the problem are product quality, after-sale service, and brand recognition. Perhaps a simulation model that focuses on those factors can be designed and constructed quickly, yielding information that can help management correct the problem. Note that the system is designed quickly to hit the main points; hence the name quick hit approach. According to Sprague, the quick-hit approach is low risk and has a high potential short run payoff.
Module 6 Unit 18 Quality Assurance
B.Tech (CSE)
- 331 -
KSOU
Quality assurance, or QA for short, refers to planned and systematic production processes that provide confidence in a product's suitability for its intended purpose. It is a set of activities intended to ensure that products (goods and/or services) satisfy customer requirements in a systematic, reliable fashion. Two key principles characterize QA: "fit for purpose" (the product should be suitable for the intended purpose) and "right first time" (mistakes should be eliminated). QA includes regulation of the quality of raw materials, assemblies, products and components; services related to production; and management, production and inspection processes. It is important to realize also that quality is determined by the intended users, clients or customers, not by society in general: it is not the same as 'expensive' or 'high quality'. Even goods with low prices can be considered quality items if they meet a market need. Total Quality Management (TQM): Total Quality Management (TQM) is a management approach to long-term success through customer satisfaction. In a TQM effort, all members of an organization participate in improving processes, products, services and the culture in which they work. A core concept in implementing TQM is Demings 14 points, a set of management practices to help companies increase their quality and productivity: 1. Create constancy of purpose for improving products and services. 2. Adopt the new philosophy. 3. Cease dependence on inspection to achieve quality. 4. End the practice of awarding business on price alone; instead, minimize total cost by working with a single supplier. 5. Improve constantly and forever every process for planning, production and service. 6. Institute training on the job. 7. Adopt and institute leadership. 8. Drive out fear. 9. Break down barriers between staff areas. 10. Eliminate slogans, exhortations and targets for the workforce.
B.Tech (CSE)
- 332 -
KSOU
11. Eliminate numerical quotas for the workforce and numerical goals for management. 12. Remove barriers that rob people of pride of workmanship, and eliminate the annual rating or merit system. 13. Institute a vigorous program of education and self-improvement for everyone. 14. Put everybody in the company to work accomplishing the transformation. Total Quality Management (TQM) Total Quality Management (TQM) is a business management strategy aimed at embedding awareness of quality in all organizational processes. TQM has been widely used in manufacturing, education, hospitals, call centers, government, and service industries, as well as NASA space and science programs. Definition Total Quality Management is the organization-wide management of quality. Management consists of planning, organizing, directing, control, and assurance. Total quality is called total because it consists of two qualities: quality of return to satisfy the needs of the shareholders, or quality of products. TQM is a management approach for an organization, centered on quality, based on the participation of all its members and aiming at long-term success through customer satisfaction, and benefits to all members of the organization and to society. In the 1980s to the 1990s, a new phase of quality control and management began. This became known as Total Quality Management (TQM). Having observed Japans success of employing quality issues, western companies started to introduce their own quality initiatives. TQM, developed as a catchall phrase for the broad spectrum of qualityfocused strategies, programs and techniques during this period, became the center of focus for the western quality movement. A typical definition of TQM includes phrases such as: customer focus, the involvement of all employees, continuous improvement and the integration of quality management into the total organization. Although the definitions were all similar, there was confusion. It
B.Tech (CSE)
- 333 -
KSOU
was not clear what sort of practices, policies, and activities needed to be implemented to fit the TQM definition. The term Total Quality Management has lost favor in the United States in recent years: Quality management is commonly substituted. Total Quality Management, however, is still used extensively in Europe. Basic Principles of Total Quality Management (TQM) The basic principles for the Total Quality Management (TQM) philosophy of doing business are to satisfy the customer, satisfy the supplier, and continuously improve the business processes. Questions we need to include:

How do you satisfy the customer? Why should you satisfy the supplier? What is continuous improvement?
The first and major TQM principle is to satisfy the customer - the person who pays for the product or service. Customers want to get their money's worth from a product or service they purchase. Deep analysis of QA practices and premises used about them is the most necessary inspection control of all in cases, where, despite statistical quality control techniques or quality improvements implemented, sales decrease. The major problem which leads to a decrease in sales was that the specifications did not include the most important factor, What the specifications have to state in order to satisfy the customer requirements?. The major characteristics, ignored during the search to improve manufacture and overall business performance were:

Reliability Maintainability Safety Strength
Quality Control
B.Tech (CSE)
- 334 -
KSOU
Quality Control was introduced to detect and fix problems along the production line to prevent the production of faulty products. Statistical theory played an important role in this area. In the 1920s, Dr W. Shewhart developed the application of statistical methods to the management of quality. He made the first modern control chart and demonstrated that variation in the production process leads to variation in product. Therefore, eliminating variation in the process leads to a good standard of end products. Statistical Quality Control:

focuses on product and the detection and control of quality problems; involves testing samples and statistically infers compliance of all products; is carried out at stages through the production process; and relies on trained production personnel and quality control professionals.
Shewarts work was later developed by Deming, Dodge and Roming. However, manufacturing companies did not fully utilize these techniques until the late 1940s. Quality methods There are also many quality methods, such as just-in-time production, variability reduction, and poke-yoke that can improve processes and reduce waste. The principles of Total Quality Management are to seek to satisfy the external customer with quality goods and services, as well as your company internal customers; to satisfy your external and internal suppliers; and to continuously improve processes by working smarter and using special quality methods. Quality Management Benchmarking is the use of standard measurements in a service or industry for comparison to other organizations in order to gain perspective on organizational performance. Continuous Improvement, in regard to organizational quality and performance, focuses on improving customer satisfaction through continuous and incremental improvements to processes, including by removing unnecessary activities and variations. Failure Mode and Effects Analysis is an approach that helps identify and prioritize potential equipment and process failures. ISO9000 is an internationally recognized
B.Tech (CSE)
- 335 -
KSOU
standard of quality, and includes guidelines to accomplish the ISO9000 quality standard. Organizations can be optionally audited to earn ISO9000 certification. Quality management can be considered to have three main components: quality control, quality assurance and quality improvement. Quality management is focused not only on product quality, but also the means to achieve it. Quality management therefore uses quality assurance and control of processes as well as products to achieve more consistent quality.
B.Tech (CSE)
- 336 -
KSOU
Quality assurance versus quality control Quality control emphasizes testing of products to uncover defects, and reporting to management who make the decision to allow or deny the release. Whereas quality assurance attempts to improve and stabilize production, and associated processes, to avoid, or at least minimize, issues that led to the defects in the first place To prevent mistakes from arising, several QA methodologies are used. However, QA does not necessarily eliminate the need for QC: some product parameters are so critical that testing is still necessary. QC activities are treated as an integral part of the overall QA processes Quality Assurance in software development The following are examples of QA models relating to the software development process. Models and standards ISO 17025 is an international standard that specifies the general requirements for the competence to carry out tests and or calibrations. There are 15 management requirements and 10 technical requirements. These requirements outline what a laboratory must do to become accredited. Management system refers to the organization's structure for managing its processes or activities that transform inputs of resources into a product or service which meets the organization's objectives, such as satisfying the customer's quality requirements, complying with regulations, or meeting environmental objectives. The CMMI (Capability Maturity Model Integration) model is widely used to implement Quality Assurance (PPQA) in an organization. The CMMI maturity levels can be divided in to 5 steps, which a company can achieve by performing specific activities within the organization. Quality terms
Quality Improvement can be distinguished from Quality Control in that Quality Improvement is the purposeful change of a process to improve the reliability of achieving an outcome. Quality Control is the ongoing effort to maintain the integrity of a process to maintain the reliability of achieving an outcome.
B.Tech (CSE)
- 337 -
KSOU
Quality Assurance is the planned or systematic actions necessary to provide enough confidence that a product or service will satisfy the given requirements for quality.
Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or CMMI. SQA encompasses the entire software development process, which includes processes such as software design, coding, source code control, code reviews, change management, configuration management, and release management. The American Society for Quality offers a Certified Software Quality Engineer (CSQE) certification with exams held a minimum of twice a year.
Testing
Testing is the process of determining whether or not the system/ software fulfills the endures requirements. In other words it is the process of verifying that the desired goal as stated in the problem definition have been achieved through the system / software. Several factors contribute to the importance of making testing a high priority of any software development effort. These include:

Reducing the cost of developing the program. Ensuring that your application behaves exactly as you explain to the user. Reducing the total cost of ownership. Developing customer loyalty and word-of-mouth market share.
There are three types of testing done w.r.t to software namely Unit / module testing Integration / system testing Acceptance testing
Unit testing:
B.Tech (CSE)
- 338 -
KSOU
Unit testing deals with testing a unit as a whole. It is also referred to as function or module testing because it would test the interaction of many functions but confine the test within one unit. The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use. For example, if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places:

Is the error due to a defect in unit 1? Is the error due to a defect in unit 2? Is the error due to defects in both units? Is the error due to a defect in the interface between the units? Is the error due to a defect in the test?
Integration Testing Integration testing is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before acceptance testing. Thus, Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. Here a component refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Integration testing can be done in a variety of ways but the following are three common strategies:
The top-down approach to integration testing requires the highest-level modules be test and integrated first.
B.Tech (CSE)
- 339 -
KSOU
The bottom-up approach requires the lowest-level units be tested and integrated first. The third approach, sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths.
Acceptance Testing: Acceptance testing is the process of testing system (e.g. software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery. A system is mainly developed for an enduser normally a customer of the organization. A system is said to be accepted if and only if the user of the system is satisfied. In this perspective acceptance testing is widely used the to prove that system performs as per the requirements. In acceptance testing the customers provides the input data to validate the system operation. It is also known as functional testing, black-box testing, release acceptance, QA testing, application testing, confidence testing, final testing, validation testing, or factory acceptance testing
B.Tech (CSE)
- 340 -

Business Plan

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Business Plan

Cargado por

Copyright:

Formatos disponibles

System Analysis & Design

E On tRe r C o ler dr ke r in t o D a ily O rd ers O R C le r k

SYSTEM ANALYSIS AND DESIGN

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

Data Alphanumeric data Image data Audio data Video data

System Analysis & Design

Table 1.2 Converting data to information

System Analysis & Design

System Analysis & Design

Completeness Information must be complete, else it leads to incorrect decision-making.

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Concept Implications

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design

Fig. 2.1 System Elements

System Analysis & Design

UNIT 3 INFORMATION SYSTEMS

What is an information System?

Why information systems?

System Analysis & Design

Information system Resources

System Analysis & Design

System Analysis & Design

System Analysis & Design

Types of Information System

Operation support System

Management support System

Process Transaction Control Processing System System

Enterprise Collaboration System

Management Information System

Decision Support System

Executive Information System

System Analysis & Design

Fig 3.1 Classification of Information System

System Analysis & Design

Management support systems:

System Analysis & Design

UNIT 4 SYSTEM DEVELOPMENT LIFE CYCLE

System Analysis & Design

System Analysis & Design

Why do we use methodologies?

System Analysis & Design

POST IMPLEMENTATION REVIEW for effectiveness and efficiency of new system.

System Analysis & Design

System Analysis & Design

Fig. 29.1 Different phases of System development Life Cycle

System Analysis & Design

System Analysis & Design

System Analysis & Design

System Analysis & Design