Business Plan

System Analysis & Design KSOU

SYSTEM ANALYSIS AND DESIGN

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.

- 1 -


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.

- 2 -


Module 6

Unit 16 – System Design: System design, Logical and physical design, System design elements, Structured design, System design approaches: Modern structured design- Structure 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

DataData 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.

- 3 -


Data Represented by

Alphanumeric data Numbers, letters, and other characters

Image data Graphic images or pictures

Audio data Sound, noise, tones

Video data 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 doesn’t

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.

Converting data into information

- 4 -


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.

Fig 1.1 Process of converting data to information

The following table illustrates how the huge amount of data that manager may receive could be processed to create useful information.

DataPossible methods of converting data into

information

Financial performance Present complex data as a chart or graph

Sales figures Plot charts and identify trends

Market and competition data Find average or typical values

Production outputMonitor changes over time and forecast future values

Costs of resources or other inputsCompare 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

Collect data on the indicators that really do affect performance

- 5 -

Data InformationTransformation


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

- 6 -


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 user’s needs

Relevance

- 7 -


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.

- 8 -


Accessibility

Up-to-date information should be accessible at any time to authorized or relevant users

only.

KnowledgeKnowledge 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.

- 9 -


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.

Fig 1.2 From data to information to 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.

- 10 -

Data KnowledgeInformation applied for

a purpose

build and

process


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 systēma 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 unit’s 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

We can observe three implications from the concept of system. They are:

A system must be designed to achieve some set objectives. - 11 -


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.

InteractionA 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

the second subsystems is said to be interdependent on first. This interdependence may

continue like a chain with in a system.

- 12 -


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.

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.

- 13 -


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 systemsAutomated 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

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,

- 14 -


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

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 user’s demand is dynamic physical system.

- 15 -


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. 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.

- 16 -


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

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.

- 17 -


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.

- 18 -

Environment

Other Systems

System Boundary

ProcessingInput Output

Fig. 2.1 System Elements


UNIT 3INFORMATION 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

- 19 -


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 ResourcesInformation systems resources include,

1. People resources

2. Hardware resources

3. Software resources

4. Data resources

5. Network resources

People resources:

- 20 -


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

system’s 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

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 - 21 -


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

employee’s hours worked, gross pay, current deduction, and net pay.

- 22 -


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.

- 23 -

Information System

Operation support System Management

support System

Transaction Processing

System

ProcessControlSystem

EnterpriseCollaboration

System

ManagementInformation

System

DecisionSupportSystem

ExecutiveInformation

System


Fig 3.1 Classification of Information System

- 24 -


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

produce summary reports as output. They are normally used by middle managers. Some

- 25 -


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 high-

level 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.

What is system development?

- 26 -


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

Beginning of a System Development:- 27 -


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?

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.

- 28 -


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 user’s 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

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

- 29 -


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

Fig. 29.1 Different phases of System development Life Cycle

- 30 -


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 user’s 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 user’s 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

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

- 31 -


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:

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:

- 32 -


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 user’s

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).

• 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:

- 33 -


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 & Company’s 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.

Benefits:

Tangible Benefits:

Increase in sales / Contribution / Profits.

Decrease in investment, operating and processing cost.

Improved information availability, analysis, Management Decision

skill.

Intangible Benefits:- 34 -


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

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

- 35 -


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 user’s

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

Work volume including peak period work volume

- 36 -


-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.

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 - 37 -


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.

- 38 -


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. 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:

- 39 -


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).

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).

- 40 -


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.)

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.

- 41 -


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, Nassi-

Schneiderman 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:

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.

- 42 -


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:

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

- 43 -


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:

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

- 44 -


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

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.

- 45 -


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.

- 46 -


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.

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.

- 47 -


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.

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:

- 48 -


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.

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

user’s 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.

- 49 -


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 user’s 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 organization’s 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.

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).

- 50 -


• 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.

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 - 51 -


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. Form a project team & appoint a project leader.

2. Prepare system flowcharts.

3. Enumerate potential candidate system.

4. Describe & identify characteristics of candidate systems.

5. Determine & evaluate performance & cost effectiveness of each candidate

system.

6. Weigh system performance & cost data.

7. Select the best candidate system.

8. Prepare & report final project directive to management.

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:

- 52 -


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,

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.

- 53 -


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.

The procedure for weighting candidate system is as follows:-

1. Assign a weighting factor to each evaluation criterion based on the criterion’s

effect on the success of the system.

2. Assign a quantitative rating to each criterion’s 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.

- 54 -


Prepare & report final project directive to management:

The report is a formal document for management use, brief enough & non-

technical 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.

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, system’s

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.

- 55 -


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:

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.

- 56 -


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.

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.

- 57 -


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.

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

Technical

Determines the relationship between the present

technology resources of the organization and the

expected technology needs of the proposed

project.

- 58 -


Economic Assesses the cost/benefit relationship of the

proposed project and its net value contribution to

the organization.

Human Factors

Determines the relationship between the 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.

Legal and Political Identifies any potential legal ramifications

resulting from the construction and

implementation of the new system including

copyright or patent infringements, violation of

existing antitrust laws, foreign trade restrictions,

or any existing contractual obligations of the

organization.

Table 5.1. Categories of Feasibility studyUNIT 6

SYSTEM ANALYST

Objectives:

Explain the need of System analyst

Discuss the various roles played by system analyst while developing a

project.

- 59 -


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

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. - 60 -


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).

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 - 61 -


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.

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 - 62 -


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

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:- 63 -


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:

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:-- 64 -


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

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 analyst’s 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 - 65 -


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.

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.

- 66 -


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 ability to operate within business organizations through social

communication and interactions. Interpersonal skills are how people relate to one

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

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.

- 67 -


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:

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.

- 68 -


Analyst Role Relationship to Organization

Programmer/Analyst Employee of the organization

Systems Analyst Employee of the organization

Independent Analyst Contractor to the organization

Outsource Provider Employee of outsourcing contractor

Systems Consultant Contractor to the organization

Software developer Manufacturer or supplier of software

Table 6.1. Typical Analyst-Organization Relationships

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.

- 69 -


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.

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. - 70 -


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

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?

- 71 -


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 tester’s 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.

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- 72 -


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:

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- 73 -


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:

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- 74 -


Complex random

Convenience

Convenience samples are unrestricted. They are non-probability samples. It is easy to

arrange and most unreliable.

Purposive

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 non-

response 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

- 75 -


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

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 forms-

Systematic 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 - 76 -


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.

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- 77 -


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

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.

- 78 -


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.

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

doesn’t 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

- 79 -


• 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

– 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;

don’t interrupt, take copious notes, and review them, focus on important activities, don’t

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:

- 80 -


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:

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

- 81 -


• 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

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 analyst’s most important sources of information about the

present system and the user’s requirements. The purpose of this brief introduction is to

provide some suggestions for planning and conducting an interview. Interviews reveal - 82 -


information about - Interviewee opinions, Interviewee feelings, About the current state of

the system, Organizational and personal goals, Informal procedures.

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

interviewer’s skill. Not all subjects are comfortable being interviewed, and many people

react negatively or defensively to an interviewer’s 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 analyst’s most important sources of information about the present system and the

user’s requirements. The purpose of this brief introduction is to provide some suggestions

for planning and conducting an interview.- 83 -


Planning the Interview

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 user’s 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.

• Don’t include your opinion as part of the question.

• Avoid long or complex questions.

• Avoid threatening questions.

• Don’t use “you” when you mean a group of people

- 84 -


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

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 subject’s 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- 85 -


• interview guide

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 subject’s 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?

- 86 -


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.

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 you’re 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 beginner’s 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 - 87 -


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

off topic, but do allow a certain amount of spontaneity. You might learn something.

Avoid technical jargon; take the time to learn the subject’s application specific language.

An interview is not a trial. Ask probing questions, but do not conduct a cross-

examination. Finally, avoid attacking the subject’s 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 speaker’s 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 subject’s 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

- 88 -


As soon as possible after the interview, transcribe your notes. Ideally, they should identify

key points; use your memory to fill in the details. (Don’t 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

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- 89 -


– Closed-ended questions restrict the response

– Range-of-response questions ask the person to evaluate something

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.

- 90 -


– Note the date, time, location, and purpose

– Review the main points discussed

Step 7: Evaluate the Interview

– 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- 91 -


Interviewer control

Precision

Breadth and depth

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- 92 -


Revealing avenues of further questioning that may have gone untapped

More interesting for the interviewee

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

- 93 -


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 double-

barreled 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:

- 94 -


1. Pyramid structure – starts with closed questions and working toward open-

ended 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

Disadvantages of Audio Recording the Interview

- 95 -


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 Do’s and Don’ts

Do

• Dress appropriately

• Be courteous- 96 -


• 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

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)

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 fact-

finding 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?

What is being done?

Where are operations being performed?

When is a procedure performed?

How is a procedure performed?

Another important question Why? - 97 -


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

Unit 8

Information Gathering Techniques - II

- 98 -


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.

The steps required to design and administer a questionnaire include:

Defining the Objectives of the survey

Determining the Sampling Group

- 99 -


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.

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 - 100 -


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.

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.

- 101 -


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 respondent’s 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

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.

- 102 -


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.

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

- 103 -


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

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 - 104 -


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.

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 - 105 -


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.

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 - 106 -


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

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

- 107 -


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?

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.

- 108 -


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.

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 - 109 -


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.

Wording of questions

The language and phrasing used in constructing questions is also an important

consideration.

Seven basic principles of question construction:- 110 -


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.

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.

- 111 -


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

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 - 112 -


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

Electronically Submitting Questionnaires

Administering a questionnaire electronically has many benefits

Reduced costs

Collecting and storing the results electronically

Free-format questionnaire

- 113 -


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:

– Multiple choice (Y/N or A/B/C/..)

– Rating (5-point from strongly agree to strongly disagree)

– Ranking (importance, or % or time)

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

Disadvantages

• 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- 114 -


• Multiple-choice questions

• Rating questions

• Ranking questions

Rank the following transactions according to the amount of time you spend processing

them.

___%new customer orders

___ % order cancellations

___ % order modifications

___ % payments

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

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. - 115 -


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.

- 116 -


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

analyst’s (or information consultant’s) objective is to gather information about the user’s

requirements from the bottom up by allowing the user to interact with the prototype. In

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 - 117 -


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.

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 system’s programs are created - 118 -


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:

• 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- 119 -


• 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

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.

- 120 -


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 user’s 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.

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 system’s 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.- 121 -

Identify user requirementsAnalyze prototype

input, processing, outputImplement prototype Final conversion Post Implementation

Revise through iterative processMaintenance


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 user’s 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.

Figure 9.1 System development life cycle with Prototyping

- 122 -


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:

• 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.

- 123 -


• 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

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

- 124 -


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

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.- 125 -


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, behind-

the-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

User suggestions

Innovations

Revision plans

The User’s Role

The user’s 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.

- 126 -


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 user’s computer

Prototyping vs. conventional approaches

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 programmer’s 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. - 127 -


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 - 1Data 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

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."

- 128 -


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

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.

- 129 -


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

Process

3.1

Data Flow

Data Store

Table 10.1: DFD Symbols

External EntityExternal 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.

- 130 -


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.

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

- 131 -


external entity to external entity, external entity to store, store to external entity and store

to store

- 132 -


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 store’s

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.

- 133 -


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.

- 134 -


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.

- 135 -


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.

- 136 -


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.

- 137 -


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.

- 138 -


The process of dividing or portioning a single data flow diagram into number of lower-

level 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.

- 139 -


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.


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.

- 140 -


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 -1Precision Tools sells a line of high-quality woodworking tools. When customers place

orders on the company’s 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 Produce Reports

- 141 -


Data Stores D1 Pending Orders D2 Accounts Receivable

- 142 -


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

- 143 -


- 144 -

1.0

CheckStatus

2.0

IssueStatus

Messages

3.0

GenerateShipping

Order

ACCOUNTING

CUSTOMER WAREHOUSE

4.0

Manage Accounts

Receivable5.0

ProduceReports

Order In-Stock Request

Status Data

Status Message

PendingOrdersD1

Order Data

Order Data

Shipping Order

Shipping Confirmation

Invoice

Payment

Accounts ReceivableD2

Accounting Data Accounts Receivable Data

Order Data

Inventory Reports

Fig. 10.2 Level 0 DFD for Order System

GetListof

Numbers1

SortNumbers

intoAscending Order2

Unordered List of Numbers1

UserUser

Unordered List ofInteger Numbers

Ordered List of Numbers

PrintListof

Numbers3

2

PrintedOrdered List of

Numbers


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.

- 145 -

User UserUnordered List of Numbers

PrintedOrdered List of Numbers

Number System

Fig 10.3: Context DFD for Number System

Fig 10.4: Level 1 DFD for Number System

Customer DVD Store

DVD Rental System0Hire

Invoice

Check Available

Payment

Issue Invoice

DVD Store

Available

Reply Available

Video / audio Store

Send/Receive request

Customer

Hire

Invoice

Payment Details

Payment

2.0 Cash

Credit card


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 level 1 data flow diagram for this sytem.

- 146 -

Fig 10.5: Context DFD for DVD rental system

Check/Reply for availability1.0

Order

OrderReject Notice

PickingList

CompletedOrder

Payment Invoice


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.

- 147 -

Fig 10.6: Level 1 DFD for DVD rental system

0

Order System

SALESREP

CUSTOMER WAREHOUSE

BANK

Commission Bank Deposit

CashReceiptsEntry


For the above given context diagram the level 1 data flow diagram is illustrated below in figure 10.8

- 148 -

ACCOUNTING

Fig 10.7: Context DFD for Order processing system

1.0

Fill Order

2.0

CreateInvoice

3.0

ApplyPayment

SALESREP

BANK ACCOUNTING

CUSTOMER WAREHOUSE

Order

Order RejectNotice

Picking List

AccountsReceivableD1

Invoice

Invoice

Invoice DetailPayment

Detail

Payment

Commission Bank Deposit Cash Receipts Entry

Completed Order

Fig 10.8: Level 1 DFD for Order processing system


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 Constructing a Level 1 Data flow 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.

Make a list of all processes that exist in the problem.

- 149 -


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.

- 150 -


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.

- 151 -

EE-1

R e c o rd C lu bM e m b e r

1

Verify m em bers tatus

O R Clerk

EE-2

C u s t o m e r(n o n -m e m b e r)

D -1 M e m b e r M a s t e ro rd e r m e m b e rd a t a


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.

- 152 -

EE-1


1


O R Clerk

EE-2



n o n -m e m b e r o rd e ra n d a p p lic a t io n fo rm

2

Verify orderitem data

O R Clerk

m e m b e ro rd e r

D -2 It e m M a s t e rit e md a t a


FIFTH SENTENCE:

Then the clerk enters the order data and saves it to the Daily Orders file.

- 153 -

EE-1


1


O R Clerk

EE-2




2


O R Clerk

m e m b e ro rd e r


3

Enter orderin to D aily

O rders

O R Clerk

v e rifie dm e m b e r

o rd e r

D -3 D a ily O rd e rs D e t a ilo rd e r


SIXTH SENTENCE:

The clerk also prints an invoice and shipping list for each order, which are forwarded to Order Fulfillment.

- 154 -

EE-1


1


O R Clerk

EE-2




2


O R Clerk

m e m b e ro rd e r


3

Enter orderin to D aily

O rders

O R Clerk

v e rifie dm e m b e r

o rd e r

D -3 D a ily O rd e rs D e t a ilo rd e r

4

P rin t invoic eand

s hipping lis t

O R Clerk

o rd e rd a t a

EE-3

O rd e rF u lfillm e n t

in v o ic e a n ds h ip p in g lis t


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

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)?

- 155 -


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 company’s 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

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:

- 156 -


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

- 157 -


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

- 158 -


- 159 -

1.0

CheckStatus

2.0

IssueStatus

Messages

3.0

GenerateShipping

Order

ACCOUNTING

CUSTOMER WAREHOUSE

4.0

Manage Accounts

Receivable5.0

ProduceReports

Order In-Stock Request

Status Data

Status Message

PendingOrdersD1

Order Data

Order Data

Shipping Order

Shipping Confirmation

Invoice

Payment

Accounts ReceivableD2

Accounting Data Accounts Receivable Data

Order Data

Inventory Reports

Fig. 11.2 Level 0 DFD for Order System

DepartmentStaff

Courseinformation

Courseofferings Students

0

CourseRegistration

System

Enrollmentinformation

Studentschedules


Case Study 2: Online University Registration SystemThe 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

- 160 -


- 161 -

Fig. 11.3 Context diagram Online Registration System

3

CourseEnrollmentReports

D3 Enrollments

D2 Course Offerings

D1 Fees

2

Maintainstudentenrollments

1

Maintaindepartmentcourseofferings



- 162 -

DeptStaff

Course OfferingChanges

CourseOfferings

Availablecourses

Courseinformation

Student EnrollmentReport Request

StudentEnrollmentReport

Enrollmentinformation

StudentsCourseOfferingUpdates

Course OfferingList

Fee PaymentHistory

Availablecourse request

Available courses

Availablecourses

Course enrollment

Student schedule

Studentschedule

Courseenrollmentrequest

Fig. 11.4 Level 0 DFD for Online Registration System

Dept.Staff

Producecourseofferinglist

Add newcourse

Department ID

Department ID

D2 Course Offerings

Course todelete

Course modifications

Course OfferingList Request

Course offering list

New Courseinformation

New Course

Deletecourse

Modifyexistingcourses

Course to delete

Course modifications

Existing Courseinformation

1.1

1.2

1.3

1.4


Level 1 data flow diagram for process 1

- 163 -

Fig. 11.5 Level 1 DFD for Online Registration System - 1

Obtaincurrentschedule

D1 Fees

D3 Enrollments

Deletecourse fromschedule

D2 Course Offerings

Add courseto schedule

Producecourseofferinglist



- 164 -

StudentsCourse todelete

Current schedule request

Available courses

Course to addto enrollment

Course enrollment add

Course to delete

2.1

2.2

2.3

2.4

Available CourseRequest

AvailableCourses

Student enrollmentinformation

Fee payment history

Course enrollmentadd

Student schedule


Dept.Staff

Obtainreporttype

D2 Course Offerings

Reporttype

Course offeringinformation

Generaterequestedreport

3.1

3.2

ReportRequest

D3 EnrollmentsEnrollmentinformationRequested

report



- 165 -



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

- 167 -

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 amountDaily inventory depletion amount

Formatted goods sold dataFormatted inventory data


Level 0 diagram

- 168 -

Sellers AREISystem

Houseinformation

Buyerinformation

HouseInformation

0

BuyersHouseinformation

HouseInformation

Multiple ListingService


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 AREI’s 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 AREI’s 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

- 169 -


- 170 -

Sellers

Maintainhouseseller

information

D2 Sales Contracts

Houseinformation

Generaterequested

report

1

2

Sales Contract

D3 Offered Houses

House information

Buyer information form

D1 Multiple ListingServices File

House information

SalesContract

House information

House information

House information

Buyers

House information request

D4 BuyersBuyerinformation



- 171 -

Lease, Payments

Bank Deposit

Lease Cash

Report

Receipts, Notices

Tenant

Bank

ExternalManager

0

ApartmentRentalSystem


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

- 172 -

1

2

3

Tenant

NewTenantProcess

CollectionProcess

DelinquentProcess

Lease

D1 Tenant FileTenant Info

Payments

Bank

Bank DepositReceipt

ExternalManager

Cash Report

D1 Tenant File

UnpaidCharges

DelinquencyReport

TenantInfo

Delinquencies

Copy of lease

Notice


- 173 -


Deposit Checks

Rent Checks

2.1

2.2

Collect SecurityDeposit

CollectRent

Deposit Receipts

Payment Receipts

Unpaid Charges

Bank Deposit

Bank Deposit

D1 Tenant File

TenantInfo

TenantInfo

Cash Report


- 174 -


Deposit Check2.1.1

MakeBank

Deposit

Bank Deposit

2.1.2

UpdateTenant

File

Deposit Info

D1 Tenant FileUpdate Info

2.1.3

CreateReceipt

Tenant InfoReceipt


UNIT 12

SYSTEM ANALYSIS TOOLS - 3Data 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.

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 system’s 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.

B.Tech (CSE) - 175 -

Level 2 data flow diagram for process 2.1


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 flowEvery 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.

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 Customer Order



DescriptionContains customer order information and is used to update the

customer master and item files and to produce an order record.

Source / Origin External Entity, Customer

Destination Process 1.0, Add Customer Order

Type Screen

Data Structure Order Information

Volume/Time 25 per hour

Comments 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



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 Meaning

= (Equal to) Consists of

+ (Plus) And

{ } (Curly braces)Repeating element or group of elements

[ ] (Square braces)Either/or situation

() (Parentheses) Optional elementTable 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



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.



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.


following entries about order number data element as illustrated in table 12.3.

Name Order number

Alias Order Id

Description Used to identify order given to vendor

Length 8

Input Format 10 (6)

Output Format 10 (6)

Default Value --

Continuous/Discrete Continuous

Type Numeric

Base or Derived Derived

Upper Limit <999999

Lower Limit >0000

Comments 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

about the length of the field. Input and output formats should be included, using coding

symbols.



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.


following entries about Customer Master data store as illustrated in table 12.4.

ID DS1

Name Customer Master



Alias Client File

Description Contains customer information

File type Computer

File format Database

Record size 500

Maximum Size 45,800

Average Size 41,500

% Growth / year 8%

Data Set Customer

Data Structure Customer record

Primary key Cust id

Secondary key Cust name, Cust addr

Comments It is a key file that keeps tracks of customer data.

Table 12.4: Data repository entries for customer master data store



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

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

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

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

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 InventoryD1

1.1

UpdateInventory

Added

1.2

Update Inventory

UsedStock on

Hand

Qty Added

Counts

Products

Amounts Used


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)



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

Rules

contains selectors which identify

Action Stub

a list of all possible actions that occur within the process

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 B.Tech (CSE) - 190 -


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.



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 doesn’t 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

Banner’s restaurant – A decision table case study

Banner’s 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

XProduce absence report

XCalculate overtime

XXXCalculate hourly wage

XXXPay base salary

Action

>40>404040<40<40Hours worked

HSHSHSEmployee type

654321

Condition

Produce absence report

Calculate overtime

Calculate hourly wage

Pay base salary

Action

Hours worked

Employee type

ConditionRules

X

X

XXX

X

>4040<40-

HHHS

4321


Table 12.6 : Decsion table for Banner’s restaurant

The above table can further be simplified as illustrated in the table 12.7.



Table 12.7 : Simplified decsion table for Banner’s restaurant



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 can’t 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.

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

Steps to build a decision tree

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).


1

2

6

3

5

4

Condition

1

Condition 2

Action 1

Action 4

Action 2

Action 3

Condition

3

Condition 4


The following figure 12.2 illustrates the structure of a decision tree.

Figure 12.2: Decision tree structure

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


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

Triplemileage

Normalmileage

Saturday?Yes

No

TuesdayTrip?

Yes

No

9th legin month?

Yes

No

17th legIn month?

Yes

No


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

1.5 times

Double mileage

Triplemileage

Normalmileage

Saturday

Tuesday

9th legin month

17th legIn month

Not Saturday

Not Tuesday

Not 9th legin month

Not 17th legIn month


Figure 12.4: Decision tree structure for Premium Airlines (Simplified)



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


BestBestThird BestChecking

Consistency and Completeness

BestThird BestBestTransforming

Conditions and Actions into

Sequence

BestThird BestSecond BestDetermining

Conditions and Actions

Decision Trees

Decision Tables

Structured English

Criteria

WorstBestEasier to manipulate

WorstBestMore compact

BestWorstMaking decisions

BestWorstPortraying simple rules

WorstBestPortraying complex logic

Decision TreesDecision TablesCriteria


where decision has to be made between Decision Tables and Decision Trees which is

illustaed in Table 12.9

Table 12.8: Deciding Among Structured English, Decision Tables, and Decision Trees



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.

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.



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


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 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



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

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.

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.

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.

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.

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.

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.

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

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. Don’t require use of special characters. Don’t 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

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.

GUI controls

Common GUI Controls Uses



Text boxeso When the input data values are unlimited in scope

Radio buttonso When data has limited predefined set of mutually exclusive

values

Check boxeso When value set consists of a simple yes or no value

List boxeso When data has a large number of possible values

Drop down listso When data has large number of possible values and screen

space is too limited for a list box

Combination boxeso 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 boxeso 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

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.

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 can’t 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: Doctor’s 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 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).

• 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

• Old Tools

• Record Layout Charts

• Display Layout Charts

• Newer Prototyping Tools

• Microsoft Access

• CASE Tools



• Visual Basic

• Excel

• VisioModule 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:

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

. 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.

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

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.

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 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:

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.

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.

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.

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.

ObjectivesThe 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

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 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

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 5UNIT 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

Database design is the process of creating a design for a database that will support the organization’s operations and objectives.



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 ObjectivesA 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?)

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 Phases1. 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.

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.

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 people’s 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.

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 non-scalability.

Database Concepts



Anyone who works with databases should be fluent in the terminology. Below is a list of major concepts that one should know.

RealityThe real world itself is referred to as reality. DataIt is the piece of information collected about people, places or events. MetadataIt is the information that describes data.Entity An object or event about which the data is collected is called an entity. RelationshipsThese 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.

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. Variable-length 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.

KeyData items used to identify records.

Some Entity-Relationship Diagrams (E-R diagram)

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 they’re available 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 organization’s data architecture is comprised of the files and databases that store all of the organization’s 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 member’s employment record. However, we do not want to let everyone see each other’s salary history or even let all members of the payroll staff see the data that isn’t necessary to their job. Thus the manager’s view might be all fields and all tables; the payroll staff may see only an other’s pay rate (and not annual salary); while the same system may permit staff members to see all of their own record but none of another person’s.



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-user’s 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 "employee’s work department". A good data model is essentially non-redundant meaning that each data attribute describes at most only one entity other than 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, non-redundant, 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 non-primary 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 non-primary 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 organization’s 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.

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 data in this table can be deleted. For example, a library’s 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 book’s 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.



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 many-to-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.

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.

**************



UNIT 16

PROJECT MANAGEMENT

Project DefinitionA 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.


Cost

Scope

Time


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 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?

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


Fig 16.1: Project Constraints


Projects are often carried out by a team of people who have been assembled for that

specific purpose. The activities of this team may be coordinated by a project

manager.

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.

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.



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, CEO’s 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.



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.

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

Project facilitating knowledge areas

Human Resource

Management

Communication

Management

Risk Management Procurement

Management



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.

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:

o 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.

o Maintenance agreements will be a recurring cost of owning purchased

applications.

o 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

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?

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 etc…Agendas

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 etc…The 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.

Staff turnover will most likely occur on projects spanning a long time. A

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.

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 won’t exist in new version).

Project Plan should be developed and include:

Overview of the project - description, sponsors, stakeholders, deliverables

Organizational structure of the project – authority of project manager and

steering committee, responsibilities and communication for the project,

reporting structure of project



Management and technical approaches – management objectives, project

controls (status reports, how to handle changes), risk management, project

staffing plan, technology methodologies

Scope management plan – WBS (work break-down structure) or high level

task list, key deliverables

Project schedule – summary and detailed

Budget – summary and detailed, assumptions

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

Should be detailed – scripts should be developed for minimal testing. This

doesn’t mean that other testing is not also needed.

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 gaps.

Issue list should be maintained throughout project to ensure issues are

resolved before implementation or at least be aware that those issues exist.

Instances (QA/DEV/Production) – when testing, instances need to be

compatible to ensure the needed functionality is transferred from one version

to the next.

Issues found after testing should be included in test scripts to detect in future

upgrades/enhancements to the system.

Training



Evaluations may be needed to determine if there is additional training that is

needed. Be careful in assumptions regarding knowledge level of the users.

Adequate time should be allowed for training. A common theme in all

feedback was that there wasn’t enough time for testing. Need to identify a

“rule of thumb” for project managers to use as a guide.

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.

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 FailureInspite 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 organization’s 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.

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.

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

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 Dec1 2 mo. 2 2 mo. 3 2 mo. 4 2 mo. 5 2 mo. 6 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.

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 behind-

schedule 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.

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

Publish Series

Design jacket

Improve manuscript

PREPRODUCTION

Print

Design layout

PRODUCTION

Advertising campaign

Sales drive

ROLL OUT


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.



Fig 16.5: WBS for Publish Series

Since WBS is a hierarchical structure, it may also be conveyed in outline form as:

Level 1 Level 2 Level 3

Task 1

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

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.

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 activity-

on-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

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 non-

critical 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

for the fact that all preceding activities have been completed.



LS = Latest Start Time. This is the latest time an activity can be started without

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

remain on schedule.

S = Activity Slack Time. The amount of slippage in activity start or duration time

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.

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

NoActivity

Expected

completion timeDependency

1. Requirements collection 5 -

2. Screen design 6 1

3. Report design 7 1

4. Database design 2 2,3

5. User documentation 6 4

6. Programming 5 4

7. Testing 3 6

8. Installation 1 5,7

a. Draw a PERT chart for the activities.

b. Calculate the earliest expected completion time.

c. Show the critical path.


1

2

3

4

5

6

8

7

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


a. PERT Chart construction

Using information from the table the PERT chart in figure 16.6 show the sequence of

activities.

b. Earliest expected completion time calculation

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.

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).


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


c. Critical path identification

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 17System 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

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.

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.

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:

Improve Quality and reduce the risk of system failure

Establish concrete requirements specifications and complete requirements

documentation

Focus on Reliability, Flexibility, and Maintainability of system



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.

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

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

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 system’s

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:

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

• Deliverables

– Final performance specification

– Detailed logical models

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

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.

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

• Deliverables

– Physical specification

– A formal feasibility analysis

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.

- 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 process.

- 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

- 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. Design database

3. Design the human/computer interface


Essential Model

EnvironmentalModel

BehavioralModel

Implementation Model


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:

Figure Elements of structured design

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.

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

ImplementationModel

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 entity-

relationship 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 Effect on Design

Dataflow diagram not balanced Interface Problems

‘Fuzzy’ process name Need to repartitioning

No dictionary Duplicates and aliasing

Dictionary not correlated with dataflow diagrams

Duplicates and aliasing and interface problems



Dataflow diagrams not correlated with dictionary

Duplicates and aliasing and interface problems

Pseudo code not validated Logic errors

Pseudo code not correlated with dictionary

Data aliases, interface problems

Table Problems effecting design process



Development phase

Type of model

Structured Analysis Structured Design Implementation

Process DataFlow Diagrams

Dictionary

Pseudocode

Structure Chart

Dictionary

Pseudocode

Code

Dictionary

Information Entity-Relationship

Diagram

Dictionary

Database Design

Dictionary

Implemented

Database

Dictionary

Event Event Model

Dictionary

Event Model

Dictionary

Queuing Model

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.

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

analyst’s 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

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):



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.



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 class-

to-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

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

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..

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

corporation’s goals and objectives. A user-driven system is then developed using a top-

down 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

corporation’s goals and objectives adds a high-level, executive, strategic perspective to

the methodology. The methodology has a strong data orientation, leading to clearly-

defined 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.

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.

• 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

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.

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 system’s 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

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

User - represents end users’ perspective with regard to proposed

system

Manager - represents management’s perspective with regard to

proposed system

Project Sponsor - represents all parties responsible for funding and

supporting the development effort

Analyst - analyst participation is limited to observation and listening

to better understand the needs of the users and managers

Scribe - responsible for taking notes and recording important

information and events relevant to the JAD proceedings

IS Staff - responsible for providing clarification on technical

questions and issues

- contribute ideas on technical feasibility of and limitations

of proposed system components

Table 6.1 Description of Role of each JAD Participant



Consider RAD when… Avoid RAD when…

The software application will run

standalone without other system

interactions.

Application performance is not mission

critical.

Application distribution will be narrow (in-

house or controlled vertical market).

Project scope is significantly constrained.

Application reliability is not mission

critical.

System can be subdivided into multiple

independent modules.

The required technology is considered mature (more

than one year).

Application must interact with existing

system applications.

Optimal performance is mission critical.

Application development cannot take

advantage of high-end IS tools (i.e., 4th

generation programming languages).

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).

Technical feasibility is low due to use of

"bleeding" edge technology.

The application is mission- or life-critical.

The system cannot be modularized (defeats 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

(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

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

problem’s 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 participant’s 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

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

• Parallel Development

Requirements

Planning

User

Design Construction Cutover

Primary

Activity

Model and

prototype

requirements

Model and

prototype

design

Complete

application

development

Install

application

Data

Conversion

Define data

requirements

Plan and design

data conversion

Develop data

conversion

modules

Implement

conversion plan

Testing

Design

application test

plan

Conduct user

testing

End-user

Training

Define training

requirements

Design training

plan

Produce

training

materials

Conduct end-

user 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

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,

standards should be established for the organization’s 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

“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 18Quality Assurance



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 Deming’s 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.

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 Japan’s 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 quality-

focused 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 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

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.

Shewart’s 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

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.



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.

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:

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.

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


Business Plan

Documents

Transcript of Business Plan