1

THE COMPLETE HAND BOOK ON SYSTEM ANALYSIS AND DESIGN AND

MANAGEMENT INFORMATION SYSTEMS

BY

THEMBO JIMMY

[IT TECHNICIAN KYAMBOG UNIVERSITY]

2

SYSTEMS ANALYSIS AND DESIGN

COMPLETE INTRODUCTORY TUTORIAL

Computers are fast becoming our way of life and one cannot imagine life without computers in

today‘s world. You go to a railway station for reservation, you want to web site a ticket for a

cinema, you go to a library, or you go to a bank, you will find computers at all places. Since

computers are used in every possible field today, it becomes an important issue to understand

and build these computerized systems in an effective way.

Building such systems is not an easy process but requires certain skills and capabilities to

understand and follow a systematic procedure towards making of any information system. For

this, experts in the field have devised various methodologies. Waterfall model is one of the

oldest methodologies. Later Prototype Model, Object Oriented Model, Dynamic Systems

Development Model, and many other models became very popular for system development. For

anyone who is a part of this vast and growing Information Technology industry, having basic

understanding of the development process is essential. For the students aspiring to become

professionals in the field a thorough knowledge of these basic system development

methodologies is very important.

In this web site we have explored the concepts of system development. The web site starts with

the system concepts, making the reader understand what does system mean in general and what

are information systems in specific. The web site then talks about the complete development

process discussing the various stages in the system development process. The different types of

system development methodologies, mentioned above, are also explained.

This tutorial is for beginners to System Analysis and Design (SAD) Process. If you are new to

computers and want to acquire knowledge about the process of system development, then you

will find useful information in this tutorial. This tutorial is designed to explain various aspects of

software development and different techniques used for building the system. This tutorial is a

good introductory guide to the need and overall features of software engineering.

This tutorial is designed to introduce Software Engineering concepts to the upcoming software

professionals. It assumes that its reader does not know anything about the system development

process. However it is assumed that the reader knows the basics of computers.

What is Software Engineering?

Software Engineering is the systematic aproach to the development, operation and maintenance

of software. Software Engineering is concerned with development and maintenance of software

products.

3

The primary goal of software engineering is to provide the quality of software with low cost.

Software Engineering involves project planning, project management, systematic analysis,

design, validations and maintenance activities.

System Analysis and Design Contents

1. Introduction to Systems

2. Software (System) Development Life Cycle Models

3. Preliminary Analysis

4. Fact Finding and Decision Making Techniques

5. Functional Modeling I

6. Functional Modeling II

7. Data Modeling Techniques

8. Relational Data Modeling and Object Oriented Data Modeling Techniques

9. Testing and Quality Assurance

Brief Explanation of the chapters in this tutorial

1. Introduction to Systems - Introduces the concept of systems to the reader and explains what an

information system is. It talks about various types of information systems and their relevance to

the functioning of any organization. This chapter also gives a brief introduction to system

analysis and design.

2. Software (System) Development Life Cycle Models - Explains various activities involved in

the development of software systems. It presents the different approaches towards software

development. In this chapter, Waterfall Model, Prototype Model, Dynamic System Development

Model, and Object Oriented models are discussed.

3. Preliminary Analysis - covers various activities that are performed during the preliminary

analysis of the system development. It shows how the feasibility study for the system to be

developed is done. Also in the later part of the chapter various software estimation techniques are

discussed.

4. Fact Finding and Decision Making Techniques - shows the various techniques used for fact

finding during the analysis of the system. In this, interviews, questionnaires, on site observation,

and record reviews are presented. This chapter also discusses the decision-making and

4

documentation techniques. For this Decision Tables, Decision Tress, Structured English and

Data Dictionary is presented.

5. Functional Modeling I - presents the various concepts of system design. Design elements like

input-output to the system, processes involved in the system and the database elements of the

system are discussed. It also discusses Data Flow Diagrams that are used to represent the

functionality of the system.

6. Functional Modeling II - introduces the modular programming concept to the software

development. It explains the structure charts that represent the modular structure of various

modules of the software being developed. Concepts like Cohesion and Coupling that further

enhance the users understanding of modular designing are also presented.

7. Data Modeling Techniques - presents the concepts involve in the data modeling phase of

system development where the storage of data and the storage form is discussed. Here Entity

Relationship model along with Entity Relationship Diagrams is used to illustrate the data

modeling concepts. are discussed.

8. Relational Data Modeling and Object Oriented Data Modeling Techniques - is an extension to

the chapter 7 (Data Modeling Techniques). Here two other data models, Relational and Object

Oriented Models are discussed. Comparison of the two models is also presented.

9. Testing and Quality Assurance - covers the various testing techniques and strategies employed

during the development of the system. Also various quality assurance activities for software

development are presented.

What is a System?

The term ―system‖ originates from the Greek term syst¯ema, which means to ―place together.‖ Multiple

business and engineering domains have definitions of a system. This text defines a system as:

System An integrated set of interoperable elements, each with explicitly specified and bounded

capabilities, working synergistically to perform value-added processing to enable a User to satisfy

mission-oriented operational needs in a prescribed operating environment with a specified outcome

and probability of success.

To help you understand the rationale for this definition, let‘s examine each part in detail.

System Definition Rationale

The definition above captures a number of key discussion points about systems. Let‘s examine the basis for

each phrase in the definition.

By ―an integrated set,‖ we mean that a system, by definition, is composed of hierarchical levels of

physical elements, entities, or components.

5

By ―interoperable elements,‖ we mean that elements within the system‘s structure must be

compatible with each other in form, fit, and function, for example. System elements include

equipment (e.g., hardware and system, system, facilities, operating constraints, support),

maintenance, supplies, spares, training, resources, procedural data, external systems, and anything

else that supports mission accomplishment.

One is tempted to expand this phrase to state ―interoperable and complementary.‖ In general, system

elements should have complementary missions and objectives with nonoverlapping capabilities. However,

redundant systems may require duplication of capabilities across several system elements. Additionally,

some systems, such as networks, have multiple instances of the same components.

By each element having ―explicitly specified and bounded capabilities,‖ we mean that every element

should work to accomplish some higher level goal or purposeful mission. System element

contributions to the overall system performance must be explicitly specified. This requires that

operational and functional performance capabilities for each system element be identified and

explicitly bounded to a level of specificity that allows the element to be analyzed, designed,

developed, tested, verified, and validated—either on a stand-alone basis or as part of the integrated

system.

By ―working in synergistically,‖ we mean that the purpose of integrating the set of elements is to

leverage the capabilities of individual element capabilities to accomplish a higher level capability

that cannot be achieved as stand-alone elements.

By ―value-added processing,‖ we mean that factors such operational cost, utility, suitability,

availability, and efficiency demand that each system operation and task add value to its inputs

availability, and produce outputs that contribute to achievement of the overall system mission

outcome and performance objectives.

By ―enable a user to predictably satisfy mission-oriented operational needs,‖ we mean that every

system has a purpose (i.e., a reason for existence) and a value to the user(s). Its value may be a

return on investment (ROI) relative to satisfying operational needs or to satisfy system missions and

objectives.

By ―in a prescribed operating environment,‖ we mean that for economic, outcome, and survival

reasons, every system must have a prescribed—that is, bounded—operating environment.

By ―with a specified outcome,‖ we mean that system stakeholders (Users, shareholders, owners,

etc.) expect systems to produce results. The observed behavior, products, byproducts, or services,

for example, must be outcome-oriented, quantifiable, measurable, and verifiable.

By ―and probability of success,‖ we mean that accomplishment of a specific outcome involves a

degree of uncertainty or risk. Thus, the degree of success is determined by various performance

factors such as reliability, dependability, availability, maintainability, sustainability, lethality, and

survivability.

You need at least four types of agreement on working level definitions of a system:

1. a personal understanding

2. a program team consensus

3. an organizational (e.g., System Developer) consensus, and

6

4. most important, a contractual consensus with your customer.

Why? Of particular importance is that you, your program team, and your customer (i.e., a User or an

Acquirer as the User‘s technical representative) have a mutually clear and concise understanding of the

term. Organizationally you need a consensus of agreement among the System Developer team members.

The intent is to establish continuity across contract and organizations as personnel transition between

programs.

Other Definitions of a System

National and international standards organizations as well as different authors have their own definitions of

a system. If you analyze these, you will find a diversity of viewpoints, all tempered by their personal

knowledge and experiences. Moreover, achievement of a ―one size fits all‖ convergence and consensus by

standards organizations often results in wording that is so diluted that many believe it to be insufficient and

inadequate. Examples of organizations having standard definitions include:

International Council on Systems Engineering (INCOSE)

Institute of Electrical and Electronic Engineers (IEEE)

American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA)

International Standards Organization (ISO)

US Department of Defense (DoD)

US National Aeronautics and Space Administration (NASA)

US Federal Aviation Administration (FAA)

You are encouraged to broaden your knowledge and explore definitions by these organizations. You should

then select one that best fits your business application. Depending on your personal viewpoints and needs,

the definition stated in this text should prove to be the most descriptive characterization.

Closing Point

When people develop definitions, they attempt to create content and grammar simultaneously. People

typically spend a disproportionate amount of time on grammar and spend very little time on substantive

content. We see this in specifications and plans, for example. Grammar is important, since it is the root of

our language and communications. However, wordsmithed grammar has no value if it lacks substantive

content.

You will be surprised how animated and energized people become over wording exercises. Subsequently,

they throw up their hands and walk away. For highly diverse terms such as a system, a good definition may

sometimes be simply a bulleted list of descriptors concerning what a term is or, perhaps, is not. So, if you or

your team attempts to create your own definition, perform one step at a time. Obtain consensus on the key

elements of substantive content. Then, structure the statement in a logical sequence and translate the

structure into grammar.

7

Learning to Recognize Types of Systems

Systems occur in a number of forms and vary in composition, hierarchical structure, and

behavior. Consider the next high-level examples.

Economic systems

Educational systems

Financial systems

Environmental systems

Medical systems

Corporate systems

Insurance systems

Religious systems

Social systems

Psychological systems

Cultural systems

Food distribution systems

Transportation systems

Communications systems

Entertainment systems

Government systems

Legislative systems, Judicial systems, Revenue systems, Taxation systems, Licensing

systems, Military systems, Welfare systems, Public safety systems, Parks and recreation

systems, Environmental systems

If we analyze these systems, we find that they produce combinations of products, by-products, or

services. Further analysis reveals most of these fall into one or more classes such as individual

versus organizational; formal versus informal; ground-based, sea-based, air-based, space-based,

or hybrid; human-in-the-loop (HITL) systems, open loop versus closed loop; and fixed, mobile,

and transportable systems.

Delineating Systems, Products and Tools

People often confuse the concepts of systems, products, and tools. To facilitate our discussion,

let‘s examine each of these terms in detail.

System Context

8

We defined the term system earlier in this section. A system may consist of two or more

integrated elements whose combined—synergistic—purpose is to achieve mission objectives that

may not be effectively or efficiently accomplished by each element on an individual basis. These

systems typically include humans, products, and tools to varying degrees. In general, human-

made systems require some level of human resources for planning, operation, intervention, or

support.

Product Context

Some systems are created as a work product by other systems. Let‘s define the context of

product: a product, as an ENABLING element of a larger system, is typically a physical device

or entity that has a specific capability—form, fit, and function—with a specified level of

performance.

Products generally lack the ability—meaning intelligence—to self-apply themselves without

human assistance. Nor can products achieve the higher level system mission objectives without

human intervention in some form. In simple terms, we often relate to equipment-based products

as items you can procure from a vendor via a catalog order number. Contextually, however, a

product may actually be a vendor‘s ―system‖ that is integrated into a User‘s higher-level system.

Effectively, you create a system of systems (SoS).

Example

1. A hammer, as a procurable product has form, fit, and function but lacks the ability to apply its

self to hammering or removing nails.

2. Ajet aircraft, as a system and procurable vendor product, is integrated into an airline‘s system

and may possess the capability, when programmed and activated by the pilot under certain

conditions, to fly.

Tool Context

Some systems or products are employed as tools by higher level systems. Let‘s define what we

mean by a tool. A tool is a supporting product that enables a user or system to leverage its own

capabilities and performance to more effectively or efficiently achieve mission objectives that

exceed the individual capabilities of the User or system.

Example

1. A simple fulcrum and pivot, as tools, enable a human to leverage their own physical strength

to displace a rock that otherwise could not be moved easily by one human.

2. A statistical software application, as a support tool, enables a statistician to efficiently analyze

large amounts of data and variances in a short period of time.

9

Analytical Representation of a System

As an abstraction we symbolically represent a system as a simple entity by using a rectangular

box as shown in Figure 1. In general, inputs such as stimuli and cues are fed into a system that

processes the inputs and produces an output. As a construct, this symbolism is acceptable;

however, the words need to more explicitly identify WHAT the system performs. That is, the

system must add value to the input in producing an output.

We refer to the transformational processing that adds value to inputs and produces an output as a

capability. You will often hear people refer to this as the system‘s functionality; this is partially

correct. Functionality only represents the ACTION to be accomplished; not HOW WELL as

characterized by performance. This text employs capability as the operative term that

encompasses both the functionality and performance attributes of a system.

The simple diagram presented in Figure 1 represents a system. However, from an analytical

perspective, the diagram is missing critical information that relates to how the system operates

and performs within its operating environment. Therefore, we expand the diagram to identify

these missing elements. The result is shown in Figure 2. The attributes of the construct—which

include desirable/undesirable inputs, stakeholders, and desirable/undesirable outputs—serve as a

key checklist to ensure that all contributory factors are duly considered when specifying,

designing, and developing a system.

Figure 1 - Basic System Entity Construct

10

Figure 2 - Analytical System Entity Construct

Systems that Require Engineering

Earlier we listed examples of various types of systems. Some of these systems are workflow-

based systems that produce systems, products, or services such as schools, hospitals, banking

systems, and manufacturers. As such, they require insightful, efficient, and effective

organizational structures, supporting assets, and collaborative interactions.

Some systems require the analysis, design, and development of specialized structures, complex

interactions, and performance monitoring that may have an impact on the safety, health, and

wellbeing of the public as well as the environment, engineering of systems may be required. As

you investigate WHAT is required to analyze, design, and develop both types of systems, you

will find that they both share a common set concepts, principles, and practices. Business systems,

for example, may require application of various analytical and mathematical principles to

develop business models and performance models to determine profitability and return on

investment (ROI) and statistical theory for optimal waiting line or weather conditions, for

example. In the case of highly complex systems, analytical, mathematical, and scientific

principles may have to be applied. We refer to this as the engineering of systems, which may

require a mixture of engineering disciplines such as system engineering, electrical engineering,

mechanical engineering, and software engineering. These disciplines may only be required at

various stages during the analysis, design, and development of a system, product, or service.

This text provides the concepts, principles, and practices that apply to the analysis, design, and

development of both types of systems. On the surface these two categories imply a clear

distinction between those that require engineering and those that do not. So, how do you know

when the engineering of systems is required?

Actually these two categories represent a continuum of systems, products, or services that range

from making a piece of paper, which can be complex, to developing a system as complex as an

11

aircraft carrier or NASA ‘s International Space Station (ISS). Perhaps the best way to address the

question: What is system engineering?

What Is System Engineering?

Explicitly System Engineering (SE) is the multidisciplinary engineering of systems. However, as

with any definition, the response should eliminate the need for additional clarifying questions.

Instead, the engineering of a system response evokes two additional questions: What is

engineering? What is a system? Pursuing this line of thought, let‘s explore these questions

further.

Defining Key Terms

Engineering students often graduate without being introduced to the root term that provides the

basis for their formal education. The term, engineering originates from the Latin word

ingenerare, which means ―to create.‖ Today, the Accreditation Board for Engineering and

Technology (ABET), which accredits engineering schools in the United States, defines the term

as follows:

Engineering ―[T]he profession in which knowledge of the mathematical and natural

sciences gained by study, experience, and practice is applied with judgment to develop

ways to utilize economically the materials and forces of nature for the benefit of

mankind.‖ (Source: Accreditation Board for Engineering and Technology [ABET])

There are a number of ways to define System Engineering (SE), each dependent on an

individual‘s or organization‘s perspectives, experiences, and the like. System engineering means

different things to different people.

You will discover that even your own views of System Engineering (SE) will evolve over time.

So, if you have a diver-sity of perspectives and definitions, what should you do? What is

important is that you, program teams, or your organization:

1. Establish a consensus definition.

2. Document the definition in organizational or program command media to serve as a

guide for all.

For those who prefer a brief, high-level definition that encompasses the key aspects of System

Engineering (SE), consider the following definition:

System Engineering (SE) The multidisciplinary application of analytical, mathematical,

and scientific principles to formulating, selecting, and developing a solution that has

acceptable risk, satisfies user operational need(s), and minimizes development and life

cycle costs while balancing stakeholder interests.

This definition can be summarized in a key System Engineering (SE) principle:

12

System engineering BEGINS and ENDS with the User.

System Engineering (SE), as we will see, is one of those terms that requires more than simply

defining WHAT System Engineering (SE) does; the definition must also identify WHO/WHAT

benefits from System Engineering (SE). The ABET definition of engineering, for example,

includes the central objective ―to utilize, economically, the materials and forces of nature for the

benefit of mankind.‖

Applying this same context to the definition of System Engineering (SE), the User of systems,

products, and services symbolizes humankind. However, mankind‘s survival is very dependent

on a living environment that supports sustainment of the species. Therefore, System Engineering

(SE) must have a broader perspective than simply ―for the benefit of mankind.‖ System

Engineering (SE) must also ensure a balance between humankind and the living environment

without sacrificing either.

System Components and Characteristics

A big system may be seen as a set of interacting smaller systems known as subsystems or

functional units each of which has its defined tasks. All these work in coordination to achieve the

overall objective of the system. System engineering requires development of a strong foundation

in understanding how to characterize a system, product, or service in terms of its attributes,

properties, and performance.

As discussed above, a system is a set of components working together to achieve some goal. The

basic elements of the system may be listed as:

Resources

Procedures

Data/Information

Intermediate Data

Processes

Resources

Every system requires certain resources for the system to exist. Resources can be hardware,

software or liveware. Hardware resources may include the computer, its peripherals, stationery

etc. Software resources would include the programs running on these computers and the liveware

would include the human beings required to operate the system and make it functional.

Thus these resources make an important component of any system. For instance, a Banking

system cannot function without the required stationery like cheque books, pass books etc. such

13

systems also need computers to maintain their data and trained staff to operate these computers

and cater to the customer requirements.

Procedures

Every system functions under a set of rules that govern the system to accomplish the defined

goal of the system. This set of rules defines the procedures for the system to Chapter 1 -

Introduction to Systems operate. For instance, the Banking systems have their predefined rules

for providing interest at different rates for different types of accounts.

Data/Information

Every system has some predefined goal. For achieving the goal the system requires certain

inputs, which are converted into the required output. The main objective of the System is to

produce some useful output. Output is the outcome of processing. Output can be of any nature

e.g. goods, services or information.

However, the Output must conform to the customer's expectations. Inputs are the elements that

enter the system and produce Output. Input can be of various kinds, like material, information,

etc.

Intermediate Data

Various processes process system's Inputs. Before it is transformed into Output, it goes through

many intermediary transformations. Therefore, it is very important to identify the Intermediate

Data. For example, in a college when students register for a new semester, the initial form

submitted by student goes through many departments. Each department adds their validity

checks on it.

Finally the form gets transformed and the student gets a slip that states whether the student has

been registered for the requested subjects or not. It helps in building the System in a better way.

Intermediate forms of data occur when there is a lot of processing on the input data. So,

intermediate data should be handled as carefully as other data since the output depends upon it.

Processes

The systems have some processes that make use of the resources to achieve the set goal under

the defined procedures. These processes are the operational element of the system.

For instance in a Banking system there are several processes that are carried out. Consider for

example the processing of a cheque as a process. A cheque passes through several stages before

it actually gets processed and converted. These are some of the processes of the Banking system.

All these components together make a complete functional system.

Systems also exhibit certain features and characteristics, some of which are:

14

Objective

Standards

Environment

Feedback

Boundaries and interfaces

Objective

Every system has a predefined goal or objective towards which it works. A system cannot exist

without a defined objective. For example an organization would have an objective of earning

maximum possible revenues, for which each department and each individual has to work in

coordination.

Standards

It is the acceptable level of performance for any system. Systems should be designed to meet

standards. Standards can be business specific or organization specific.

For example take a sorting problem. There are various sorting algorithms. But each has its own

complexity. So such algorithm should be used that gives most optimum efficiency. So there

should be a standard or rule to use a particular algorithm. It should be seen whether that

algorithm is implemented in the system.

Environment

Every system whether it is natural or man made co-exists with an environment. It is very

important for a system to adapt itself to its environment. Also, for a system to exist it should

change according to the changing environment. For example, we humans live in a particular

environment. As we move to other places, there are changes in the surroundings but our body

gradually adapts to the new environment. If it were not the case, then it would have been very

difficult for human to survive for so many thousand years.

Another example can be Y2K problem for computer systems. Those systems, which are not Y2K

compliant, will not be able to work properly after year 2000. For computer systems to survive it

is important these systems are made Y2K compliant or Y2K ready.

Feed Back

Feedback is an important element of systems. The output of a system needs to be observed and

feedback from the output taken so as to improve the system and make it achieve the laid

standards. In fig 1.1, it is shown that a system takes input. It then transforms it into output. Also

some feedback can come from customer (regarding quality) or it can be some intermediate data

(the output of one process and input for the other) that is required to produce final output.

Boundaries and Interfaces

15

Every system has defined boundaries within which it operates. Beyond these limits the system

has to interact with the other systems. For instance, Personnel system in an organization has its

work domain with defined procedures. If the financial details of an employee are required, the

system has to interact with the Accounting system to get the required details.

Interfaces are another important element through which the system interacts with the outside

world. System interacts with other systems through its interfaces. Users of the systems also

interact with it through interfaces. Therefore, these should be customized to the user needs.

These should be as user friendly as possible.

Classifications of System

From previous section we have a firm knowledge of various system components and its

characteristics. There are various types of system. To have a good understanding of these

systems, these can be categorized in many ways. Some of the categories are open or closed,

physical or abstract and natural or man made information systems, which are explained next.

Classification of systems can be done in many ways.

Physical or Abstract System

Physical systems are tangible entities that we can feel and touch. These may be static or dynamic

in nature. For example, take a computer center. Desks and chairs are the static parts, which assist

in the working of the center. Static parts don't change. The dynamic systems are constantly

changing. Computer systems are dynamic system. Programs, data, and applications can change

according to the user's needs.

Abstract systems are conceptual. These are not physical entities. They may be formulas,

representation or model of a real system.

Open Closed System

Systems interact with their environment to achieve their targets. Things that are not part of the

system are environmental elements for the system. Depending upon the interaction with the

environment, systems can be divided into two categories, open and closed.

Open systems: Systems that interact with their environment. Practically most of the systems are

open systems. An open system has many interfaces with its environment. It can also adapt to

changing environmental conditions. It can receive inputs from, and delivers output to the outside

of system. An information system is an example of this category.

Closed systems:Systems that don't interact with their environment. Closed systems exist in

concept only.

Man made Information System

16

The main purpose of information systems is to manage data for a particular organization.

Maintaining files, producing information and reports are few functions. An information system

produces customized information depending upon the needs of the organization. These are

usually formal, informal, and computer based.

Formal Information Systems: It deals with the flow of information from top management to

lower management. Information flows in the form of memos, instructions, etc. But feedback can

be given from lower authorities to top management.

Informal Information systems: Informal systems are employee based. These are made to solve

the day to day work related problems. Computer-Based Information Systems: This class of

systems depends on the use of computer for managing business applications. These systems are

discussed in detail in the next section.

Information Systems

In the previous section we studied about various classifications of systems. Since in business we

mainly deal with information systems we'll further explore these systems. We will be talking

about different types of information systems prevalent in the industry.

Information system deals with data of the organizations. The purposes of Information system are

to process input, maintain data, produce reports, handle queries, handle on line transactions,

generate reports, and other output. These maintain huge databases, handle hundreds of queries

etc. The transformation of data into information is primary function of information system.

These types of systems depend upon computers for performing their objectives. A computer

based business system involves six interdependent elements. These are hardware (machines),

software, people (programmers, managers or users), procedures, data, and information

(processed data). All six elements interact to convert data into information. System analysis

relies heavily upon computers to solve problems. For these types of systems, analyst should have

a sound understanding of computer technologies.

In the following section, we explore three most important information systems namely,

transaction processing system, management information system and decision support system,

and examine how computers assist in maintaining Information systems

Types of Information Systems

Information systems differ in their business needs. Also depending upon different levels in

organization information systems differ. Three major information systems are

1. Transaction processing systems

17

2. Management information systems

3. Decision support systems

Figure 1.2 shows relation of information system to the levels of organization. The information

needs are different at different organizational levels. Accordingly the information can be

categorized as: strategic information, managerial information and operational information.

Strategic information is the information needed by top most management for decision making.

For example the trends in revenues earned by the organization are required by the top

management for setting the policies of the organization. This information is not required by the

lower levels in the organization. The information systems that provide these kinds of information

are known as Decision Support Systems.

Figure 1.2 - Relation of information systems to levels of organization

The second category of information required by the middle management is known as managerial

information. The information required at this level is used for making short term decisions and

plans for the organization. Information like sales analysis for the past quarter or yearly

production details etc. fall under this category. Management information system (MIS) caters to

such information needs of the organization. Due to its capabilities to fulfill the managerial

information needs of the organization, Management Information Systems have become a

necessity for all big organizations. And due to its vastness, most of the big organizations have

separate MIS departments to look into the related issues and proper functioning of the system.

The third category of information is relating to the daily or short term information needs of the

organization such as attendance records of the employees. This kind of information is required at

the operational level for carrying out the day-to-day operational activities. Due to its capabilities

to provide information for processing transaction of the organization, the information system is

18

known as Transaction Processing System or Data Processing System. Some examples of

information provided by such systems areprocessing of orders, posting of entries in bank,

evaluating overdue purchaser orders etc.

Transaction Processing Systems

TPS processes business transaction of the organization. Transaction can be any activity of the

organization. Transactions differ from organization to organization. For example, take a railway

reservation system. Booking, canceling, etc are all transactions. Any query made to it is a

transaction. However, there are some transactions, which are common to almost all

organizations. Like employee new employee, maintaining their leave status, maintaining

employees accounts, etc.

This provides high speed and accurate processing of record keeping of basic operational

processes. These include calculation, storage and retrieval.

Transaction processing systems provide speed and accuracy, and can be programmed to follow

routines functions of the organization.

Management Information Systems

These systems assist lower management in problem solving and making decisions. They use the

results of transaction processing and some other information also. It is a set of information

processing functions. It should handle queries as quickly as they arrive. An important element of

MIS is database.

A database is a non-redundant collection of interrelated data items that can be processed through

application programs and available to many users.

Decision Support Systems

These systems assist higher management to make long term decisions. These type of systems

handle unstructured or semi structured decisions. A decision is considered unstructured if there

are no clear procedures for making the decision and if not all the factors to be considered in the

decision can be readily identified in advance.

These are not of recurring nature. Some recur infrequently or occur only once. A decision

support system must very flexible. The user should be able to produce customized reports by

giving particular data and format specific to particular situations.

Summary of Information Systems

Catagories of Information System Characteristices

Transaction Processing System Substitutes computer-based processing for manual

19

procedures.

Deals with well-structured processes. Includes

record keeping applications.

Management information system Provides input to be used in the managerial decision

process. Deals with supporting well structured

decision situations. Typical information

requirements can be anticipated.

Decision support system Provides information to managers who must make

judgements about particular situations. Supports

decision-makers in situations that are not well

structured.

.

Brief Introduction to System Analysis and Design

Till now we have studied what systems are, their components, classification of system,

information system. Now we will look into the different aspects of how these systems are built.

Any change in the existing policies of an organization may require the existing information

system to be restructured or complete development of a new information system. In case of an

organization functioning manually and planning to computerize its functioning, the development

of a new information system would be required.

The development of any information system can be put into two major phases: analysis and

Design. During analysis phase the complete functioning of the system is understood and

requirements are defined which lead to designing of a new system. Hence the development

process of a system is also known as System Analysis and Design process. So let us now

understand

1. What exactly System Analysis and Design is?

2. Who is system analyst and what are his various responsibilities?

3. Users of the Systems?

What is System Analysis and Design?

20

System development can generally be thought of having two major components: systems

analysis and systems design.In System Analysis more emphasis is given to understanding the

details of an existing system or a proposed one and then deciding whether the proposed system is

desirable or not and whether the existing system needs improvements. Thus, system analysis is

the process of investigating a system, identifying problems, and using the information to

recommend improvements to the system.

Stages in building an improved system

The above figuer shows the various stages involved in building an improved system.

System design is the process of planning a new business system or one to replace or complement

an existing system.

Analysis specifies what the system should do. Design states how to accomplish the objective.

After the proposed system is analyzed and designed, the actual implementation of the system

occurs. After implementation, working system is available and it requires timely maintenance.

See the fugure above.

Role of System Analyst

21

The system analyst is the person (or persons) who guides through the development of an

information system. In performing these tasks the analyst must always match the information

system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common responsibilities

of System Analyst are following

1) System analysis

It includes system's study in order to get facts about business activity. It is about getting

information and determining requirements. Here the responsibility includes only requirement

determination, not the design of the system.

2) System analysis and design:

Here apart from the analysis work, Analyst is also responsible for the designing of the new

system/application.

3) Systems analysis, design, and programming:

Here Analyst is also required to perform as a programmer, where he actually writes the code to

implement the design of the proposed application.

Due to the various responsibilities that a system analyst requires to handle, he has to be

multifaceted person with varied skills required at various stages of the life cycle. In addition to

the technical know-how of the information system development a system analyst should also

have the following knowledge.

Business knowledge: As the analyst might have to develop any kind of a business system,

he should be familiar with the general functioning of all kind of businesses.

Interpersonal skills: Such skills are required at various stages of development process for

interacting with the users and extracting the requirements out of them

Problem solving skills: A system analyst should have enough problem solving skills for

defining the alternate solutions to the system and also for the problems occurring at the

various stages of the development process.

Who are the Users of System (System end Users)?

The system end users of the system refer to the people who use computers to perform their jobs,

like desktop operators. Further, end users can be divided into various categories.

22

Very first users are the hands-on users. They actually interact with the system. They are the

people who feed in the input data and get output data. Like person at the booking counter of a

gas authority. This person actually sees the records and registers requests from various customers

for gas cylinders.

Other users are the indirect end users who do not interact with the systems hardware and

software. However, these users benefit from the results of these systems. These types of users

can be managers of organization using that system.

There are third types of users who have management responsibilities for application systems.

These oversee investment in the development or use of the system.

Fourth types of users are senior managers. They are responsible for evaluating organization's

exposure to risk from the systems failure.

Now we know what are systems and what is system analysis and design. So let us take a case in

which we‘ll apply the concepts we have learned in the chapter. The case would be referred to as

and where necessary throughout the website and in this process we will be developing the system

required.

Case Study : Noida Library System

Noida Public Library is the biggest library in Noida. Currently it has about 300 members. A

person who is 18 or above can become a member. There is a membership fee of Rs 400 for a

year. There is a form to be filled in which person fills personal details. These forms are kept in

store for maintaining members‘ records and knowing the membership period.

A member can issue a maximum of three books. He/she has three cards to issue books. Against

each card a member can issue one book from library. Whenever a member wishes to issue a book

and there are spare cards, then the book is issued. Otherwise that request is not entertained. Each

book is to be returned on the specified due date. If a member fails to return a book on the

specified date, a fine of Rs 2 per day after the due return date is charged. If in case a card gets

lost then a duplicate card is issued. Accounts are maintained for the membership fees and money

collected from the fines. There are two librarians for books return and issue transaction.

Approximately 100 members come to library daily to issue and return books.

There are 5000 books available out of which 1000 books are for reference and can not be issued.

Records for the books in the library are maintained. These records contain details about the

publisher, author, subject, language, etc. There are suppliers that supply books to the library.

Library maintains records of these suppliers.

Many reports are also produced. These reports are for details of the books available in the

library, financial details, members‘ details, and supplier‘s details.

23

Currently all functions of the library are done manually. Even the records are maintained on

papers. Now day by day members are increasing. Maintaining manual records is becoming

difficult task. There are other problems also that the library staff is facing. Like in case of issue

of duplicate cards to a member when member or library staff loses the card. It is very difficult to

check the genuinity of the problem.

Sometimes the library staff needs to know about the status of a book as to whether it is issued or

not. So to perform this kind of search is very difficult in a manual system.

Also management requires reports for books issued, books in the library, members, and accounts.

Manually producing the reports is a cumbersome job when there are hundreds and thousands of

records.

Management plans to expand the library, in terms of books, number of members and finally the

revenue generated. It is observed that every month there are at least 50-100 requests for

membership. For the last two months the library has not entertained requests for the new

membership as it was difficult to manage the existing 250 members manually. With the

expansion plans, the management of the library aims to increase its members at the rate of 75 per

month. It also plans to increase the membership fees from 400 to 1000 for yearly and 500 for

half year, in order to provide its members better services, which includes increase in number of

books from 3 to 4.

Due to the problems faced by the library staff and its expansion plans, the management is

planning to have a system that would first eradicate the needs of cards. A system to automate the

functions of record keeping and report generation. And which could help in executing the

different searches in a faster manner. The system to handle the financial details.

24

Applying the concepts studied in the chapter to the case study:

The first thing we studied is systems. In our case study Noida Public Library is our system.

Every system is a set of some functional units that work together to achieve some objective. The

main objective of library system is to provide books to its members without difficulty. Fig 1.4

depicts our library system pictorially.

Our system has many functional units. Books issue and return section, books record unit,

members record unit, accounts, and report generation units are the different functional units of

the library. Each functional unit has its own task. However, each of these work independently to

achieve the overall objective of the library.

Later in the session, we talked about different components and characteristics of the systems.

Data is an important component of any system. Here, data is pertaining to the details of

members, books, accounts, and suppliers. Since people can interact with the system this system

is an open system. The system is mainly concerned with the management of data it is an

information system.

If this system were to be automated as conceived by the management, then role of the system

analyst would be to study the system, its workings, and its existing problems. Also the analyst

needs to provide a solution to the existing problem.

25

Now that the management has decided for an automated system the analyst would perform the

above tasks. As the analyst did the study of the system, the following problems were identified

Maintaining membership cards

Producing reports due to large amount of data

Maintaining accounts

Keeping records for books in library and its members

Performing searches

Now that the analyst has studied the system and identified the problems, it is the responsibility of

the analyst to provide a solution system to the management of the library.

Introduction to Systems: Summary and Review Questions

Summary

A system is a set of interdependent components, organized in a planned manner to

achieve certain objectives.

System interacts with their environment through receiving inputs and producing outputs.

Systems can be decomposed into smaller units called subsystems.

Systems falls into three categories

Physical or Abstract systems

Open or closed system depending upon their interaction with environment.

Man-made such as information systems.

Three levels of information in organization require a special type of information.

Strategic information relates to long-term planning policies and upper management.

Managerial information helps middle management and department heads in policy

implementation and control.

Operational information is daily information needed to operate the business.

Information systems are of many types. Management Information, transaction processing,

and decision support systems are all information systems.

Transaction processing system assist in processing day to day activities of the

organization

Management information systems are decisions oriented. These use transaction data and

other information that is developed internally or outside the organization.

Decision support systems are built for assisting managers who are responsible for making

decisions.

System analysis and design refers to the application of systems approach to problem

solving.

Review Questions

1. Define the term ‗System‘.

26

2. What are the various elements of system?

3. Identify two systems in your surroundings.

4. What is system analysis and design?

5. What are the roles of system analyst?

6. Make a list of traits that a system analyst should have.

7. Will the responsibility of a system analyst vary according to:

(a) Organization size( for example small or large business)?

(b) Type of organization(business, government agency, non-profit organization)?

8. Differentiate between

a) Open and closed system

b) Physical and abstract

9. Main aim of an information system is to process _________.

10. Transaction processing, __________________ , and decision support system are three

types of information system.

11. State true or false

a) Decision support system is for middle level management.

b) Closed systems don't interact with their environment.

c) Transaction processing system handles day-to-day operations of the organization.

d) Management information system deals with strategic information of organization.

e) Problem solving and interpersonal skills are desirable for system analyst.

Software (System Development) life Cycle Models

At the end of this lesson you would be able to know the various stages involved in a system life cycle and

you would be able to understand the various methodologies available for system development.

Introduction to Life Cycle Models

Activities involved in any Life cycle Model

Preliminary Investigation

Determination of System's requirements - Analysis Phase

Design of System

Development of Software

System Testing

Implementation and Maintenance

Error Distribution with Phases

Different Life Cycles Models

Traditional/Waterfall Software Development Model

Advantages and limitations of the Waterfall Model

Prototyping Life Cycle

27

Iterative Enhancement Life Cycle Model

Spiral Life Cycle Model

Object Oriented Methodology

Dynamic System Development Method

Introduction to System Development/Software life cycle models

The trends of increasing technical complexity of the systems, coupled with the need for

repeatable and predictable process methodologies, have driven System Developers to establish

system development models or software development life cycle models.

Nearly three decades ago the operations in an organization used to be limited and so it was

possible to maintain them using manual procedures. But with the growing operations of

organizations, the need to automate the various activities increased, since for manual procedures

it was becoming very difficult, slow and complicated. Like maintaining records for a thousand

plus employees company on papers is definitely a cumbersome job. So, at that time more and

more companies started going for automation.

Since there were a lot of organizations, which were opting for automation, it was felt that some

standard and structural procedure or methodology be introduced in the industry so that the

transition from manual to automated system became easy. The concept of system life cycle came

into existence then. Life cycle model emphasized on the need to follow some structured

approach towards building new or improved system. There were many models suggested. A

waterfall model was among the very first models that came into existence. Later on many other

models like prototype, rapid application development model, etc were also introduced.

System development begins with the recognition of user needs. Then there is a preliminary

investigation stage. It includes evaluation of present system, information gathering, feasibility

study, and request approval. Feasibility study includes technical, economic, legal and operational

feasibility. In economic feasibility cost-benefit analysis is done. After that, there are detailed

design, implementation, testing and maintenance stages.

28

In this session, we'll be learning about various stages that make system's life cycle. In addition,

different life cycles models will be discussed. These include Waterfall model, Prototype model,

Object-Oriented Model, spiral model and Dynamic Systems Development Method (DSDM).

Activities involved Software Development life cycle model

Problem solving in software consists of these activities:

1. Understanding the problem

2. Deciding a plan for a solution

3. Coding the planned solution

4. Testing the actual program

For small problems these activities may not be done explicitly. The start end boundaries of these

activities may not be clearly defined, and not written record of the activities may be kept.

However, for large systems where the problem solving activity may last over a few years. And

where many people are involved in development, performing these activities implicitly without

proper documentation and representation will clearly not work. For any software system of a

non-trival nature, each of the four activities for problem solving listed above has to be done

formally. For large systems, each activity can be extremely complex and methodologies and

precedures are needed to perform it efficiently and correctly. Each of these activities is a major

task for large software projects.

Furthermore, each of the basic activities itself may be so large that it cannot be handled in single

step and must be broken into smaller steps. For example, design of a large software system is

always broken into multiple, distinct design phases, starting from a very high level design

specifying only the components in the system to a detailed design where the logic of the

components is specified. The basic activities or phases to be performed for developing a software

system are:

1. Requirement Analysis / Determination of System's Requirements

2. Design of system

3. Development (coding) of software

4. System Testing

In addition to the activities performed during software development, some activities are

performed after the main development is complete. There is often an installation (also called

implementation) phase, which is concerned with actually installing the system on the client's

computer systems and then testing it. Then, there is software maintenance. Maintenance is an

activity that commences after the software is developed. Software needs to be maintained not

because some of its components "wear out" and need to be replaced, but because there are often

some residual errors remaining in the system which must be removed later as they are

discovered. Furthermore, the software often must be upgraded and enhanced to include more

"features" and provide more services. This also requires modification of the software, Therefore,

maintenance in unavoidable for software systems.

29

In most commercial software developments there are also some activities performed before the

requirement analysis takes place. These can be combined into a feasibility analysis phase. In this

phase the feasibility of the project is analyzed, and a business proposal is put forth with a very

general plan for the project and some cost estimates. For feasibility analysis, some understanding

of the major requirements of the system is essential. Once the business proposal is accepted or

the contract is awarded, the development activities begin starting with the requirements analysis

phase.

Following topics describes the above mentioned phases:

1. Preliminary Investigation

2. Requirement Analysis / Determination of System's Requirements

3. Design of system

4. Development (coding) of software

5. System Testing

6. Software Maintenance

7. Error distribution with phases

Preliminary Investigation

Fig 2.1 shows different stages in the system's life cycle. It initiates with a project request. First

stage is the preliminary analysis. The main aim of preliminary analysis is to identify the problem.

First, need for the new or the enhanced system is established. Only after the recognition of need,

for the proposed system is done then further analysis is possible.

Suppose in an office all leave-applications are processed manually. Now this company is

recruiting many new people every year. So the number of employee in the company has

increased. So manual processing of leave application is becoming very difficult. So the

management is considering the option of automating the leave processing system. If this is the

case, then the system analyst would need to investigate the existing system, find the limitations

present, and finally evaluate whether automating the system would help the organization.

Once the initial investigation is done and the need for new or improved system is established, all

possible alternate solutions are chalked out. All these systems are known as "candidate systems".

All the candidate systems are then weighed and the best alternative of all these is selected as the

solution system, which is termed as the "proposed system". The proposed system is evaluated for

its feasibility. Feasibility for a system means whether it is practical and beneficial to build that

system.

Feasibility is evaluated from developer and customer's point of view. Developer sees whether

they have the required technology or manpower to build the new system. Is building the new

system really going to benefit the customer. Does the customer have the required money to build

that type of a system? All these issues are covered in the feasibility study of the system. The

30

feasibility of the system is evaluated on the three main issues: technical, economical, and

operational. Another issue in this regard is the legal feasibility of the project.

1. Technical feasibility: Can the development of the proposed system be done with current

equipment, existing software technology, and available personnel? Does it require new

technology?

2. Economic feasibility: Are there sufficient benefits in creating the system to make the

costs acceptable? An important outcome of the economic feasibility study is the cost

benefit analysis.

3. Legal feasibility: It checks if there are any legal hassle in developing the system.

4. Operational feasibility: Will the system be used if it is developed and implemented? Will

there be resistance from users that will undermine the possible application benefits?

The result of the feasibility study is a formal document, a report detailing the nature and scope of

the proposed solution. It consists of the following:

Statement of the problem

Details of findings

Findings and recommendations in concise form

Once the feasibility study is done then the project is approved or disapproved according to the

results of the study. If the project seems feasible and desirable then the project is finally

approved otherwise no further work is done on it.

31

Determination of System's requirements: Analysis phase in SDLC

Requirements Analysis is done in order to understand the problem for which the software system

is to solve. For example, the problem could be automating an existing manual process, or

developing a completely new automated system, or a combination of the two. For large systems

which have a large number of features, and that need to perform many different tasks,

understanding the requirements of the system is a major task. The emphasis in requirements

Analysis is on identifying what is needed from the system and not how the system will achieve it

goals. This task is complicated by the fact that there are often at least two parties involved in

software development - a client and a developer. The developer usually does not understand the

client's problem domain, and the client often does not understand the issues involved in software

systems. This causes a communication gap, which has to be adequately bridged during

requirements Analysis.

In most software projects, the requirement phase ends with a document describing all the

requirements. In other words, the goal of the requirement specification phase is to produce the

software requirement specification document. The person responsible for the requirement

analysis is often called the analyst. There are two major activities in this phase - problem

understanding or analysis and requirement specification in problem analysis; the analyst has to

understand the problem and its context. Such analysis typically requires a thorough

understanding of the existing system, the parts of which must be automated.

Once the problem is analyzed and the essentials understood, the requirements must be specified

in the requirement specification document. For requirement specification in the form of

document, some specification language has to be selected (example: English, regular

expressions, tables, or a combination of these). The requirements documents must specify all

functional and performance requirements, the formats of inputs, outputs and any required

standards, and all design constraints that exits due to political, economic environmental, and

security reasons. The phase ends with validation of requirements specified in the document. The

basic purpose of validation is to make sure that the requirements specified in the document,

actually reflect the actual requirements or needs, and that all requirements are specified.

Validation is often done through requirement review, in which a group of people including

representatives of the client, critically review the requirements specification.

Software Requirement or Role of Software Requirement Specification (SRS)

IEEE (Institute of Electrical and Electronics Engineering) defines as,

1. A condition of capability needed by a user to solve a problem or achieve an objective;

2. A condition or capability that must be met or possessed by a system to satisfy a contract,

standard, specification, or other formally imposed document.

32

Note that in software requirements we are dealing with the requirements of the proposed system,

that is, the capabilities that system, which is yet to be developed, should have. It is because we

are dealing with specifying a system that does not exist in any form that the problem of

requirements becomes complicated. Regardless of how the requirements phase proceeds, the

Software Requirement Specification (SRS) is a document that completely describes what the

proposed software should do without describing how the system will do it?. The basic goal of the

requirement phase is to produce the Software Requirement Specification (SRS), which describes

the complete external behavior of the proposed software.

System/Software Design Phase in SDLC

The purpose of the design phase is to plan a solution of the problem specified by the requirement

document. This phase is the first step in moving from problem domain to the solution domain.

The design of a system is perhaps the most critical factor affecting the quality of the software,

and has a major impact on the later phases, particularly testing and maintenance. The output of

this phase is the design document. This document is similar to a blue print or plan for the

solution, and is used later during implementation, testing and maintenance.

The design activity is often divided into two separate phase-system design and detailed design.

System design, which is sometimes also called top-level design, aims to identify the modules that

should be in the system, the specifications of these modules, and how they interact with each

other to produce the desired results. At the end of system design all the major data structures, file

formats, output formats, as well as the major modules in the system and their specifications are

decided.

During detailed design the internal logic of each of the modules specified in system design is

decided. During this phase further details of the data structures and algorithmic design of each of

the modules is specified. The logic of a module is usually specified in a high-level design

description language, which is independent of the target language in which the software will

eventually be implemented. In system design the focus is on identifying the modules, whereas

during detailed design the focus is on designing the logic for each of the modules. In other

words, in system design the attention is on what components are needed, while in detailed design

how the components can be implemented in software is the issue.

During the design phase, often two separate documents are produced. One for the system design

and one for the detailed design. Together, these documents completely specify the design of the

system. That is they specify the different modules in the system and internal logic of each of the

modules.

A design methodology is a systematic approach to creating a design by application of set of

techniques and guidelines. Most methodologies focus on system design. The two basic principles

used in any design methodology are problem partitioning and abstraction. A large system cannot

be handled as a whole, and so for design it is partitioned into smaller systems. Abstraction is a

concept related to problem partitioning. When partitioning is used during design, the design

33

activity focuses on one part of the system at a time. Since the part being designed interacts with

other parts of the system, a clear understanding of the interaction is essential for properly

designing the part. For this, abstraction is used. An abstraction of a system or a part defines the

overall behavior of the system at an abstract level without giving the internal details.

While working with the part of a system, a designer needs to understand only the abstractions of

the other parts with which the part being designed interacts. The use of abstraction allows the

designer to practice the "divide and conquer" technique effectively by focusing one part at a

time, without worrying about the details of other parts.

Like every other phase, the design phase ends with verification of the design. If the design is not

specified in some executable language, the verification has to be done by evaluating the design

documents. One way of doing this is thorough reviews. Typically, at least two design reviews are

held-one for the system design and one for the detailed and one for the detailed design.

Development of Software - Coding Stage/Phase in SDLC

Once the design is complete, most of the major decisions about the system have been made. The

goal of the coding phase is to translate the design of the system into code in a given

programming language. For a given design, the aim of this phase is to implement the design in

the best possible manner. The coding phase affects both testing and maintenance profoundly. A

well written code reduces the testing and maintenance effort. Since the testing and maintenance

cost of software are much higher than the coding cost, the goal of coding should be to reduce the

testing and maintenance effort. Hence, during coding the focus should be on developing

programs that are easy to write. Simplicity and clarity should be strived for, during the coding

phase.

An important concept that helps the understandability of programs is structured programming.

The goal of structured programming is to arrange the control flow in the program. That is,

program text should be organized as a sequence of statements, and during execution, the

statements are executed in the sequence in the program.

For structured programming, a few single-entry-single-exit constructs should be used. These

constructs includes selection (if-then-else), and iteration (while - do, repeat - until etc). With

these constructs it is possible to construct a program as sequence of single - entry - single - exit

constructs. There are many methods available for verifying the code. Some methods are static in

nature that is, that is they do not involve execution of the code. Examples of such methods are

data flow analysis, code reading, code reviews, testing (a method that involves executing the

code, which is used very heavily). In the coding phase, the entire system is not tested together.

Rather, the different modules are tested separately. This testing of modules is called "unit

testing". Consequently, this phase is often referred to as "coding and unit testing". The output of

this phase is the verified and unit tested code of the different modules.

34

System Testing

Testing is the major quality control measure employed during software development. Its basic

function is to detect errors in the software. During requirement analysis and design, the output is

a document that is usually textual and non-executable. After the coding phase, computer

programs are available that can be executed for testing phases. This implies that testing not only

has to uncover errors introduced during coding, but also errors introduced during the previous

phases. Thus, the goal of testing is to uncover requirement, design or coding errors in the

programs.

Consequently, different levels of testing are employed. The starting point of testing is unit

testing. In this a module is tested separately and is often performed by the coder himself

simultaneously with the coding of the module. The purpose is to execute the different parts of the

module code to detect coding errors. After this the modules are gradually integrated into

subsystem, which are then integrated themselves eventually form the entire system. During

integration of modules, integration testing is performed. The goal of this testing is to detect

design errors, while focusing on testing the interconnection between modules. After the system is

put together, system testing is performed. Here the system is tested against tech system

requirements to see if all the requirements are met and the system performs as specified by the

requirements. Finally, acceptance testing is performed to demonstrate to the client, on the real

life data of the client, the separation of the system.

For testing to be successful, proper selection of test cases is essential. There are two different

approaches to selecting test cases-functional testing and structural testing. In functional testing

the software for the module to be tested is treated as black box, and then test cases are decided

based on the specifications of the system or module. For this reason, this form of testing is also

called "black box testing". The focus is on testing the external behavior of the system. In

structural testing the test cases are decided based on the logic of the module to be tested.

Structural testing is sometimes called "glass box testing". Structural testing is used for lower

levels of testing and functional testing is used for higher levels.

Testing is an extremely critical and time-consuming activity. It requires proper planning of the

overall testing process. Frequently the testing process starts with the test plan. This plan

identifies all the testing related activities that must be performed and specifies the schedule,

allocates the resources, and specify guidelines for testing. The test plan specifies manner in

which the modules will integrate together. Then for different test units, a test case specification

document is produced, which lists all the different test cases, together with the expected outputs,

that will be used for testing. During the testing of the unit, the specified test cases are executed

and actual result is compared with the expected output. The final output of the testing phases is

to the text report and the error report, or set of such reports (one of each unit is tested). Each test

report contains the set of such test cases and the result of executing the code with these test cases

The error report describes the errors encountered and action taken to remove those errors.

35

System testing is explained further in the chapter entitled "Testing and Quality Assurance"

SDLC - Implementation and Maintenance in Software Life Cycle

Maintenance includes all the activity after the installation of software that is performed to keep

the system operational. As we have mentioned earlier, software often has design faults. The two

major forms of maintenance activities are adaptive maintenance and corrective maintenance.

It is generally agreed that for large systems, removing all the faults before delivery is extremely

difficult and faults will be discovered long after the system is installed. As these faults are

detected, they have to be removed. Maintenance activities related to fixing of errors fall under

corrective maintenance.

Removing errors is one of the activities of maintenance. Maintenance also needed due to a

change in the environment or the requirements of the system. The introduction of a software

system affects the work environment. This change in environment often changes what is desired

from the system. Furthermore, often after the system is installed and the users have had a chance

to work with it for sometime, requirements that are not identified during requirement analysis

phase will be uncovered. This occurs, since the experience with the software helps the user to

define the needs more precisely. There might also be changes in the input data, the system

environment and output formats. All these require modification of the software. The maintenance

activities related to such modification fall under adaptive maintenance.

Maintenance work is based on existing software, as compared to development work, which

creates new software. Consequently maintenance resolves around understanding the existing

software and spares most of their time trying to understand the software that they have to

modify. Understanding the software involves not only understanding the code, but also the

related documents. During the modification of the software, the effects of the change have to be

clearly understood by the maintainer since introducing undesired side effects in the system

during modification is easier.

To test whether those aspects in the system that are not supposed to be modified are operating as

they were before modification, regression testing is done. Regression testing involves executing

old test cases to test that no new errors have been introduced. Thus, maintenance involves

understanding the existing software (code and related documents), understanding the effects of

change, making the changes - both to the code and documents, testing the new parts (changes),

and resetting of the old parts that were not changed.

Since often during development, needs of the maintainers are not kept in mind, little support

documents are produced during development to aid the maintainer. The complexity of the

36

maintenance task is coupled with the neglect of maintenance concerns during development

which makes maintenance the most cost effective activity in the life of a software product.

Error Distribution with Phases in Software Development Life Cycles

A typical software product may take months to a few years for development, and is in operation

for five to twenty years before it is withdrawn. For software, the cost of development is the

incurred during requirement analysis, design, coding and testing. Therefore, the development

cost is the total cost incurred before the product delivery. The cost of maintenance is the cost of

modifying the software due to residual faults in the software, for enhancing or for updating the

software. This cost is spread over the operational years of the software. Software engineers

generally agree that the total cost of maintenance is more than the cost of development of

software. The ratio of development to maintenance cost has been variously suggested as 40/60,

30/70 or even lower. However, it is generally accepted that the cost of maintenance is likely to

be higher than the development cost, and are often not at all concerned with the maintenance.

Since maintenance depends critically on the software characteristics that are decided during

development, maintenance cost can be reduced if maintenance concerns are kept in forefront

during development. One of the reasons why this is often not done is that the development cost is

done by the developers while maintenance is often done by the users. Hence, the developers do

not have much incentive for increasing the development effort in order to reduce the

maintenance cost. However, for reduction in overall cost of software, it is imperative that the

software be developed so the maintenance is easy.

The development cost, a typical distribution of effort with the different phases is

Requirement - 10%

Design - 20%

Coding - 20%

Testing - 50%

The exact number will differ with organization and the type of the project. There are some

observation we can make from the data given above. The first is that the goal of design and

coding should reduce the cost of design and coding, but should be to reduce the cost of testing

and maintenance, at the expense of increasing design and coding cost. Both testing and

maintenance depend heavily in the design and coding of the software. And these costs can be

considerably reduced if the software is designed and coded to make testing and maintenance

easier. Therefore, during design and implementation, the issues in our minds should be "can the

design be easily tested", and "can it be easily modified". These require alternate designs and may

increase the cost of the design and coding. But this additional costs pay dividends in the later

phases.

37

Error Distribution

The notion that programming is the central of activity during software development is largely

because normally programming has been considered to be difficult task and sometimes an "art".

Another consequence of this kind of thinking is the belief that errors largely occur during

programming, as it is the oldest activity in software development and offers many opportunities

for commiting errors. It is now realized that errors can occur at any stage during development. A

typical distribution of error occurrences by is

Requirement Analysis - 20%

Design - 30%

Coding - 50%

As we can see, errors occur throughout the development process. However the cost of correcting

different phases is not the same and depends on when the error is detected and correceted. As

one old expect, the greater the delay in detecting an error after it occurs, the more expensive it is

to correct it. Error that occur during the requirements phase, if corrected after coding is

completed, can cost many times more than correcting the error during the requirements phase

itself. The reason for this is fairly obvious. If there is an error in the requirements, then the

design and the code will get affected.

To correct the error, the coding that is done would require both the design and the code to be

changed there by increasing the correction. So we should attempt to detect errors in the previous

phase and should not wait until testing to detect errors. This is not often practiced. In reality,

sometimes testing is the sole point where errors are detected. Besides the cost factor, reliance on

testing as the primary source for error detection, due to the limitations of testing, will also result

in unreliable software. Error detection and correction should be a continous proces that is done

throughout software development. In terms of the development phases what this means is that we

should try to validate each phase before starting with the next.

Different types of Software Development Life Cycle Models (SDLC)

A Software Development Life Cycle Model is a set of activities together with an ordering

relationship between activities which if performed in a manner that satisfies the ordering

relationship that will produce desired product. Software Development Life Cycle Model is an

abstract representation of a development process.

In a software development effort the goal is to produce high quality software. The development

process is, therefore, the sequence of activities that will produce such software. A software

development life cycle model is broken down into distinct activities. A software development

life cycle model specifies how these activities are organized in the entire software development

effort. We discuss each software development life cycle model in detail.

38

1. Waterfall Software Development Life Cycle Model

2. Prototyping Software Development Life Cycle Model

3. Iterative Enhacement Model

4. The Spiral Model

5. Object Oriented Methodology

6. Dynamic System Development Method

Waterfall Software Development Life Cycle Model

The simplest software development life cycle model is the waterfall model, which states that the

phases are organized in a linear order. A project begins with feasibility analysis. On the

successful demonstration of the feasibility analysis, the requirements analysis and project

planning begins.

The design starts after the requirements analysis is done. And coding begins after the design is

done. Once the programming is completed, the code is integrated and testing is done. On

succeeful completion of testing, the system is installed. After this the regular operation and

maintenance of the system takes place. The following figure demonstrates the steps involved in

waterfall life cycle model.

The Waterfall Software Life Cycle Model

With the waterfall model, the activities performed in a software development project are

requirements analysis, project planning, system design, detailed design, coding and unit testing,

system integration and testing. Linear ordering of activities has some important consequences.

First, to clearly identify the end of a phase and beginning of the others. Some certification

mechanism has to be employed at the end of each phase. This is usually done by some

verification and validation. Validation means confirming the output of a phase is consistent with

its input (which is the output of the previous phase) and that the output of the phase is consistent

with overall requirements of the system.

39

The consequences of the need of certification is that each phase must have some defined output

that can be evaluated and certified. Therefore, when the activities of a phase are completed, there

should be an output product of that phase and the goal of a phase is to produce this product. The

outputs of the earlier phases are often called intermediate products or design document. For the

coding phase, the output is the code. From this point of view, the output of a software project is

to justify the final program along with the use of documentation with the requirements

document, design document, project plan, test plan and test results.

Another implication of the linear ordering of phases is that after each phase is completed and its

outputs are certified, these outputs become the inputs to the next phase and should not be

changed or modified. However, changing requirements cannot be avoided and must be faced.

Since changes performed in the output of one phase affect the later phases, that might have been

performed. These changes have to made in a controlled manner after evaluating the effect of

each change on the project.This brings us to the need for configuration control or configuration

management.

The certified output of a phase that is released for the best phase is called baseline. The

configuration management ensures that any changes to a baseline are made after careful review,

keeping in mind the interests of all parties that are affected by it. There are two basic

assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall

model.

For a successful project resulting in a successful product, all phases listed in the waterfall model

must be performed anyway.

Any different ordering of the phases will result in a less successful software product.

Project Output in a Waterfall Model

As we have seen, the output of a project employing the waterfall model is not just the final

program along with documentation to use it. There are a number of intermediate outputs, which

must be produced in order to produce a successful product.

The set of documents that forms the minimum that should be produced in each project are:

Requirement document

Project plan

System design document

Detailed design document

Test plan and test report

Final code

Software manuals (user manual, installation manual etc.)

Review reports

40

Except for the last one, these are all the outputs of the phases. In order to certify an output

product of a phase before the next phase begins, reviews are often held. Reviews are necessary

especially for the requirements and design phases, since other certification means are frequently

not available. Reviews are formal meeting to uncover deficiencies in a product. The review

reports are the outcome of these reviews.

Advantages and limitations of the waterfall life cycle model

Other Software/System Development Life Cycles

Prototyping Software Development Life Cycle Model

Iterative Enhacement Model

The Spiral Model

Object Oriented Methodology

Dynamic System Development Method

Advantages and limitations of the Waterfall Model

Advantages of Waterfall Life Cycle Models

1. Easy to explain to the user

2. Stages and activities are well defined

3. Helps to plan and schedule the project

4. Verification at each stage ensures early detection of errors / misunderstanding

Limitations of the Waterfall Life Cycle Model

The waterfall model assumes that the requirements of a system can be frozen (i.e. basedline)

before the design begins. This is possible for systems designed to automate an existing manual

system. But for absolutely new system, determining the requirements is difficult, as the user

himself does not know the requirements. Therefore, having unchanging (or changing only a few)

requirements is unrealistic for such project.

Freezing the requirements usually requires choosing the hardware (since it forms a part of the

requirement specification). A large project might take a few years to complete. If the hardware is

selected early, then due to the speed at which hardware technology is changing, it is quite likely

that the final software will employ a hardware technology that is on the verge of becoming

obsolete. This is clearly not desirable for such expensive software.

The waterfall model stipulates that the requirements should be completely specified before the

rest of the development can proceed. In some situations it might be desirable to first develop a

part of the system completely, an then later enhance the system in phase. This is often done for

software products that are developed not necessarily for a client (where the client plays an

41

important role in requirement specification), but for general marketing, in which the

requirements are likely to be determined largely by developers.

Other Software/System Development Life Cycles

Waterfall Software Development Life Cycle Model

Prototyping Software Development Life Cycle Model

Iterative Enhacement Model

The Spiral Model

Object Oriented Methodology

Dynamic System Development Method

Prototyping Software Life Cycle Model

The goal of prototyping based development is to counter the first two limitations of the waterfall

model discussed earlier. The basic idea here is that instead of freezing the requirements before a

design or coding can proceed, a throwaway prototype is built to understand the requirements.

This prototype is developed based on the currently known requirements. Development of the

prototype obviously undergoes design, coding and testing. But each of these phases is not done

very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the

system, since the interactions with prototype can enable the client to better understand the

requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual

process or existing system to help determining the requirements. In such situations letting the

client "plan" with the prototype provides invaluable and intangible inputs which helps in

determining the requirements for the system. It is also an effective method to demonstrate the

feasibility of a certain approach. This might be needed for novel systems where it is not clear that

constraints can be met or that algorithms can be developed to implement the requirements. The

process model of the prototyping approach is shown in the figure below.

Prototyping Model

42

The basic reason for little common use of prototyping is the cost involved in this built-it-twice

approach. However, some argue that prototyping need not be very costly and can actually reduce

the overall development cost. The prototype are usually not complete systems and many of the

details are not built in the prototype. The goal is to provide a system with overall functionality.

In addition, the cost of testing and writing detailed documents are reduced. These factors helps to

reduce the cost of developing the prototype. On the other hand, the experience of developing the

prototype will very useful for developers when developing the final system. This experience

helps to reduce the cost of development of the final system and results in a more reliable and

better designed system.

Advantages of Prototyping

1. Users are actively involved in the development

2. It provides a better system to users, as users have natural tendency to change their mind

in specifying requirements and this method of developing systems supports this user

tendency.

3. Since in this methodology a working model of the system is provided, the users get a

better understanding of the system being developed.

4. Errors can be detected much earlier as the system is mode side by side.

5. Quicker user feedback is available leading to better solutions.

Disadvantages

1. Leads to implementing and then repairing way of building systems.

2. Practically, this methodology may increase the complexity of the system as scope of the

system may expand beyond original plans.

Other Software/System Development Life Cycles

Waterfall Software Development Life Cycle Model

Iterative Enhacement Model

The Spiral Model

Object Oriented Methodology

Dynamic System Development Method

Iterative Enhancement Life Cycle Model

The iterative enhancement life cycle model counters the third limitation of the waterfall model

and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is

that the software should be developed in increments, where each increment adds some functional

capability to the system until the full system is implemented. At each step extensions and design

modifications can be made. An advantage of this approach is that it can result in better testing,

since testing each increment is likely to be easier than testing entire system like in the waterfall

43

model. Furthermore, as in prototyping, the increments provides feedback to the client which is

useful for determining the final requirements of the system.

In the first step of iterative enhancement model, a simple initial implementation is done for a

subset of the overall problem. This subset is the one that contains some of the key aspects of the

problem which are easy to understand and implement, and which forms a useful and usable

system. A project control list is created which contains, in an order, all the tasks that must be

performed to obtain the final implementation. This project control list gives an idea of how far

the project is at any given step from the final system.

Each step consists of removing the next step from the list. Designing the implementation for the

selected task, coding and testing the implementation, and performing an analysis of the partial

system obtained after this step and updating the list as a result of the analysis. These three phases

are called the design phase, implementation phase and analysis phase. The process is iterated

until the project control list is empty, at the time the final implementation of the system will be

available. The process involved in iterative enhancement model is shown in the figure below.

The Iterative Enhancement Model

The project control list guides the iteration steps and keeps track of all tasks that must be done.

The tasks in the list can be include redesign of defective components found during analysis. Each

entry in that list is a task that should be performed in one step of the iterative enhancement

process, and should be simple enough to be completely understood. Selecting tasks in this

manner will minimize the chances of errors and reduce the redesign work.

Other Software/System Development Life Cycles

Waterfall Software Development Life Cycle Model

Prototyping Software Development Life Cycle Model

The Spiral Model

Object Oriented Methodology

Dynamic System Development Method

44

The Spiral Life Cycle Model

This is a recent model that has been proposed by Boehm. As the name suggests, the activities in this model

can be organized like a spiral. The spiral has many cycles. The radial dimension represents the cumulative

cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress

made in completing each cycle of the spiral. The structure of the spiral model is shown in the figure given

below. Each cycle in the spiral begins with the identification of objectives for that cycle and the different

alternatives are possible for achieving the objectives and the imposed constraints.

The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives

and constraints. This will also involve identifying uncertainties and risks involved. The next step is to

develop strategies that resolve the uncertainties and risks. This step may involve activities such as

benchmarking, simulation and prototyping. Next, the software is developed by keeping in mind the risks.

Finally the next stage is planned.

The next step is determined by remaining risks. For example, its performance or user-interface risks are

considered more important than the program development risks. The next step may be evolutionary

development that involves developing a more detailed prototype for resolving the risks. On the other hand,

if the program development risks dominate and previous prototypes have resolved all the user-interface and

45

performance risks; the next step will follow the basic waterfall approach.

The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented,

prototype-oriented, simulation-oriented or some other approach. An important feature of the model is that

each cycle of the spiral is completed by a review, which covers all the products developed during that cycle,

including plans for the next cycle. The spiral model works for developed as well as enhancement projects.

Spiral Model Description

The development spiral consists of four quadrants as shown in the figure above

Quadrant 1: Determine objectives, alternatives, and constraints.

Quadrant 2: Evaluate alternatives, identify, resolve risks.

Quadrant 3: Develop, verify, next-level product.

Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable

to systems, hardware, and training, for example. To better understand the scope of each spiral development

quadrant, let‘s briefly address each one.

Quadrant 1: Determine Objectives, Alternatives, and Constraints

Activities performed in this quadrant include:

1. Establish an understanding of the system or product objectives—namely performance, functionality,

and ability to accommodate change.

2. Investigate implementation alternatives—namely design, reuse, procure, and procure/ modify

3. Investigate constraints imposed on the alternatives—namely technology, cost, schedule, support,

and risk. Once the system or product‘s objectives, alternatives, and constraints are understood,

Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks

Engineering activities performed in this quadrant select an alternative approach that best satisfies technical,

technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each

alternative is investigated and prototyped to reduce the risk associated with the development decisions.

Boehm describes these activities as follows:

. . . This may involve prototyping, simulation, benchmarking, reference checking, administering user

questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.

The outcome of the evaluation determines the next course of action. If critical operational and/or technical

46

issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more

detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if

the alternative chosen is ―operationally useful and robust enough to serve as a low-risk base for future

product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes

going toward the right (hand side of the graphic) . . . the option of writing specifications would be addressed

but not exercised.‖ This brings us to Quadrant 3.

Quadrant 3: Develop, Verify, Next-Level Product

If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to

develop, verify, next-level product are performed. As a result, the basic ―waterfall‖ approach may be

employed—meaning concept of operations, design, development, integration, and test of the next system or

product iteration. If appropriate, incremental development approaches may also be applicable.

Quadrant 4: Plan Next Phases

The spiral development model has one characteristic that is common to all models—the need for advanced

technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the

model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of

development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews

plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral.

Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant

paths and decision considerations.

Other Software/System Development Life Cycles

Waterfall Software Development Life Cycle Model

Prototyping Software Development Life Cycle Model

Iterative Enhacement Model

Object Oriented Methodology

Dynamic System Development Method

Object Oriented Methodology Life Cycle Model

We live in a world of objects. These objects exist in nature, in man-made entities, in business,

and in the products that we use. They can be categorized, described, organized, combined,

manipulated and created. Therefore, an object-oriented view has come into picture for creation of

computer software. An object-oriented approach to the development of software was proposed in

late 1960s.

47

Object-Oriented development requires that object-oriented techniques be used during the

analysis, and implementation of the system. This methodology asks the analyst to determine

what the objects of the system are, how they behave over time or in response to events, and what

responsibilities and relationships an object has to other objects. Object-oriented analysis has the

analyst look at all the objects in a system, their commonalties, difference, and how the system

needs to manipulate the objects.

Object Oriented Process

The Object Oriented Methodology of Building Systems takes the objects as the basis. For this,

first the system to be developed is observed and analyzed and the requirements are defined as in

any other method of system development. Once this is done, the objects in the required system

are identified. For example in case of a Banking System, a customer is an object, a chequebook

is an object, and even an account is an object.

In simple terms, Object Modeling is based on identifying the objects in a system and their

interrelationships. Once this is done, the coding of the system is done. Object Modeling is

somewhat similar to the traditional approach of system designing, in that it also follows a

sequential process of system designing but with a different approach. The basic steps of system

designing using Object Modeling may be listed as:

System Analysis

System Design

Object Design

Implementation

System Analysis

As in any other system development model, system analysis is the first phase of development in

case of Object Modeling too. In this phase, the developer interacts with the user of the system to

find out the user requirements and analyses the system to understand the functioning.

Based on this system study, the analyst prepares a model of the desired system. This model is

purely based on what the system is required to do. At this stage the implementation details are

not taken care of. Only the model of the system is prepared based on the idea that the system is

made up of a set of interacting objects. The important elements of the system are emphasized.

System Design

System Design is the next development stage where the overall architecture of the desired system

is decided. The system is organized as a set of sub systems interacting with each other. While

designing the system as a set of interacting subsystems, the analyst takes care of specifications as

observed in system analysis as well as what is required out of the new system by the end user.

48

As the basic philosophy of Object-Oriented method of system analysis is to perceive the system

as a set of interacting objects, a bigger system may also be seen as a set of interacting smaller

subsystems that in turn are composed of a set of interacting objects. While designing the system,

the stress lies on the objects comprising the system and not on the processes being carried out in

the system as in the case of traditional Waterfall Model where the processes form the important

part of the system.

Object Design

In this phase, the details of the system analysis and system design are implemented. The Objects

identified in the system design phase are designed. Here the implementation of these objects is

decided as the data structures get defined and also the interrelationships between the objects are

defined.

Let us here deviate slightly from the design process and understand first a few important terms

used in the Object-Oriented Modeling.

As already discussed, Object Oriented Philosophy is very much similar to real world and hence

is gaining popularity as the systems here are seen as a set of interacting objects as in the real

world. To implement this concept, the process-based structural programming is not used; instead

objects are created using data structures. Just as every programming language provides various

data types and various variables of that type can be created, similarly, in case of objects certain

data types are predefined.

For example, we can define a data type called pen and then create and use several objects of this

data type. This concept is known as creating a class.

Class: A class is a collection of similar objects. It is a template where certain basic characteristics

of a set of objects are defined. The class defines the basic attributes and the operations of the

objects of that type. Defining a class does not define any object, but it only creates a template.

For objects to be actually created instances of the class are created as per the requirement of the

case.

Abstraction: Classes are built on the basis of abstraction, where a set of similar objects are

observed and their common characteristics are listed. Of all these, the characteristics of concern

to the system under observation are picked up and the class definition is made. The attributes of

no concern to the system are left out. This is known as abstraction.

The abstraction of an object varies according to its application. For instance, while defining a

pen class for a stationery shop, the attributes of concern might be the pen color, ink color, pen

type etc., whereas a pen class for a manufacturing firm would be containing the other dimensions

of the pen like its diameter, its shape and size etc.

Inheritance: Inheritance is another important concept in this regard. This concept is used to apply

the idea of reusability of the objects. A new type of class can be defined using a similar existing

49

class with a few new features. For instance, a class vehicle can be defined with the basic

functionality of any vehicle and a new class called car can be derived out of it with a few

modifications. This would save the developers time and effort as the classes already existing are

reused without much change.

Coming back to our development process, in the Object Designing phase of the Development

process, the designer decides onto the classes in the system based on these concepts. The

designer also decides on whether the classes need to be created from scratch or any existing

classes can be used as it is or new classes can be inherited from them.

Implementation

During this phase, the class objects and the interrelationships of these classes are translated and

actually coded using the programming language decided upon. The databases are made and the

complete system is given a functional shape.

The complete OO methodology revolves around the objects identified in the system. When

observed closely, every object exhibits some characteristics and behavior. The objects recognize

and respond to certain events. For example, considering a Window on the screen as an object, the

size of the window gets changed when resize button of the window is clicked.

Here the clicking of the button is an event to which the window responds by changing its state

from the old size to the new size. While developing systems based on this approach, the analyst

makes use of certain models to analyze and depict these objects. The methodology supports and

uses three basic Models:

Object Model - This model describes the objects in a system and their interrelationships.

This model observes all the objects as static and does not pay any attention to their

dynamic nature.

Dynamic Model - This model depicts the dynamic aspects of the system. It portrays the

changes occurring in the states of various objects with the events that might occur in the

system.

Functional Model - This model basically describes the data transformations of the

system. This describes the flow of data and the changes that occur to the data throughout

the system.

While the Object Model is most important of all as it describes the basic element of the system,

the objects, all the three models together describe the complete functional system.

As compared to the conventional system development techniques, OO modeling provides many

benefits. Among other benefits, there are all the benefits of using the Object Orientation. Some

of these are:

Reusability - The classes once defined can easily be used by other applications. This is

achieved by defining classes and putting them into a library of classes where all the

50

classes are maintained for future use. Whenever a new class is needed the programmer

looks into the library of classes and if it is available, it can be picked up directly from

there.

Inheritance - The concept of inheritance helps the programmer use the existing code in

another way, where making small additions to the existing classes can quickly create new

classes.

Programmer has to spend less time and effort and can concentrate on other aspects of the

system due to the reusability feature of the methodology.

Data Hiding - Encapsulation is a technique that allows the programmer to hide the

internal functioning of the objects from the users of the objects. Encapsulation separates

the internal functioning of the object from the external functioning thus providing the

user flexibility to change the external behaviour of the object making the programmer

code safe against the changes made by the user.

The systems designed using this approach are closer to the real world as the real world

functioning of the system is directly mapped into the system designed using this

approach.

Advantages of Object Oriented Methodology

Object Oriented Methodology closely represents the problem domain. Because of this, it

is easier to produce and understand designs.

The objects in the system are immune to requirement changes. Therefore, allows changes

more easily.

Object Oriented Methodology designs encourage more re-use. New applications can use

the existing modules, thereby reduces the development cost and cycle time.

Object Oriented Methodology approach is more natural. It provides nice structures for

thinking and abstracting and leads to modular design.

Dynamic System Development Method (DSDM)

Dynamic System Development Method is another approach to system development, which, as

the name suggests, develops the system dynamically. This methodology is independent of tools,

in that it can be used with both structured analysis and design approach or object-oriented

approach.

The Dynamic System Development Method (DSDM) is dynamic as it is a Rapid Application

Development method that uses incremental prototyping. This method is particularly useful for

the systems to be developed in short time span and where the requirements cannot be frozen at

the start of the application building. Whatever requirements are known at a time, design for them

is prepared and design is developed and incorporated into system. In Dynamic System

Development Method (DSDM), analysis, design and development phase can overlap. Like at one

time some people will be working on some new requirements while some will be developing

something for the system. In Dynamic System Development Method (DSDM), requirements

evolve with time.

51

Dynamic System Development Method (DSDM) has a five-phase life cycle as given the

following figure

Feasibility study

In this phase the problem is defined and the technical feasibility of the desired application is

verified. Apart from these routine tasks, it is also checked whether the application is suitable for

Rapid Application Development (RAD) approach or not. Only if the RAD is found as a justified

approach for the desired system, the development continues.

Business study

In this phase the overall business study of the desired system is done. The business requirements

are specified at a high level and the information requirements out of the system are identified.

Once this is done, the basic architectural framework of the desired system is prepared.

The systems designed using Rapid Application Development (RAD) should be highly

maintainable, as they are based on the incremental development process. The maintainability

level of the system is also identified here so as to set the standards for quality control activities

throughout the development process.

Functional Model Iteration

This is one of the two iterative phases of the life cycle. The main focus in this phase is on

building the prototype iteratively and getting it reviewed from the users to bring out the

52

requirements of the desired system. The prototype is improved through demonstration to the

user, taking the feedback and incorporating the changes. This cycle is repeated generally twice or

thrice until a part of functional model is agreed upon. The end product of this phase is a

functional model consisting of analysis model and some software components containing the

major functionality

Design and Build Iteration

This phase stresses upon ensuring that the prototypes are satisfactorily and properly engineered

to suit their operational environment. The software components designed during the functional

modeling are further refined till they achieve a satisfactory standard. The product of this phase is

a tested system ready for implementation.

There is no clear line between these two phases and there may be cases where while some

component has flown from the functional modeling to the design and build modeling while the

other component has not yet been started. The two phases, as a result, may simultaneously

continue.

Implementation

Implementation is the last and final development stage in this methodology. In this phase the

users are trained and the system is actually put into the operational environment. At the end of

this phase, there are four possibilities, as depicted by figure :

Everything was delivered as per the user demand, so no further development required.

A new functional area was discovered, so return to business study phase and repeat the

whole process

A less essential part of the project was missed out due to time constraint and so

development returns to the functional model iteration.

Some non-functional requirement was not satisfied, so development returns to the design

and build iterations phase.

Dynamic System Development Method (DSDM) assumes that all previous steps may be

revisited as part of its iterative approach. Therefore, the current step need be completed only

enough to move to the next step, since it can be finished in a later iteration. This premise is that

the business requirements will probably change anyway as understanding increases, so any

further work would have been wasted.

According to this approach, the time is taken as a constraint i.e. the time is fixed, resources are

fixed while the requirements are allowed to change. This does not follow the fundamental

assumption of making a perfect system the first time, but provides a usable and useful 80% of the

desired system in 20% of the total development time. This approach has proved to be very useful

under time constraints and varying requirements.

DSDM Model Limitations

53

It is a relatively new model. It is not very common. So it is difficult to understand.

DSDM Model Advantages

Active user participation throughout the life of the project and iterative nature of

development improves quality of the product.

DSDM ensures rapid deliveries.

Both of the above factors result in reduced project costs

54

CHAPTER THREE

Preliminary Analysis

The main objectives of preliminary analysis is to identify the customer's needs, evaluate system

concept for feasibility, perform economic and technical analysis, perform cost benefit analysis

and create system definition that forms the foundation for all subsequent engineering works.

There should be enough expertise available for hardware and software for doing analysis.

While performing analysis, the following questions arise.

How much time should be spent on it?

As such, there are no rules or formulas available to decide on this. However, size,

complexity, application field, end-use, contractual obligation are few parameters on

which it should be decided.

Other major question that arises is who should do it.

Well an experienced well-trained analyst should do it. For large project, there can be an

analysis team.

After the preliminary analysis, the analyst should report the findings to management, with

recommendations outlining the acceptance or rejection of the proposal.

Request Clarification

Feasibility Study

Technical Feasibility

Economic Feasibility

Cost Benefit Analysis

Operational Feasibility

Legal Feasibility

Request Approval

Estimation

Lines of code (LOC)

FP Estimation

Empirical Estimation

COCOMO

Case study : Library Management system

Request Clarification / Software Requirement Specification (SRS)

55

Software Requirement Specification (SRS) is the beginning point of the software development

activity. Software requirement is one such area to which little importance was attached in the

early days of software development, as the emphasis was on coding and design. The main

assumption was that the developers understood the problem clearly when it was explained to

them, generally informally.

As system grew more complex, it became evident that the goals of the entire system could not be

easily comprehended. Therefore, the need for a more rigorous requirement analysis phase arose.

Now, for large systems, requirements analysis is perhaps the most difficult and intractable

activity; it is also very error prone. Many software engineers believe that the software

engineering discipline is the weakest in this critical area. Some of the difficulties is the scope of

this phase. The software project is initiated by clients needs. These needs are in the minds of

various people in the client organization.

The requirement analyst has to identify the requirements by talking to these people and

understanding their needs. In situations where the software is to automate a currently manual

process, many of the needs can be understood by observing the current practice. But no such

methods exists for such systems for which manual processes do not exist (example; software for

a missile control system) or for a "new features", which are frequently added when automating

an existing manual process.

Thus, identifying requirements necessarily involves specifying what some people have in their

minds (or what will come to their minds when they visualize it). As the information in their

minds is by very nature not formally stated or organized, the input to the software requirement

specification phase is inherently informal and imprecise, and is likely to be incomplete. When

inputs from multiple people are to be gathered, as is more often the case, these inputs are likely

to be inconsistent as well. The software requirement specification phase translates the ideas in

the minds of the client (the input), into a set of formal documents (the output of the requirement

phase). Thus, the output of the phase is a set of formally specified requirements, which hopefully

are complete and consistent.

Software Requirement (or) Role of Software Requirement Specification

IEEE (Institute of Electrical and Electronics Engineers) defines as,

1. A condition of capability needed by a user to solve a problem or achieve an objective

2. A condition or capability that must be met or possessed by a system to satisfy a contract,

standard, specification or other formally imposed document.

Note that in software requirements we are dealing with the requirements of the proposed system,

that is, capabilities that system, which is yet to be developed, should have. It is because we are

dealing with specifying a system that does not exist in any form that the problem of requirements

becomes complicated. Regardless of how the requirements phase proceeds, the Software

56

Requirement Specification (SRS) is a document that completely describes what the proposed

software should do without describing how the system will do it?.

Feasibility Study

A feasibility study is a preliminary study undertaken before the real work of a project starts to

ascertain the likelihood of the project's success. It is an analysis of possible solutions to a

problem and a recommendation on the best solution to use. It involves evaluating how the

solution will fit into the corporation. It, for example, can decide whether an order processing be

carried out by a new system more efficiently than the previous one.

A feasibility study is defined as an evaluation or analysis of the potential impact of a proposed

project or program. A feasibility study is conducted to assist decision-makers in determining

whether or not to implement a particular project or program. The feasibility study is based on

extensive research on both the current practices and the proposed project/program and its impact

on the selected organization operation. The feasibility study will contain extensive data related to

financial and operational impact and will include advantages and disadvantages of both the

current situation and the proposed plan.

Why Prepare Feasibility Studies?

Developing any new business venture is difficult. Taking a project from the initial idea through

the operational stage is a complex and time-consuming effort. Most ideas, whether from a

cooperative or invest or owned business, do not develop into business operations. If these ideas

make it to the operational stage, most fail within the first 6 months. Before the potential members

invest in a proposed business project, they must determine if it can be economically viable and

then decide if investment advantages outweigh the risks involved.

Many cooperative business projects are quite expensive to conduct. The projects involve

operations that differ from those of the members‘ individual business. Often, cooperative

businesses‘ operations involve risks with which the members are unfamiliar. The study allows

groups to preview potential project outcomes and to decide if they should continue. Although the

costs of conducting a study may seem high, they are relatively minor when compared with the

total project cost. The small initial expenditure on a feasibility study can help to protect larger

capital investments later.

Feasibility studies are useful and valid for many kinds of projects. Evaluations of a new business

venture both from new groups and established businesses, are the most common, but not the only

usage. Studies can help groups decide to expand existing services, build or remodel facilities,

change methods of operation, add new products, or even merge with another business. A

feasibility study assists decision makers whenever they need to consider alternative development

opportunities.

57

Feasibility studies permit planners to outline their ideas on paper before implementing them.

This can reveal errors in project design before their implementation negatively affects the

project. Applying the lessons gained from a feasibility study can significantly lower the project

costs. The study presents the risks and returns associated with the project so the prospective

members can evaluate them. There is no "magic number" or correct rate of return a project needs

to obtain before a group decides to proceed. The acceptable level of return and appropriate risk

rate will vary for individual members depending on their personal situation.

Cooperatives serve the needs and enhance the economic returns of their members, and not

outside investors, so the appropriate economic rate of return for a cooperative project may be

lower than those required by projects of investor-owned firms. Potential members should

evaluate the returns of a cooperative project to see how it would affect the returns of all of their

business operations.

The proposed project usually requires both risk capital from members and debt capital from

banks and other financiers to become operational. Lenders typically require an objective

evaluation of a project prior to investing. A feasibility study conducted by someone without a

vested interest in the project outcome can provide this assessment.

What Is a Feasibility Study?

This analytical tool used during the project planning process shows how a business would

operate under a set of assumptions — the technology used (the facilities, equipment, production

process, etc.) and the financial aspects (capital needs, volume, cost of goods, wages etc.). The

study is the first time in a project development process that the pieces are assembled to see if

they perform together to create a technical and economically feasible concept. The study also

shows the sensitivity of the business to changes in these basic assumptions.

Feasibility studies contain standard technical and financial components, as discussed in more

detail later in this report. The exact appearance of each study varies. This depends on the

industry studied, the critical factors for that project, the methods chosen to conduct the study, and

the budget. Emphasis can be placed on various sections of an individual feasibility study

depending upon the needs of the group for whom the study was prepared. Most studies have

multiple potential uses, so they must be designed to serve everyone‘s needs.

The feasibility study evaluates the project‘s potential for success. The perceived objectivity of

the evaluation is an important factor in the credibility placed on the study by potential investors

and financiers. Also, the creation of the study requires a strong background both in the financial

and technical aspects of the project. For these reasons, outside consultants conduct most studies.

Feasibility studies for a cooperative are similar to those for other businesses, with one exception.

Cooperative members use it to be successful in enhancing their personal businesses, so a study

conducted for a cooperative must address how the project will impact members as individuals in

addition to how it will affect the cooperative as a whole.

58

The feasibility study is conducted to assist the decision-makers in making the decision that will

be in the best interest of the school food service operation. The extensive research, conducted in

a non-biased manner, will provide data upon which to base a decision.

A feasibility study could be used to test a new working system, which could be used because:

The current system may no longer suit its purpose,

Technological advancement may have rendered the current system redundant,

The business is expanding, allowing it to cope with extra work load,

Customers are complaining about the speed and quality of work the business provides,

Competitors are not winning a big enough market share due to an effective integration of

a computerized system.

Although few businesses would not benefit from a computerized system at all, the process of

carrying out this feasibility study makes the purchaser/client think carefully about how it is going

to be used.

After request clarification, analyst proposes some solutions. After that for each solution it is

checked whether it is practical to implement that solution.

This is done through feasibility study. In this various aspects like whether it is technically or

economically feasible or not. So depending upon the aspect on which feasibility is being done it

can be categorized into four classes:

Technical Feasibility

Economic Feasibility

Operational Feasibility

Legal Feasibility

The outcome of the feasibility study should be very clear. It should answer the following issues.

Is there an alternate way to do the job in a better way?

What is recommended?

Technical Feasibility, Economic Feasibility, Operational Feasibility, Legal Feasibility

Technical Feasibility

In technical feasibility the following issues are taken into consideration.

Whether the required technology is available or not

59

Whether the required resources are available -

- Manpower- programmers, testers & debuggers

- Software and hardware

Once the technical feasibility is established, it is important to consider the monetary factors also.

Since it might happen that developing a particular system may be technically possible but it may

require huge investments and benefits may be less. For evaluating this, economic feasibility of

the proposed system is carried out.

Economic Feasibility

For any system if the expected benefits equal or exceed the expected costs, the system can be

judged to be economically feasible. In economic feasibility, cost benefit analysis is done in

which expected costs and benefits are evaluated. Economic analysis is used for evaluating the

effectiveness of the proposed system.

In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an

analysis of the costs to be incurred in the system and benefits derivable out of the system. Click

on the link below which will get you to the page that explains what cost benefit analysis is and

how you can perform a cost benefit analysis.

Cost Benefit Analysis

Operational Feasibility

Operational feasibility is mainly concerned with issues like whether the system will be used if it

is developed and implemented. Whether there will be resistance from users that will effect the

possible application benefits? The essential questions that help in testing the operational

feasibility of a system are following.

Does management support the project?

Are the users not happy with current business practices? Will it reduce the time

(operation) considerably? If yes, then they will welcome the change and the new system.

Have the users been involved in the planning and development of the project? Early

involvement reduces the probability of resistance towards the new system.

Will the proposed system really benefit the organization? Does the overall response

increase? Will accessibility of information be lost? Will the system effect the customers

in considerable way?

Legal Feasibility

It includes study concerning contracts, liability, violations, and legal other traps frequently

unknown to the technical staff.

60

Cost Benefit Analysis

Developing an IT application is an investment. Since after developing that application it provides

the organization with profits. Profits can be monetary or in the form of an improved working

environment. However, it carries risks, because in some cases an estimate can be wrong. And the

project might not actually turn out to be beneficial.

Cost benefit analysis helps to give management a picture of the costs, benefits and risks. It

usually involves comparing alternate investments.

Cost benefit determines the benefits and savings that are expected from the system and compares

them with the expected costs.

The cost of an information system involves the development cost and maintenance cost. The

development costs are one time investment whereas maintenance costs are recurring. The

development cost is basically the costs incurred during the various stages of the system

development.

Each phase of the life cycle has a cost. Some examples are :

Personnel

Equipment

Supplies

Overheads

Consultants' fees

Cost and Benefit Categories

In performing Cost benefit analysis (CBA) it is important to identify cost and benefit factors.

Cost and benefits can be categorized into the following categories.

There are several cost factors/elements. These are hardware, personnel, facility, operating, and

supply costs.

In a broad sense the costs can be divided into two types

1. Development costs-

Development costs that are incurred during the development of the system are one time

investment.

Wages

Equipment

61

2. Operating costs,

e.g. , Wages

Supplies

Overheads

Another classification of the costs can be:

Hardware/software costs:

It includes the cost of purchasing or leasing of computers and it's peripherals. Software costs

involves required software costs.

Personnel costs:

It is the money, spent on the people involved in the development of the system. These

expenditures include salaries, other benefits such as health insurance, conveyance allowance, etc.

Facility costs:

Expenses incurred during the preparation of the physical site where the system will be

operational. These can be wiring, flooring, acoustics, lighting, and air conditioning.

Operating costs:

Operating costs are the expenses required for the day to day running of the system. This includes

the maintenance of the system. That can be in the form of maintaining the hardware or

application programs or money paid to professionals responsible for running or maintaining the

system.

Supply costs:

These are variable costs that vary proportionately with the amount of use of paper, ribbons,

disks, and the like. These should be estimated and included in the overall cost ofthe system.

Benefits

We can define benefit as

Profit or Benefit = Income - Costs

Benefits can be accrued by :

62

- Increasing income, or

- Decreasing costs, or

- both

The system will provide some benefits also. Benefits can be tangible or intangible, direct or

indirect. In cost benefit analysis, the first task is to identify each benefit and assign a monetary

value to it.

The two main benefits are improved performance and minimized processing costs.

Further costs and benefits can be categorized as

Tangible or Intangible Costs and Benefits

Tangible cost and benefits can be measured. Hardware costs, salaries for professionals, software

cost are all tangible costs. They are identified and measured.. The purchase of hardware or

software, personnel training, and employee salaries are example of tangible costs. Costs whose

value cannot be measured are referred as intangible costs. The cost of breakdown of an online

system during banking hours will cause the bank lose deposits.

Benefits are also tangible or intangible. For example, more customer satisfaction, improved

company status, etc are all intangible benefits. Whereas improved response time, producing error

free output such as producing reports are all tangible benefits. Both tangible and intangible costs

and benefits should be considered in the evaluation process.

Direct or Indirect Costs and Benefits

From the cost accounting point of view, the costs are treated as either direct or indirect. Direct

costs are having rupee value associated with it. Direct benefits are also attributable to a given

project. For example, if the proposed system that can handle more transactions say 25% more

than the present system then it is direct benefit.

Indirect costs result from the operations that are not directly associated with the system.

Insurance, maintenance, heat, light, air conditioning are all indirect costs.

Fixed or Variable Costs and Benefits

Some costs and benefits are fixed. Fixed costs don't change. Depreciation of hardware,

Insurance, etc are all fixed costs. Variable costs are incurred on regular basis. Recurring period

may be weekly or monthly depending upon the system. They are proportional to the work

volume and continue as long as system is in operation.

Fixed benefits don't change. Variable benefits are realized on a regular basis.

63

Performing Cost Benefit Analysis (CBA)

Example:

Cost for the proposed system ( figures in USD Thousands)

Benefit for the propose system

Profit = Benefits - Costs

= 300, 000 -154, 000

= USD 146, 000

Since we are gaining , this system is feasible.

Steps of CBA can briefly be described as:

Estimate the development costs, operating costs and benefits

Determine the life of the system

When will the benefits start to accrue?

When will the system become obsolete?

Determine the interest rate

This should reflect a realistic low risk investment rate.

Select Evaluation Method

64

When all the financial data have been identified and broken down into cost categories, the

analyst selects a method for evaluation.

There are various analysis methods available. Some of them are following.

1. Present value analysis

2. Payback analysis

3. Net present value

4. Net benefit analysis

5. Cash-flow analysis

6. Break-even analysis

Present value analysis:

It is used for long-term projects where it is difficult to compare present costs with future benefits.

In this method cost and benefit are calculated in term of today's value of investment.

To compute the present value, we take the following formula Where,

i is the rate of interest &

n is the time

Example:

Present value of $3000 invested at 15% interest at the end of 5th year is calculates as

P = 3000/(1 + .15)5

= 1491.53

Table below shows present value analysis for 5 years

Year Estimation Future

Value Present Value

Cumulative present

Value of Benefits

1 3000 2608.69 2608.69

2 3000 2268.43 4877.12

65

3 3000 1972.54 6949.66

4 3000 1715.25 8564.91

5 3000 1491.53 10056.44

Net Present Value : NPA

The net present value is equal to benefits minus costs. It is expressed as a percentage of the

investment.

Net Present Value= Costs - Benefits

% = Net Present Value/Investments

Example: Suppose total investment is $50000 and benefits are $80000

Then Net Present Value = $(80000 - 50000)

= $30000

% = 30000/80000

=.375

Break-even Analysis:

Once we have determined what is estimated cost and benefit of the system it is also essential to

know in what time will the benefits are realized. For that break-even analysis is done.

Break -even is the point where the cost of the proposed system and that of the current one are

equal. Break-even method compares the costs of the current and candidate systems. In

developing any candidate system, initially the costs exceed those of the current system. This is

an investment period. When both costs are equal, it is break-even. Beyond that point, the

candidate system provides greater benefit than the old one. This is return period.

66

Fig. 3.1 is a break-even chart comparing the costs of current and candidate systems. The

attributes are processing cost and processing volume. Straight lines are used to show the model's

relationships in terms of the variable, fixed, and total costs of two processing methods and their

economic benefits. B' point is break-even. Area after B' is return period. A'AB' area is investment

area. From the chart, it can be concluded that when the transaction are lower than 70,000 then the

present system is economical while more than 70,000 transaction would prefer the candidate

system.

Cash-flow Analysis:

Some projects, such as those carried out by computer and word processors services, produce

revenues from an investment in computer systems. Cash-flow analysis keeps track of

accumulated costs and revenues on a regular basis.

Request Approval

Those projects that are evaluated to be feasible and desirable are finally approved. After that,

they are put into schedule. After a project is approved, it's cost, time schedule and personnel

requirements are estimated.

Not all project proposals turn out to be feasible. Proposals that don't pass feasibility test are often

discarded. Alternatively, some rework is done and again they are submitted as new proposals. In

some cases, only a part is workable. Then that part can be combined with other proposals while

the rest of it is discarded.

67

After the preliminary analysis is done and if the system turns out to be feasible, a more intensive

analysis of the system is done. Various fact finding techniques are used for this purpose. In the

next chapter, we'll look into these fact finding techniques.

When we do the economic analysis, it is meant for the whole system. But for the people who

develop the system, the main issue is what amount of their effort goes into the building the

system. So how much should be charged from the customer for building the system. For this,

estimation is done by the developer. In estimation, software size and cost is estimated. Now we

will study, the various techniques used in the software estimation.

Software Estimation

Software measurements, just like any other measurement in the physical world, can be

categorized into Direct measures and Indirect measures. Direct measures of the software process

include measurement of cost and effort applied. Direct measures of a product include Lines Of

Code (LOC) produced, execution speed, memory size, and defects reported over some set of

time. Indirect measures of the software process include measurement of resulting features of the

software. Indirect measures of the product include its functionality, quality, complexity,

efficiency, reliability, maintainability etc.

In the starting era of computers, software cost was a small proportion of the cost for complete

computer based system. An error in estimation of software didn't have a major impact. But,

Today software is the most expensive element in many computer-based systems. Large cost

estimation errors can make the difference between profit and loss. Cost overruns can be

disastrous for the developer.

Estimation is not an exact science. Too many variables - human, technical, environmental, and

political - can affect the ultimate cost of software and effort applied to develop it.

In order to make a reliable cost and effort estimation there are lot of techniques that provide

estimates with acceptable mount of risk.

These methods can be categorized into Decomposition techniques and Empirical Estimation

models. According to Decomposition techniques the software project is broken into major

functions and software engineering activities (like testing, coding etc.) and then the cost and

effort estimation of each component can be achieved in a stepwise manner.

Finally the consolidated estimate is the clubbed up entities resulting from all the individual

components. Two methods under this head are Lines of Code (LOC) and Function Points (FP)

Estimation. Further Empirical Estimation models are used to offer a valuable estimation

approach, which is based on historical data (experience).

68

Lines of Code (LOC)

Lines of Code (LOC) method measures software and the process by which it is being developed.

Before an estimate for software is made, it is important and necessary to understand software

scope and estimate its size.

Lines of Code (LOC) is a direct approach method and requires a higher level of detail by means

of decomposition and partitioning. In contrast, Function Points (FP) is indirect an approach

method where instead of focusing on the function it focuses on the domain characteristics

(discussed later in the chapter).

From statement of software scope software is decomposed into problem functions that can each

be estimated individually. LOC or FP (estimate variables) is then calculated for each function.

An expected value is then computed using the following formula.

where,

EV stand for the estimation variable.

Sopt stand for the optimistic estimate.

Sm stands for the most likely estimate.

Spess stand for the pessimistic estimate.

It is assumed that there is a very small probability that the actual size results will fall outside the

optimistic or pessimistic value.

Once the expected value for estimation variable has been determined, historical LOC or FP data

are applied and person months, costs etc are calculated using the following formula.

Productivity = KLOC / Person-month

Quality = Defects / KLOC

Cost = $ / LOC

Documentation = pages of documentation / KLOC

Where,

KLOC stand for no. of lines of code (in thousands).

Person-month stand for is the time(in months) taken by developers to finish the product.

Defects stand for Total Number of errors discovered

Example:

69

Problem Statement: Take the Library management system case. Software developed for library

will accept data from operator for issuing and returning books. Issuing and returning will require

some validity checks. For issue it is required to check if the member has already issued the

maximum books allowed. In case for return, if the member is returning the book after the due

date then fine has to be calculated. All the interactions will be through user interface. Other

operations include maintaining database and generating reports at regular intervals.

Major software functions identified.

1. User interface

2. Database management

3. Report generation

For user interface

Sopt : 1800

Sm : 2000

Spess : 4000

EV for user interface

EV = (1800 + 4*2000 + 4000) / 6

EV = 2300

For database management

Sopt : 4600

Sm : 6900

Spess : 8600

EV for database management

EV = (4600 + 4*6900 + 8600) / 6

EV = 6800

For report generation

Sopt : 1200

Sm : 1600

Spess : 3200

EV for report generation

EV = (1200 + 4*1600 + 3200) / 6

EV = 1800

FP Estimation

70

Function oriented metrics focus on program "functionality" or "utility". Albrecht first proposed

function point method, which is a function oriented productivity measurement approach.

Five information domain characteristics are determined and counts for each are provided and

recorded in a table.

Number of user inputs

Number of user outputs

Number of user inquires

Number of files

Number of external interfaces

Once the data have been collected, a complexity value is associated with each count. Each entry

can be simple, average or complex. Depending upon these complexity values is calculated.

To compute function points, we use

FP = count-total X [ 0.65 + 0.01 * SUM(Fi) ]

Where, count-total is the sum of all entries obtained from fig. 3.2

Fi(I= 1 to 14) are complexity adjustment values based on response to questions(1-14) given

below. The constant values in the equation and the weighing factors that are applied to

information domain are determined empirically.

Fi

1. Does the system require reliable backup and recovery?

2. Are data communications required?

3. Are there distributed processing functions?

4. Is performance critical?

5. Will the system run in an existing, heavily utilized operational environment?

6. Does the system require on-line entry?

7. Does the on-line data entry require the input transaction to be built over multiple screens or

operations?

8. Are the inputs, outputs, files, or inquiries complex

9. Is the internal processing complex?

10. Is the code designed to be reusable?

11. Are master files updated on-line?

12. Are conversion and installations included in the design?

13. Is the system designed for multiple installations in different organizations?

14. Is the application designed to facilitate change and ease of use by the user?

Rate each factor on a scale of 0 to 5

71

0 - No influence

1 - Incidental

2 - Moderate

3 - Average

4 - Significant

5 - Essential

Count-total is sum of all FP entries.

Once function points have been calculated, productivity, quality, cost and documentation can be

evaluated.

Productivity = FP / person-month

Quality = defects / FP

Cost = $ / FP

Documentation = pages of documentation / FP

Fig 3.2 - Computing function-point metrics

Example: Same as LOC problem

Information Domain

Values Opt likely Pess

est

Account wt FP Account

72

Number of Inputs 4 10 16 10 4 40

Number of Outputs 4 7 16 8 5 40

Number of Inquiries 5 12 19 12 4 48

Number of Files 3 6 9 6 10 60

Number of external

interfaces 2 2 3 2 7 14

Count Total 202

Complexity weighing factors are determined and the following results are obtained.

Factor Value

Backup Recovery 4

Data Communication 1

Distributed processing 0

Perfomance Critical 3

Existing Operating Environment 2

On-line data entry 5

Input transaction over multiple screens 5

Master file updated online 3

Information domain values complex 3

Internal processing complex 2

Code design for reuse 0

Conversion/Installation in design 1

Multiple installations 3

73

Application designed for change 5

Sum ( Fi ) 37

Estimated number of FP :

FPestimated = count-total * [0.65 + .01 * sum(Fi) ]

FPestimated = 206

From historical data, productivity is 55.5 FP/person-month and development cost is $8000 per

month.

Productivity = FP/ person-month

person-month = FP/Productivity

= 202/55.5

= 3.64 person-month

Total Cost = Development cost * person-month

= 8000 * 3.64

=$29100

Cost per FP = Cost/FP

= 29100/202

= $144.2per FP

Empirical Estimation

In this model, empirically derived formulas are used to predict data that are a required part of the

software project-planning step. The empirical data are derived from a limited sample of projects.

Resource models consist of one or more empirically derived equations. These equations are used

to predict effort (in person-month), project duration, or other pertinent project data. There are

four classes of resource models:

• Static single-variable models

• Static multivariable models

• Dynamic multivariable models

74

• Theoretical models

Static single-variable model has the following form

Resource = c1 X (estimated characteristics c2)

Where,

Resource could be effort, project duration, staff size, or lines of software documentation.

c1 and c2 are constants derived from data of past projects.

Estimated characteristics is line of code, effort (if estimated), or other software characteristics.

The basic version of the Constructive Cost Model, or COCOMO, presented in the next section is

an example of a static-variable model.

Static multivariable models also use historical data to derive empirical relationships. A typical

model of this category takes the form

Resource = c11e1 + c12e2+ .................

Where ei is the ith software characteristics and ci1,ci2 are empirically derived constants for the

ith characteristics.

In dynamic multivariable models, resource requirements are projected as a function of time. If

the model is derived empirically, resources are defined in a series of time steps that allocate

some percentage of effort (or other resource) to each step in the software engineering process.

Further, each step may be divided into tasks. A theoretical approach to dynamic multivariable

modeling hypothesizes a continuous "resource expenditure curve" and from it, derives equations

that model behavior of the resource.

COCOMO, COnstructive COst MOdel

COCOMO, COnstructive COst MOdel is static single-variable model. Barry Boehm introduced

COCOMO models. There is a hierarchy of these models.

Model 1:

Basic COCOMO model is static single-valued model that computes software development effort

(and cost) as a function of program size expressed in estimated lines of code.

Model 2:

75

Intermediate COCOMO model computes software development effort as a function of program

size and a set of "cost drivers" that include subjective assessments of product, hardware,

personnel, and project attributes.

Model 3:

Advanced COCOMO model incorporates all characteristics of the intermediate version with an

assessment of the cost driver's impact on each step, like analysis, design, etc.

COCOMO can be applied to the following software project's categories.

Organic mode:

These projects are very simple and have small team size. The team has a good application

experience work to a set of less than rigid requirements. A thermal analysis program developed

for a heat transfer group is an example of this.

Semi-detached mode:

These are intermediate in size and complexity. Here the team has mixed experience to meet a

mix of rigid and less than rigid requirements. A transaction processing system with fixed

requirements for terminal hardware and database software is an example of this.

Embedded mode:

Software projects that must be developed within a set of tight hardware, software, and

operational constraints. For example, flight control software for aircraft.

The basic COCOMO model takes the form

where,

E is the effort applied in person-month,

D is the development time in chronological month,

KLOC is the estimated number of delivered lines ( expressed in thousands ) of code for project,

The ab and cb and the exponents bb and db are given in the table below.

76

Basic COCOMO

The basic model is extended to consider a set of "cost drivers attributes". These attributes can be

grouped together into four categories.

1. Product attributes

a) Required software reliability.

b) Complexity of the project.

c) Size of application database.

2. Hardware attributes

a) Run-time performance constraints.

b) Volatility of the virtual machine environment.

c) Required turnaround time.

d) Memory constraints.

3. Personnel attributes

a) Analyst capability.

b) Software engineer capability.

c) Virtual machine experience.

d) Application experience.

e) Programming language experience.

4. Project attributes

a) Application of software engineering methods.

b) Use of software tools.

c) Required development schedule.

Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "very high" in

importance or value. Based on the rating, an effort multiplier is determined from the tables given

by Boehm. The product of all multipliers results in an effort adjustment factor (EAF). Typical

values of EAF range from 0.9 to 1.4.

77

Example : Problem Statement same as LOC problem refer section 3.2.1

KLOC = 10.9

E = ab (KLOC)exp(bb)

= 2.4(10.9)exp(1.05)

= 29.5 person-month

D = Cb(E)exp(db)

= 2.5(29.5)exp(.38)

= 9.04 months

The intermediate COCOMO model takes the following form.

E = ai(LOC)exp(bi) X EAF

Where,

E is the effort applied in person-months,

LOC is the estimated number of delivered lines of code for the project.

The coefficient ai and the exponent bi are given in the table below.

Intermediate COCOMO

78

Preliminary Analysis - Case study: Library Management System

Again referring back to our "Library management system" discussed in earlier chapters, we now apply to it the concepts

that we have studied in this chapter.

Preliminary Analysis:

Request Clarification.

First the management of the library approached this ABC Software Ltd. for their request for the new automated system.

What they stated in their request was that they needed a system for their library that could automate its various functions.

And provide faster response.

From this request statement, it is very difficult for the analyst to know what exactly the customer wants. So in order to

get information about the system, the analyst visits the library site and meets the staff of the library. Library staff is go ing

to be the end user of the system. Analyst asks various questions from the staff so that the exact requirements for the

system become clear. From this activity, the analyst is able to identify the following requirements for the new system:

Function for issue of books

Function for return of books that can also calculate the fine if the book is returned after the due date

Function for performing different queries

Report generation functions

Function for maintaining account s

Maintaining the details for members, books, and suppliers in some structured way.

Now that the requirements are known, the analyst proposes solution system.

Solution: The desired system can be implemented with Oracle RDBMS in the back end with Visual Basic as the front

end. It will have modules for handling issue and return functions, generating reports, performing checks, and maintaining

accounts. It will also store the data relating to books, members, and suppliers in a structures way. In our case, the data

will be maintained in a relational way.

Feasibility Study

Now the next stage in preliminary analysis is to determine whether the proposed solution is practical enough to be

implemented. For this feasibility study is done.

First technical feasibility is done.

Major issues in technical feasibility are to see if the required resources- trained manpower, software and hardware are

available or not.

ABC Software Ltd. is big IT Company. It has developed similar projects using Oracle and VB. It has a special team that

is formed to work in this combination of projects, that is, Oracle and Visual Basic. So manpower is readily available. The

software is available with the company since it has already worked with the same software earlier also. So our solution is

79

technically feasible.

Technical feasibility doesn't guarantee if the system will be beneficial to the system if developed. For this economic

feasibility is done.

First task that is done in economic analysis is to identify the cost and benefit factors in the system proposed. In our case,

the analyst has identified the following costs and benefits.

First task that is done in economic analysis is to identify the cost and benefit factors in the system proposed. In our case,

the analyst has identified the following costs and benefits.

Costs

Cost Cost per unit Quantity Total Cost

Software

Oracle 50,000 1 50,000

Visual Basic 30,000 1 30,000

Windows Server 2003 15,000 1 15,000

Windows XP professional 5,000 4 5,000

Hardware

Central Computer 100,000 1 100,000

Client Machine 50,000 4 50,000

Development 50,000 1 50,000

Analyst 50,000 1 50,000

Developer 20,000 2 40,000

Training 20,000 1 20,000

80

Data Entry 5,000 1 5,000

Warranty ( 1 month)

Professional 20,000 1 20,000

Total Cost 5,55,000

Benefits

According to new policy: A member is required to pay Rs 500 for a half yearly membership and Rs 1000 for a year

membership.

Expected increase in number of members : 75 per month

40 new members for 1 year and 35 new members for half year

Free collected from new members in one year = 12 (40 * 1000 + 35 * 500)

= Rs 6,90,000

For four years = 4 * 6,90,000

= 27,60,000

Now using Net present value method for cost benefit analysis we have,

Net present value( or gain ) = Benefits - Costs

= 27,60,000 - 5,55,000

= 22,10,000

Gain % = Net present value / investment

= 22,10,000 / 5,55,000

81

= 4.018

Overall Gain = 401.8 % in four year

For each year

First year

Investment = 5,50,000

Benefit = 6,90,000

Net present value for first year = 6,90,000 - 5,50,000

= 1,40,000

Gain % = 1,40,000 / 5,50,000

= .254

= 25.4 % in first year

Second Year

Investment = 5,50,000

Benefit = 13,80,000

Net present value for second year = 13,80,000 - 5,50,000

= 8,30,000

82

Gain % = 830000/550000

= 1.50

= 150 % at the end of second year

Third Year

Investment = 5,50,000

Benefit = 20,70,000

Net present value for third year = 20,70,000 - 5,50,000

= 15,20,000

Gain % = 1520000/550000

= 2.76

= 276 % at the end of third year

Fourth Year

Invetment = 550,000

Benefit = 2760000

83

Net Present Value for fourth year = 2760000 - 550000

= 2210000

Gain % = 2210000 / 550000

= 4.018

= 401.8 % at end of fourth year

From CBA we have found that it is economically feasible since it is showing great gains(about 400%).

After economic feasibility, operational feasibility is done. In this, major issue is to see if the system is developed what is

the likelihood that it'll be implemented and put to operation? Will there be any resistance from its user?

It is very clear that the new automated system will work more efficiently and faster. So the users will certainly accept it.

Also they are being actively involved in the development of the new system. Due to this fact they will know the system

well and will be happy to use a new improved system. So our system is operationally feasible. After the feasibility study

has been done and it is found to be feasible, the management has approved this project. So further work can de done that

is the design of system that will be discussed in the later chapters.

Fact Finding and Decision Making Techniques

At the end of this chapter you would be able to know the various fact finding techniques and you would also be able to

understand techniques used for decision making.

Contents

Fact finding techniques

Getting Cooperation

What Facts to Gather

How to Initiate Fact Gathering?

Common Sense Protocol - Where to Get the Facts?

Introduction to the Employee at the Work Place

Recording Technique

A Caution about Instant Improvements

How to Keep the Data Organized?

84

Various kinds of techniques used in fact techniques

Interviews

Structured Interviews

Unstructured Interviews

Questionnaires

Open-Response Based Questionnaires

Closed-Response Based Questionnaires

Record Reviews

On-site Observation

Decision making and Documentation

Decision Trees

Decision Tables

Structured English

Data Dictionary

CASE Tools

Fact Finding Techniques - Case Study : Library Management System

Fact Finding Techniques

Fact-finding is an important activity in system investigation. In this stage, the functioning of the system is to be

understood by the system analyst to design the proposed system. Various methods are used for this and these are known

as fact-finding techniques. The analyst needs to fully understand the current system.

The analyst needs data about the requirements and demands of the project undertaken and the techniques employed to

gather this data are known as fact-finding techniques.

Various kinds of techniques are used and the most popular among them are interviews, questionnaires, record reviews,

case tools and also the personal observations made by the analyst himself. Each of these techniques is further dealt in

next pages.

Two people can go into the same area to gather facts and experience entirely different results. One spends weeks and

gets incomplete and misleading data. The other is finished in a few hours and has complete and solid facts. This session

outlines some of the things a person can do to achieve the latter. It covers:

• Getting user cooperation

85

• Choosing the facts to gather

• Initiating fact gathering

• Common sense protocol - Where to get the facts?

• Introduction to the employee at the work place

• Recording technique

• Keeping the data organized

Getting Cooperation in Fact Finding

The cooperation of operating people is crucial to fact gathering. However, if the operating people believe that the

purpose of the fact gathering is to make changes in the work with the object of reducing staff, it is naïve to expect them

to help. The key to obtaining cooperation is two-way loyalty and trust. We get this by commitment to developing

improvements that simultaneously serve the interests of employees while they serve the interests of owners, managers

and customers.

Process improvement projects should be undertaken with the object of making the company as good as it can be, not

reducing staff. Of course process improvements will change the work, often eliminating tasks. This is obvious. Not quite

so obvious is the fact that eliminating tasks does not have to mean reducing staff. It can mean having resources available

at no additional cost to do any number of things needed by the organization, not the least of which could be further

improvement work. And, no one is in a better position to improve the work than the people who know it first hand.

When organizations are truly commited to their people and their people know this, their people can relax and

enthusiastically commit themselves to continuous improvement.

This article is written for companies that want to capture the enormous potential of enthusiastic employees embracing

new technology. They cannot accomplish this with lip service. The employees of an organization are its most valuable

resource. When executives say this sort of thing publicly but then treat their people as expenses to be gotten rid of at the

first opportunity, that is lip service. Resources should be maintained and utilized, not dumped. When they are dumped,

trust dissolves.

Meanwhile the people and their society have changed significantly in the last few decades. The popularization of

computers stands high among the factors that have contributed to recent social change. Young people are being exposed

to computers early in their education. A sizeable portion of the work force is comfortable working with computers. This

was certainly not so a generation ago.

Another social change that is very important to process improvement is the increasing acceptance of involving operating

level employees in the improvement process. It has become rather commonplace to form teams of operating people.

86

Along with the increasing acceptance of employee involvement has come a dramatic change in the role of the internal

consultant who is learning new skills for working with teams.

This article addresses the role of the facilitator who gathers facts about work processes to use with an improvement

team. The facilitator follows a work process as it passes through departmental boundaries and prepares an As-is Chart.

Then an improvement team made up of people from the departments involved in the process studies the As-is Chart and

develops a To-be Chart. Facilitators learn how to study work processes. Facilitators are a great help as they gather and

organizing the facts of work processes and guide the study of those facts by improvement teams

What Facts to Gather?

Knowing what facts you want to gather is crucial to effective fact gathering. When a people do not know what they are

looking for but attempt to learn everything they can, in effect ―to gather all of the facts‖, they embark on endless and

often fruitless effort. Knowing what facts not to gather is just as important as knowing the facts that are needed.

There is a pattern to fact gathering that is particularly helpful during process improvement. It makes use of the standard

journalism questions: what, where, when, why, who and how. This pattern focuses on the information that is relevant for

process improvement and avoids that which is not. How it accomplishes this is not completely obvious. It goes like this.

Distinguishing Between Facts and Skill

No matter how carefully facts are gathered, they will never match the understandings of people who have experienced

the work first hand for years. Those people possess the organizational memory. They have accumulated detailed

knowledge that is available to them alone. They access this knowledge intuitively, as they need it, in a fashion that has

the feel of common sense. But, they cannot simply explain it to someone else.

For instance, we could ask an experienced medical doctor what he does when he visits a patient and expect a general

answer like, ―I examine the patient and enter a diagnosis on the patient record form.‖ However, if we then asked ―How

do you do that? How do you know what to write as the diagnosis?‖, we would be asking for detail that took years to

accumulate. During those years this detail has been transformed from myriads of individual facts to intuitively available

skill. We simply cannot gather it.

The information that the doctor and for that matter all employees can readily provide answers the question, ―What?‖.

The information that cannot be provided because it resides in the realm of skill answers the question, ―How?‖. Rather

than attempt to gather the skill and settling for simplistic/superficial data we acknowledge that that information is not

accessible to the fact gatherer.

However, this information is critical to effective improvement. In order to get at it, we must invite the people who have

it to join in the improvement development activity. This is the fundamental strength of employee teams. They provide

the organizational memory.

And, don‘t think for a moment that medical doctors have skill but clerks don‘t. In all lines of work there are differences

of skill levels. Our object in process improvement should be to incorporate into our changes the finest skills available.

So we use teams of the best experienced employees we have. To do otherwise invites superficiality.

Using the Description Pattern

87

The description pattern provides facts, not skills. We organize these facts on charts as effective reminders of the steps in

a process. When these charts are used by people who are skilled at performing those steps, we have the knowledge we

need for improvement. Therefore:

What – Answer this question at every step. This tells us what the step is and provides the necessary reminder for the

team.

Where – This question deals specifically with location. Answer it for the very first step of the process and then every

time the location changes and you will always know location.

When – When dealing with processes, this question generally means how long. Ask it throughout the fact gathering,

making note of all delays and particularly time-consuming steps.

Who – This question deals specifically with who is performing each step. The easiest way to collect and display this

information is to note every time a new person takes over.

How – This question is important but it changes the fact gathering to skill gathering. We should rarely get into it.

Instead we leave this information to be provided by the team, as needed.

Why – This question is different. It is evaluative rather than descriptive. It becomes most important when we study the

process for improvement but while we are fact gathering, it is premature. Just gather facts. Later as a team we will

question the why of each of them.

Follow this pattern and:

• You will always show what is happening.

• You will always show where the work is happening.

88

• You will show who is doing the work whenever a person is involved.

• You will show when most of the processing time is occurring.

• You won‘t bog your readers down with how the individual steps are done, non flow detail.

• You won‘t bog your readers down with how the individual steps are done, non flow detail.

How to Initiate Fact Gathering - Public Announcement

A public announcement can go a long way towards inspiring cooperation. It can also provide an opportunity to forestall

the anxieties just discussed. The people working in the areas affected by the project are informed that a five or ten

minute meeting will be held at the end of a work shift and that a senior executive has an important announcement. (This

senior executive should be a person whose authority spans the entire project.)

The meeting includes an announcement of the project, its objective, who is involved in it, a request for the support of all

employees and an invitation for questions. It is conducted by the executive mentioned above because it is important that

statements about the intent of the project be made by someone who has the authority to stand behind his or her words. It

is also helpful for the executive to introduce the analyst and the team members who have been assigned to the project.

The issue of staff cuts may be introduced by the executive or may surface as a question. (Or, it may not arise at all in

organizations where loss of employment is a non-issue.) If it is addressed, it should be answered directly and forcefully.

"I guarantee there will be no loss of employment because of work improvement." This is not a difficult guarantee for

executives who genuinely believe that their people are their most valuable resource. (Note, this is not a guarantee that

there will be no loss of employment. If we fail to improve our work, there is a pretty certain guarantee that there will be

loss of employment.)

This meeting can also have constructive side effects. One is that the analyst gets a public introduction to the people from

whom he or she will be gathering data. Simultaneously, everyone is informed of the reason for the project, making it

unnecessary for the analyst to explain this at each interview. And, the explanation carries the assurances of the boss

rather than an analyst.

Common Sense Protocol - Where to Get the Facts?

It is critical that the analyst go where the facts are to learn about them. This means going where the work is done and

learning from the people who are doing it. If there are a number of people doing the same work, one who is particularly

knowledgeable should be selected or several may be interviewed.

Unfortunately, analysts often try to collect data in indirect ways. Occasionally this may be for no better reason than that

the analyst is too lazy to go where the work is done. Or, the analyst may have been instructed to keep the project a secret

because management wants to avoid stirring up concern about job loss. Unfortunately, when employees learn (and they

89

will) that secret projects are underway in their areas, their anxiety levels will rise all the higher, encouraging more non-

cooperation.

Introverts tend to be attracted to research type work and they also tend to find excuses to avoid meeting people. They are

often tempted to use written procedures as their source of data rather than going directly to the operating people. Or,

they may simply assume data to avoid having to go after it.

Sometimes an analyst arrives in the supervisor's office (a proper practice when visiting a department for the first time)

and the supervisor wants to provide the information rather than having the analyst bother the employee who does the

work. This could be motivated by a sincere desire to help. The supervisor may also want to slant the data. Regardless of

the motive, it separates the analyst from the work place and the person doing the work.

Whatever the reasons, each time an analyst settles for collecting data at a distance from reality, the quality of the

analysis suffers. Guesses replace facts. Fantasy replaces reality. Where the differences are small the analyst may slide

by, but professionals should not try to slide by. Where the differences are large the analyst may be seriously

embarrassed. Meanwhile, the quality of the work suffers and, in the worst cases, major commitments to work methods

are made based on faulty premises.

Introduction to the Employee at the Work Place

When we are gathering data, everywhere you go people are accommodating you, interrupting their work to help you do

your work. The least you can do is show that you are willing to return the favor. When the time is not convenient, agree

to come back later. Occasionally an employee will suggest that it is an inconvenient time and ask that you come back

later. Sometimes, however, the employee is seriously inconvenienced but for some reason does not speak up about it. A

sensitive analyst may notice this. However, to be on the safe side it helps to ask, "Is this a convenient time?" Coming

back later is usually a minor problem. Typically you have a number of places to visit. Pick a more convenient time and

return. Don't be surprised if the employee appreciates it and is waiting for you with materials set out when you return.

Whatever you do, don't start suspecting that every time a person puts you off that person is trying to scuttle your work or

is a difficult employee. Assume the person is honestly inconvenienced and simply come back later. If someone puts you

off repeatedly, it is still a minor inconvenience as long as you have data to collect elsewhere. Give the employees the

benefit of the doubt, knowing that every time you accommodate them their debt to you grows. If you do in fact run into

a genuinely uncooperative and eventually have to impose a time, it is nice to be able to remind that person of how many

times you have rescheduled for his or her benefit. At such times you will also appreciate the project-announcement

meeting when the senior executive brought everyone together, described the importance of the project and asked for

support.

As you are about to start the interview the employee may bring up a subject for idle conversation such as the weather, a

sports event, a new building renovation, etc. People often do this when they first meet in order to size up one another

(on a subject that doesn't matter) before opening up on subjects that are important. Since the purpose, on the part of the

employee, is to find out what you are like you will do well to join in the conversation politely and respectfully. Then

when it has continued for an appropriate amount of time, shift to the subject of the interview, perhaps with a comment

90

about not wanting to take up too much of the employee's time.

Respect

Most of the time analysts gather data from people at the operating levels who happen to be junior in status (i.e. file

clerks, messengers, data entry clerks). Be careful not to act superior. One thing you can do to help with this is to set in

your mind that wherever you gather data you are talking to the top authority in the organization. After all, if the top

authority on filing in the organization is the CEO, the organization has serious trouble. Don't treat this subject lightly.

We all receive a good deal of conditioning to treat people in superior positions with special respect. Unfortunately, the

flip side of this conditioning leads to treating people in lesser positions with limited respect.

Unintentionally, analysts frequently show disrespect for operating employees by implying that the way they do their

work is foolish. The analyst is usually eager to discover opportunities for improvement. When something appears

awkward or unnecessarily time-consuming the analyst is likely to frown, smile, act surprised, etc. In various ways, an

analyst can suggest criticism or even ridicule of the way the work is being done. The bottom line is that the analyst, with

only a few minutes observing the work, is implying that he or she knows how to do it better than a person who has been

doing it for years. This is unacceptable behavior. Don't do it! Go to people to find out what is happening, not to judge

what is happening. First get the facts. Later we can search out better ways and invite knowledgeable operating people to

join us in that effort.

A Caution about Instant Improvements

Recording Technique

Recording Data

The keys to effective data recording are a reverence for facts and knowing how to look for them. You do not go into

data collection with a preconceived notion of the design of the final procedure. You let the facts tell you what shape the

procedure should take. But, you must be able to find facts and know how to record them. This is done by breaking down

the procedure into steps and listing them in proper sequence, without leaving things out. The analyst keeps his or her

attention on the subject being charted, follows its flow, step by step, and is not distracted by other subjects that could

easily lead off onto tangents. The analyst becomes immersed in the data collection, one flow at a time.

Record what is actually happening, not what should happen or could happen. Record without a preference. Wash the

wishes from your eyes and let the facts speak for themselves. When later you have them neatly organized and present

them for study the facts will assert their authority as they tell their story.

The Authority of the Facts

There are two authority systems in every organization. One is a social authority set up for the convenience of arranging

people and desks and telephones, dividing up the work and making decisions. The other authority system is reality itself.

Too often the former is revered and feared and attended to constantly, while the latter is attended to when time permits.

Yet, whether we come to grips with the facts or not, they enforce themselves with an unyielding will of steel. 'Reality is'

- whether we are in touch with it or not. And, it is indifferent to us. It is not hurt when we ignore it. It is not pleased or

91

flattered or thankful when we discover it. Reality simply does not care, but it enforces its will continuously.

We are the ones who care. We care when reality rewards us. We care when reality crushes us. The better we are able to

organize our methods of work in harmony with reality, the more we prosper. When we are unable to discover reality, or

deny reality we are hurt. Period!

So we enter into data collection with respect for reality. We demonstrate respect for the people who are closest to

reality. And, we do our best to carefully record the unvarnished truth.

Observation

A person who has been doing a job for years will have an understanding of the work that goes well beyond his or her

ability to describe it. Don't expect operating people to describe perfectly and don't credit yourself with hearing perfectly.

Sometimes it is a lot easier for a person to show you what he or she does than to describe it. A demonstration may save a

good deal of time. A person might be able to show you how the task is done in minutes but could talk about it for hours.

Most people are able to speak more comfortably to a human being than to a machine. Furthermore, a tape recorder

doesn't capture what is seen. If you are going to use a tape recorder, use it after you have left the interview site. It can

help you capture a lot of detail while it is fresh in your mind without causing the employee to be ill at ease.

Level of Detail

As covered earlier while explaining the Description Pattern, you can gather facts but not skill. If you attempt to gather

enough information to redesign a procedure without the help of experienced employees, your data collection will be

interminably delayed. For instance, if you are studying a procedure that crosses five desks, and the five people who do

the work each have five years of experience, together they have a quarter of a century of first-hand experience. There is

no way to match that experience by interviewing. No matter how many times you go back, there will still be new things

coming up. Then, if you redesign the procedure based solely on your scanty information, your results will be deficient in

the eyes of these more experienced people. It doesn't do any good to complain that they didn't tell you about that after

you have designed a defective procedure.

Save yourself a lot of time and grief by not bothering to record the details of the individual steps and concentrate on the

flow of the work. It goes here. They do this. It sits. It is copied. This part goes there. That one goes to them. Never mind

the detail of how they do the different steps. Just note the steps in their proper sequence. Then, when it comes time to

analyze and you invite in those five people, they bring with them their twenty-five years of detailed experience. Voila!

You have the big picture and you have the detail. You have all that you need to discover the opportunities that are there.

Defused resentment

When people who have been doing work for years are ignored while their work is being improved, there is a clear

statement that their experience is not considered of value. These people tend to feel slighted. When the organization then

pays consultants who have never done the work to develop improvements, this slight becomes an insult. When the

consultants arrive at the workplace trying to glean information from the employees so that they can use it to develop

their own answers, how do you expect the employees to react? Do you think they will be enthusiastic about providing

the best of their inside knowledge to these consultants? "Here, let me help you show my boss how much better you can

92

figure out my work than I can?" Really!

We don't have to get into this kind of disagreeable competition. Instead we honestly accept the cardinal principle of

employee empowerment which is, "The person doing the job knows far more than anyone else about the best way of

doing that job and therefore is the one person best fitted to improve it." Allan H. Mogensen, 1901-1989, the father of

Work Simplification.

By involving operating people in the improvement process, you also reduce the risk of getting distorted or misleading

data. Their experience is brought into improvement meetings, unaltered. If they get excited about helping to develop the

best possible process they will have little reason to distort or withhold the data

A Caution about Instant Improvements

While the analyst cannot match the employees' detailed knowledge of what happens at their workplaces, it is not at all

difficult to discover some things that those people are unaware of, things that involve multiple workplaces. During data

collection, opportunities for improvement of a certain type surface immediately. Some of them are outstanding. The

analyst discovers, for instance, that records and reports are being maintained that are destroyed without ever being used.

Time-consuming duplication of unneeded records is found. Information is delivered through roundabout channels

creating costly delays. The only reason these opportunities were not discovered earlier by the employees is that the

records had never been followed through the several work areas. These instant improvements simply weren't visible

from the limited perspective of one office. The people preparing the reports had no idea that the people receiving them

had no use for them and were destroying them. The people processing redundant records had no idea that other people

were doing the same thing.

These discoveries can be clearly beneficial to the organization. However, they can be devastating for the relationship

between the analyst and the operating employees. The problem lies in the fact that the analyst discovers them. This may

delude the analyst into believing that he or she is really capable of redesigning the procedure without the help of the

employees. "After all, they have been doing this work all these years and never made these discoveries. I found them so

quickly. I must be very bright."

Most people spend a great deal of their lives seeking confirmation of their worth. When something like this presents

itself, an analyst is likely to treasure it. It becomes a personal accomplishment. It is perceived as support for two

judgments, "I am a lot better at this than those employees." and "Employees in general are not capable of seeing these

kinds of things." Both of these judgments are wrong. The credit goes to the fact that the analyst was the first person with

the opportunity to follow the records through their flow. If any one of those employees had done the same thing, the

odds are that the results would have been the same.

The analyst is apt to alienate the employees if he or she grabs the credit for these discoveries. If this prompts the analyst

to proceed with the entire redesign of the procedure without the help of the employees, he or she will be cut off from

hundreds of finer details, any one of which could seriously compromise the effort.

Taking credit for these early discoveries can also alienate employees even if they are invited into the improvement

activity. For instance, it is not uncommon for an analyst who is about to go over a new process chart with a group of

93

users to start by telling them about the discoveries made while preparing the chart. This can appear very innocent, but

the fact is, the analyst does this in order to get the credit for the discoveries before the team members spot them.

Instinctively, the analyst knows that as soon as the employees see the chart those discoveries will be obvious to them as

well.

An analyst who realizes that the enthusiastic involvement of the team members is much more important than the credit

for one idea or another will want to keep quiet about early discoveries until after the employees get a chance to study the

chart. In doing this the analyst positions himself or herself to provide professional support to knowledgeable employees.

Soon they make these obvious discoveries for themselves and this encourages them to become involved and excited

about the project. It makes it theirs. In the end the analyst shares the credit for a successful project, rather than grabbing

the credit for the first few ideas in a project that fails for lack of support.

How to Keep the Data Organized

One important characteristic of professional performance is the ability to work effectively on many assignments

simultaneously. Professionals have to be able to leave a project frequently and pick it up again without losing ground.

The keys to doing this well are:

1. Knowing the tools of the profession and using them in a disciplined manner.

2. Working quickly.

3. Capturing data the same day that it is gathered

Using the Tools of the Profession with Discipline

In this respect, there is more professionalism in a well conceived set of file names and directories than there is in a wall

full of certificates belonging to a disorganized person. For that matter, a three-ring binder may do more good than

another certificate.

A professional simply keeps track of the information that he or she gathers. Perhaps the worst enemy of data

organization is the tendency on the part of intelligent people, who are for the moment intensely involved in some

activity, to assume that the clear picture of it that they have today will be available to them tomorrow or a week later or

months later. One way of avoiding this is to label and assemble data as if it will be worked on by someone who has

never seen it before. Believe it or not, that person may turn out to be yourself.

A word about absentmindedness may be appropriate. When people are goal-oriented and extremely busy they frequently

find themselves looking for something they had just moments before. The reason is that when they put it down their

mind was on something else and they did not make a record of where they put it. To find it again they must think back

to the last time they used it and then look around where they were at that time. Two things we can do to avoid this are:

1. Develop the discipline of closure so that activities are wrapped up.

2. Select certain places to put tools and materials and do so consistently.

94

Working Quickly

An analyst should take notes quickly. Speed in recording is important in order to keep up with the flow of information

as the employee describes the work. It also shortens the interview, making the interruption less burdensome to the

employee, and it reduces the probability that something will come up that forces the interview to be terminated

prematurely. At the close of the interview it is a good idea to review the notes with the employee, holding them in clear

view for the employee to see and then, of course, thank the employee for his or her help.

Skill in rapid note-taking can be developed over time. This does not mean that you rush the interview. Quite the

contrary. Address the person from whom you are gathering information calmly and patiently. But, when you are actually

recording data you do it quickly and keep your attention on the person. For process analysis data gathering, you don't

have to write tedious sentences. The charting technique provides you with a specialized shorthand (using the symbols

and conventions of process charting in rough form). See the rough notes following.

Same Day Capture of Data

The analyst then returns to his or her office with sketchy notes, hastily written. These notes serve as reminders of what

has been seen and heard. Their value as reminders deteriorates rapidly. While the interview is fresh in mind these notes

can bring forth vivid recall. As time passes they lose this power. The greatest memory loss usually occurs in the first 24

hours.

A simple rule for maximizing the value of these notes is to see that they are carefully recorded in a form that is clear and

legible, the same day as the interview. The sooner after the interview this is done, the better. If this is postponed, the

quality of the results suffers. What was clear, at the time of the interview becomes vague or completely forgotten.

Details are overlooked or mixed up. Where the notes are not clear the analyst resorts to guessing about things that were

obvious a few days earlier. Or, to avoid the risk of guessing, the analyst goes back to the employee for clarification. This

causes further inconvenience to the employee and creates an unprofessional impression. You can help yourself, in this

regard, by scheduling to keep the latter part of the work day free for polishing up notes on days when you are collecting

data.

Various kinds of techniques used in fact techniques

Various kinds of techniques are used and the most popular among them are

1. Interviews

2. Questionnaires

3. Record reviews

4. Personal observations made by the analyst himself.

Each of these techniques is further dealt with

Interviews

Interview is a very important data gathering technique as in this the analyst directly contacts system and the potential

95

user of the proposed system.

One very essential aspect of conducting the interview is that the interviewer should first establish a rapport with the

interviewee. It should also be taken into account that the interviewee may or may not be a technician and the analyst

should prefer to use day to day language instead of jargon and technical terms.

For the interview to be a success the analyst should be appropriately prepared, as he needs to be beforehand aware of

what exactly needs to be asked and to what depth. Also he should try to gather maximum relevant information and data.

As the number and type of respondents vary, the analyst should be sensitive to their needs and nature.

The advantage of interviews is that the analyst has a free hand and he can extract almost all the information from the

concerned people but then as it is a very time consuming method, he should also employ other means such as

questionnaires, record reviews, etc.

This may also help the analyst to verify and validate the information gained. Interviewing should be approached, as

logically as possible and from a general point of view the following guides can be very beneficial for a successful

interview.

1. Set the stage for the interview.

2. Establish rapport; put the interviewee at ease.

3. Phrase questions clearly and succinctly.

4. Be a good listener; avoid arguments.

5. Evaluate the outcome of the interview.

The interviews are of two types namely structured and unstructured.

1. Structured Interview

2. Unstructured Interview

Structured Interview

Structured interviews are those where the interviewee is asked a standard set of questions in a particular order. All

interviewees are asked the same set of questions.

The questions are further divided in two kinds of formats for conducting this type of interview. The first is the open-

response format in which the respondent is free to answer in his own words. An example of open-response is "Why are

you dissatisfied with the current leave processing method?" The other option is of closed-response format, which limits

the respondents to opt their answer from a set of already prescribed choices. An example of such a question might be

"Are you satisfied with the current leave processing methods?" or "Do you think that the manual leave processing

procedure be changed with some automated procedure?"

Unstructured Interview

The unstructured interviews are undertaken in a question-and-answer format. This is of a much more flexible nature

96

than the structured interview and can be very rightly used to gather general information about the system.

Here the respondents are free to answer in their own words. In this way their views are not restricted. So the interviewer

get a bigger area to further explore the issues pertaining to a problem.

Structured Vs Unstructured Interviews

Each of the structured and unstructured interview methods has its own merits and demerits. We will consider the

structured format first and that too its advantages. This method is less time consuming and the interviewer need not be a

trained person.

It is easier to evaluate objectively since answers obtained are uniform. On the other hand a high level of structure and

mechanical questions are posed which may earn the disliking of the respondents. Also this kind of structure may not be

appropriate for all situations and it further limits the respondent spontaneity.

In unstructured interviews the respondents are free to answer and present their views. Also there may be case that some

issue might surface spontaneously while answering some other question. In that case the respondent can express views

on that issue also.

But at times, it may happen that the interview goes in some undesired direction and the basic facts for which the

interview was organized do not get relieved. So the analyst should be careful while conducting interviews.

Questionnaires

Questionnaires are another way of information gathering where the potential users of the system are given

questionnaires to be filled up and returned to the analyst.

Questionnaires are useful when the analyst need to gather information from a large number of people. It is not possible

to interview each individual. Also if the time is very short, in that case also questionnaires are useful. If the anonymity

of the respondent is guaranteed by the analyst then the respondent answers the questionnaires very honestly and

critically.

The questionnaire may not yield the results from those respondents who are busy or who may not give it a reasonable

priority.

The analyst should sensibly design and frame questionnaires with clarity of it's objective so as to do justice to the cost

incurred on their development and distribution. Just like the interviews and on the same lines questionnaires are of two

types i.e. open-response based and the closed-response based.

Open-Response Based Questionnaires

97

The objective of open-response questionnaire is to gather information and data about the essential and critical design

features of the system. The open-ended question requires no response direction or specific response.

This form is also used to learn about the feelings, opinions, and experiences of the respondents. This information helps

in the making the system effective because the analyst can offer subsequent modifications as per the knowledge gained.

Closed-Response Based Questionnaires

The objective of closed-response questionnaire is to collect the factual information of the system. It gives an insight in

how the people dealing with the system behave and how comfortable are they with it. In this case the respondents have

to choose from a set of given responses. Thus the respondent can express their liking for the most favorable one from

the possible alternatives.

The closed questions can be of various types and the most common ones are listed below.

1. Fill-in-the-blanks.

2. Dichotomous i.e. Yes or No type.

3. Ranking scale questions ask the respondents to rank a list of items in the order of importance or preference.

4. Multiple-choice questions which offer respondents few fixed alternatives to choose from.

5. Rating scale questions are an extension of the multiple-choice questions. Here the respondent is asked to rate certain

alternatives on some given scale.

Open Vs Closed Questionnaires

The basic comparison between the two can be made on the grounds of the format used. Open form offers more

flexibility and freedom to the respondents whereas the closed form is more specific in nature.

Open-ended questionnaires are useful when it is required to explore certain situation.They also require a lot of time of

the analyst for evaluation.

Closed questionnaires are used when factual information is required. Closed questions are quick to analyze but typically

most costly to prepare but they are more suitable to obtain factual and common information.

It is the job of the analyst to decide which format should be employed and what exactly should be it's objective. The

care should be taken to ensure that all the parts of the form are easy to understand for the respondents so that they can

answer with clarity.

Record Reviews

98

Records and reports are the collection of information and data accumulated over the time by the users about the system

and it's operations. This can also put light on the requirements of the system and the modifications it has undergone.

Records and reports may have a limitation if they are not up-to-date or if some essential links are missing. All the

changes, which the system suffers, may not be recorded.

The analyst may scrutinize the records either at the beginning of his study which may give him a fair introduction about

the system and will make him familiar with it or in the end which will provide the analyst with a comparison between

what exactly is/was desired from the system and it's current working.

One drawback of using this method for gathering information is that practically the functioning of the systems is

generally different from the procedure shown in records. So analyst should be careful in gathering in gathering

information using this method.

On-Site Observation

On-site observations are one of the most effective tools with the analyst where the analyst personally goes to the site and

discovers the functioning of the system. As an observer, the analyst can gain first hand knowledge of the activities,

operations, processes of the system on-site, hence here the role of an analyst is of an information seeker.

This information is very meaningful as it is unbiased and has been directly taken by the analyst. This exposure also

sheds some light on the actual happenings of the system as compared to what has already been documented, thus the

analyst gets closer to the system. This technique is also time-consuming and the analyst should not jump to conclusions

or draw inferences from small samples of observation rather the analyst should be more patient in gathering the

information. This method is however less effective for learning about people's perceptions, feelings and motivations.

Decision Making Documentation

Decision-making is an integral part of any business no matter how small, simple or big and complex it may be. Thus

decisions have to be made and set procedures are to be followed as the subsequent actions. Thus while analyzing and

designing a business system, analyst also needs to identify and document any decision policies or business rules of the

system being designed. There are various tools and techniques available to the analyst for this, like decision trees,

decision tables or structured English.

To analyze procedures and decisions the first step to be taken is to identify conditions and actions of all possible

activities. Conditions are the possibilities or the possible states of any given entity, which can be a person, place, thing,

or any event. Conditions are always in a flux i.e. they keep on varying time to time and object to object and based only

on these conditions the decisions are made therefore conditions are also put as decision variables.

99

Documentation comes as an aid in this condition based decision process. As the whole web of all the possible

combination of conditions and decisions is usually very large and cumbersome it becomes extremely important to

document these so that there are no mistakes committed during the decision process.

Here comes the role of documenting tools, which are available to the analyst. Tools, which are usually used, are

decision trees, decision tables, Structured English and the various CASE tools. The basic role of these tools is to depict

the various conditions, their possible combinations and the subsequent decisions.

This has to be done without harming the logical structure involved. Once all of the parameters are objectively

represented the decision process becomes much simpler, straightforward and almost error free.

Decision Trees

Decision Tables

Structured English

Data Dictionary

CASE Tools

Decision Trees

Decision tree is a tree like structure that represents the various conditions and the subsequent possible actions. It also

shows the priority in which the conditions are to be tested or addressed. Each of its branches stands for any one of the

logical alternatives and because of the branch structure, it is known as a tree.

The decision sequence starts from the root of the tree that is usually on the left of the diagram. The path to be followed

to traverse the branches is decided by the priority of the conditions and the respectable act ions. A series of decisions are

taken, as the branches are traversed from left to right. The nodes are the decision junctions. After each decision point

there are next set of decisions to be considered. Therefore at every node of the tree represented conditions are

considered to determine which condition prevails before moving further on the path.

This decision tree representation form is very beneficial to the analyst. The first advantage is that by using this form the

analyst is able to depict all the given parameters in a logical format which enables the simplification of the whole

decision process as now there is a very remote chance of committing an error in the decision process as all the options

are clearly specified in one of the most simplest manner.

Secondly it also aids the analyst about those decisions, which can only be taken when couple or more conditions should

hold true together for there may be a case where other conditions are relevant only if one basic condition holds true.

100

In our day-to-day life, many a times we come across complex cases where the most appropriate action under several

conditions is not apparent easily and for such a case a decision tree is a great aid. Hence this representation is very

effective in describing the business problems involving more then one dimension and parameters.

They also point out the required data, which surrounds the decision process. All the data used in the decision making

should be first described and defined by the analyst so that the system can be designed to produce correct output data.

Consider for example the discount policy of a saree manufacturer for his customers. According to the policy the saree

manufacturer give discount to his customers based on the type of customer and size of their order. For the individual,

only if the order size is 12 or more, the manufacturer gives a discount of 50% and for less than 12 sarees the discount is

30%. Whereas in case of shopkeeper or retailers, the discount policy is different. If the order is less than 12 then there is

15% discount. For 13 to 48 sarees order, the discount is 30%, for 49 to 84 sarees 40% and for more than 85 sarees the

discount is 50%. The decision policy for discount percentage can be put in the form of a decision tree displayed in the

following figure.

The decision trees are not always the most appropriate and the best tool for the decision making process. Representing a

very complex system with this tool may lead to a huge number of branches with a similar number of possible paths and

101

options.

For a complex problem, analyzing various situations is very difficult and can confuse the analyst.

Decision Tables

A decision table is a table with various conditions and their corresponding actions. Decision tree is a two dimensional

matrix. It is divided into four parts, condition stub, action stub, condition entry, and action entry. See the first figure

listed below. Condition stub shows the various possible conditions.

Condition entry is used for specifying which condition is being analyzed. Action stub shows the various actions taken

against different conditions.

And action entry is used to find out which action is taken corresponding to a particular set of conditions.

The steps to be taken for a certain possible condition are listed by action statements. Action entries display what specific

actions to be undertaken when selected conditions or combinations of conditions are true. At times notes are added

below the table to indicate when to use the table or to distinguish it from other decisions tables.

The right side columns of the table link conditions and actions and form the decision rules hence they state the

conditions that must be fulfilled for a particular set of actions to be taken. In the decision trees, a fixed ordered sequence

is followed in which conditions are examined. But this is not the case here as the decision rule incorporates all the

required conditions, which must be true.

Developing Decision Tables

Before describing the steps involved in building the decision table it is important to take a note of few important points.

Every decision should be given a name and the logic of the decision table is independent of the sequence in which

condition rules are written but the action takes place in the order in which events occur. Wherever possible, duplication

of terms and meaning should be avoided and only the standardized language must be used.

The steps of building the concerned tables are given below.

1. Firstly figure out the most essential factors to be considered in making a decision.

This will identify the conditions involved in the decision. Only those conditions should be selected which have

the potential to either occur or not but partial occurrences are not permissible.

2. Determine the most possible steps that can take place under varying conditions and not just under current

condition. This step will identify the actions.

3. Calculate all the possible combinations of conditions.

For every N number of conditions there are 2*2*2…. (N times) combinations to be considered.

102

4. Fill the decision rules in the table.

Entries in a decision table are filled as Y/N and action entries are generally marked as "X". For the conditions

that are immaterial a hyphen "-" is generally put. Decision table is further simplified by eliminating and

consolidating certain rules. Impossible rules are eliminated. There are certain conditions whose values do not

affect the decision and always result in the same action. These rules can be consolidated into a single rule.

Example: Consider the recruitment policy of ABC Software Ltd.

It the applicant is a BE then recruit otherwise not. If the person is from Computer Science, put him/her in the software

development department and if the person is from non-computer science background put him/her in HR department. If

the Person is from Computer Science and having experience equal to or greater than three years, take him/her as Team

leader and if the experience is less than that then take the person as Team member. If the person recruited is from non

Computer Science background, having experience less than three years, make him/her Management Trainee otherwise

Manager.

Condition Stub Condition Entry

1 2 3 4 5 6

Customer is individual ? Y Y . . . .

Customer shopkeeper or retailer ? . . Y Y Y Y

Order-size 85 copies or more ? . . Y . . .

Order-size 49-84 sarees ? . . . Y . .

Order-size 13-48 copies ? . . . . Y .

Order-size 12 or more ? . Y . . . .

Order-size less than 12? Y . . . . Y

Allow 50% discount . X X . .

Allow 40% discount . . . X . .

Allow 30% discount X . . . X .

Allow 15% discount . . . . . X

Decision table-Discount Policy

103

The first decision table for the problem stated above can be drawn as shown in the figure below.

This table can further be refined by combining condition entries 2, 4, 6, and 8. The simplified table is displayed in the

figure below.

104

Structured English

Structured English is one more tool available to the analyst. It comes as an aid against the problems of ambiguous

language in stating condition and actions in decisions and procedures. Here no trees or tables are employed, rather with

narrative statements a procedure is described. Thus it does not show but states the decision rules. The analyst is first

required to identify the conditions that occur in the process, subsequent decisions, which are to be made and the

alternative actions to be taken.

Here the steps are clearly listed in the order in which they should be taken. There are no special symbols or formats

involved unlike in the case of decision trees and tables, also the entire procedure can be stated quickly as only English

like statements are used.

Structured English borrows heavily from structured programming as it uses logical construction and imperative

statements designed to carry out instructions for actions. Using "IF", "THEN", "ELSE" and "So" statement decisions are

made. In this structured description terms from the data dictionary are widely used which makes the description compact

and straight.

Developing Structured Statements

Three basic types of statements are employed to describe the process.

1. Sequence Structures - A sequence structure is a single step or action included in a process. It is independent of the

existence of any condition and when encountered it is always taken. Usually numerous such instructions are used

together to describe a process.

2. Decision Structures - Here action sequences described are often included within decision structures that identify

conditions. Therefore these structures occur when two or more actions can be taken as per the value of a specific

105

condition. Once the condition is determined the actions are unconditional.

An example of Structured English

3. Iteration Structures- these are those structures, which are repeated, in routing operations such as DO WHILE

statements.

The decision structure of example discussed in previous sections may be given in structured English as in the figure

shown above.

Data Dictionary

As the name suggests the data dictionary is a catalog or repository of data terms such as data elements, data structures

etc. Data dictionary is a collection of data to be captured and stored in the system, inputs to the systems and outputs

generated by the systems. So let's first know more about what are these data elements and structures.

Data element

The smallest unit of data, which can not be further decomposed, is known as a data element. For example any number

digit or an alphabet will qualify to be data elements. Data element is the data at the most fundamental level. These

elements are used to as building blocks for all other data in the system. At times data elements are also referred as data

item, elementary item or just as field. There is a very little chance that only by them data element can convey some

meaning.

Data structure

Data elements when clubbed together as a group make up a data structure. These data elements are related to one

another and together they stand for some meaning. Data structures are used to define or describe the system's

components.

106

Data dictionary entries consist of a set of details about the data used or produced in the system such as data flows, data

stores and processes. For each item the dictionary records its name, description, alias and its length. The data dictionary

takes its shape during the data flow analysis and its contents are used even till the system design. It very reasonable to

know why the data dictionary is so essential. There are numerous important reasons.

In a system there is data volume flow in the form of reports, documents etc. In these transact ions either the existing data

is used or new data items are created. This poses a potential problem for the analyst and thus developing and using a

well-documented dictionary can be a great help.

Now consider a case where everyone concerned with the system derives different meanings for the same data items.

This problem can continue until the meaning of all data items and others are well documented so that everyone can refer

to the same source and derive the same common meaning.

Documentation in data dictionary is further carried on to record about the circumstances of the various process of the

system. A data dictionary is always an added advantage for the system analysis. From the data dictionary one can

determine about the need of the new features or about the changes required. Thus they help in evaluating the system and

in locating the errors about the system description, which takes place when the contents of the dictionary are themselves

not up to the mark.

CASE / Computer Aided Software Engineering Tools

A tool is any device, object or a kind of an operation used to achieve a specific task. The complete and correct

description of the system is as important as the system itself. The analyst uses case tool to represent and assemble all the

information and the data gathered about the system.

Most of the organizations have to follow some kind of procedures and they are required to make all sorts of decisions

from time to time. For the job of the analyst both these procedures and decision-making processes of the business

system under investigation are equally important.

Expressing business processes and rules in plain text is very cumbersome and difficult process. It requires a lot of effort.

Moreover, it does not guarantee if the reader will understand it well. So representing these things graphically is a good

choice. So CASE Tools are useful in representing business rules and procedures of organization in graphical way. It

requires less effort and it is easy to understand.

Some CASE tools are designed for creating new applications and not for maintaining or enhancing existing ones hence

if an organization is in a maintenance mode, it must have a CASE tool that supports the maintenance aspect of the

software developed. Many a times the large projects are too big to be handled by a single analyst thus here the CASE

too must be compatible enough to allow for partitioning of the project.

Efficient and better CASE tools collect a wide range of facts, diagrams, and rules, report layouts and screen designs.

The CASE tool must format the collected data into a meaningful document ready to use.

Tools for DFD or a data flow diagram is a perfect example of a good CASE tool and it will be dealt in

107

the later sessions.

Fact Finding Techniques - Case Study : Library Management System

In chapter 3 Preliminary Analysis , we discussed how the analyst performed the preliminary analysis. But we didn't look

into the actual methods that the analyst employed to gather the information about the system. In our case the analyst

used on-site observations, interviewed the staff members and used questionnaires for both staff and members of the

library. Now, we will see how our analyst employed these methods.

Fact Finding Techniques

On-site Observation

Our analyst wanted to see the functioning of library. So analyst visited the library for two days and observed librarian

issuing and returning books. The analyst also inspected the place where the cards are stored and from that it was seen

that it was a real mess. To see if a particular book is already issued, it is a difficult and effort intensive process. The

analyst also saw the records for books, members, and accounts. From site visit our analyst had a good understanding of

the functioning of the system. After this, the analyst performed some personal interviews of library staff and few

members. In the next section we'll look at these interviews.

Interviews

Interviews are useful to gather information from individuals. Given below is the interview between the analyst and one

of the librarians, during the information gathering stage of the development of our library system.

Analyst's interview with Librarian

Analyst: Hi, I have come to talk to you regarding the functioning of your library.

Librarian: Hello, do come in. I was expecting you.

Analyst: I'll come straight to the point. Don't hesitate, you can be as much open you want. There are no restrictions.

Librarian: I'll give you my whole contribution

Analyst: Tell me are you excited about the idea of having an automated system for your library?

Librarian: Yes, I do. Very much. After all it's gonna reduce our loads of work.

Analyst: Will you elaborate on it?

Librarian: Major problem is managing the cards of members. There are so many of them. Many times cards get lost.

Then we have to issue a duplicate card for it. But there is a flaw in it. It is difficult to find out if it is genuinely the case.

Member can lie about it so that he/she gets an extra card. And we can't do anything about it.

108

Analyst: What do you think be ideal solution to this?

Librarian: There should be no cards at all. All the information should be put into computer. It'll be easy for us to check

how many books we have already to a particular member.

Analyst: How often you get new members?

Librarian: Very often. At about 50 to 100 members in a month. But for two months we have freezed the membership

because it is already very difficult to manage the existing 250 members. But if this whole system gets computerised then

we'll open the membership. From this system, the management hopes to earn huge revenues.

Analyst: Could you explain how?

Librarian: Look every month we get about 50-100 memberships requests. After the new system is built, we will open

membership to our library. There is a membership fees to be paid. Management is planning to change the membership

criteria. It is planning to increase fee from 400 to 500 for half yearly and 1000 for the whole year. So in this way, we

plan to get huge revenues after we have an automated system.

Analyst: Do you have different member categories?

Librarian: No, we don't have any categorisation for members. All are treated at par.

Analyst: How many books are there?

Librarian: About 5000 books

Analyst: Do you people keep records for them?

Librarian: Yes.

Analyst: Do you want facility of booking a particular title in advance?

Librarian: No we don't want any such facility. It is an overhead. So we don't have any such facility presently.

Analyst: How do you categorise your books?

Librarian : By subject.

Analyst: Would you prefer online registration for users rather than the printed form?

Librarian: Yes , we really would. Sometimes we lose these forms then we don't have any information about that

particular member. It will be better to have it on computer.

Analyst: Do you have any other expectation or suggestion for the new system?

109

Librarian: It should be able to produce reports faster.

Analyst: Reports? I completely forgot about them. What reports you people produce presently?

Librarian: Well first is for books in the library, another for members listing, one for our current supplier of books, and

reports for finance.

Analyst: Do you have some format for them?

Librarian: Yes we do have and we want that the same format be used by the new system.

Analyst : Yes we'll take care of that. Any other suggestions?

Librarian: No. You have already covered all the fields.

Analyst: Thanks for your co-operation. It was nice talking to you.

Librarian: My pleasure. Bye.

Our analyst took interviews of few members of the library in order to know about their viewpoint about the new system.

One of such interview is given below.

Analyst interview with one member

Venue: Reading Room

Analyst: Hello. If you are free, I need to ask you few questions.

Member: Sure. I pleasure.

Analyst: Do you know the library people are planning to have an automated system?

Member: Yes , I do and I'm feeling good about it.

Analyst: Are you ready to pay more if there is a computerised system?

Member: In the overall functioning is going to improve then I think no one will object to paying more. It should help us

finding the books easily. But by what amount, it should matter.

Analyst: Well as far as I know they are planning to hike the membership fee from 400 to 500 for half year and 1000 for

full year.

Member: That would be too much. Then in that case, they should increase the number of books to be issued. Also the

number of days a book can be kept by member should also be increased.

110

Analyst: What you do think, how much books to be allowed for issue and for how many days.

Member: Well these people should increase number of books from 3 to at least 4. And the number of days for which a

book is kept should be increased by 4 days. Presently it is for 10 days. It should be 14 days. Only then the fee

hike will be justified.

Analyst: Yes, they have such plans.

Member: Then it should not bother members.

Analyst: Are you keen on online registration of members instead of normal paper one?

Member: Yes. It'll be a good practice.

Analyst: Should there be a facility to reserve a book in advance?

Member: Presently they have many copies of a single title. Usually a book is always available. I never have felt the need

to reserve a book in advance.

Analyst: On what basis a book should be categorised?

Member: Well, it should be on the basis of subject.

Analyst: What do you think on what basis a search for a particular book can be done?

Member: It can be searched using subject or title.

Analyst: How often you visit this library?

Member: Daily

Analyst: Do you think magazines and cassettes should be made available in the library?

Member: I think it's a good idea.

Analyst: Do you like this library?

Member: Yes, very much. That's why I come here daily.

Analyst: Have you ever recommended this library to your friends, relatives, or to your acquaintances?

Member: Yes I very often do.

Analyst: Till now, to how many you have recommended?

111

Member: About 30 people.

Analyst: And how many of them have actually become its members?

Member: 25 people.

Analyst: That's really nice. People actually take your recommendation very seriously. Thank You. It was nice talking to

you.

Member: Thank You.

After interviewing different people, analyst got to know about their opinions.

Questionnaires

Since the time was less it was not practical to interview every library staff. So to get the opinion of all staff, the analyst

distributed questionnaires to all of them.

The questionnaire for library staff

Instructions: Answer as specified by the format. Put NA for non-applicable situation.

1. What are your expectations out of the new system (computer based)? Rate the following on a scale of 1-4 giving a

low value for low priority.

a) better cataloguing

b) better managing of users

c) better account and books management

d) computer awareness

e) any other _____________

2. How many users are you expecting?

_____________________

3. How many books are there in library?

____________________

4. How you want the books to be categorized for searching (like by title, author name or by

subject) ?

_____________________

_____________________

_____________________

5. Is there any difference in the roles (privileges) of two members?

Yes\No Please specify if Yes

112

________________________________________________________________

________________________________________________________________

6. Do you want facility of booking a title in advance

Yes\No

7. Do you have data of book entered into some kind of database?

Yes\No

8. How do you want users to be categorized?

__________________ or

__________________

9. Would you like online registration for users rather than printed form?

Yes/No

10. Do you already have some existing categorization of books on the basis as specified in question 4 above

Yes/ No

11. Any other specific suggestion / expectation out of the proposed system.

________________________________________________________

________________________________________________________

Questionnaire for library members

In order to get the views of the existing members, the analyst also distributed questionnaires to the member also. The

questionnaires used by analyst for the library members is shown in fig 4.8 .

Instruction: Answer as specified by the format. Put NA for non-applicable situation.

1. Are you willing to pay extra for a library if it is fully computerized and eases finding of

book, etc.

Yes\No

___________________ ( if Yes, how much extra are you willing to pay)

2. What you feel should be necessary for a book to be searched?

( by topic, by title, by author ,…. )

___________________

___________________

___________________

___________________

3. Are you keen on online registration instead of the normal paper one.

Yes/No

113

4. How many titles do you feel should be issued to a single member?

______________

5. What should be the maximum duration for the issue of certain book to a member?

_______ Days.

6. Should there be a facility to reserve a book in advance?

Yes/No

7. How often do you visit the library? Choose One.

a) daily

b) once in two days

c) weekly

d) bi-weekly

e) monthly

8. Should there be a facility to reserve a book on phone?

Yes/No

9. Should magazines and cassettes be included in the library

Yes/No

10. Do you recommend this library to your friends, relatives, or acquaintances?

Yes/No (if yes, to how many you recommended and out of them how many actually became the members)

Recommended :_____________ Became Members : _________________

Now we'll look at the techniques that the analyst employed to document the various business rules of the library.

Analyst identified the following business rules.

1) Procedure for becoming a member of library.

Anyone whose age is 18 or more than that can become a member of library. There are two types of memberships

depending upon the duration of membership. First is for 6 months and other is for 1 year. 6 months membership fee is

Rs 500 and 1 year membership fee is Rs 1000.

The decision tree illustrating the business rule is given below.

114

Is Age < 18 Y . .

Age > = 18 . Y Y

Is Memebership for 6 months ? . Y .

Is Memebership for 12 months ? . . Y

Grant Membership . X X

Deny Membership X . .

Charge Membership Rs. 500 . X .

Charge Membership Rs. 1000 . . X

Fig 4.10 Decision table for membership rule

2) Rule for Issuing Books

If the number of books already issued is equal to 4 then no more books is issued to that member. If it is less than 4 then

that book is issued.

115

Now the analyst has a good understanding of the requirements for the new system, we can move to the designing.

Design of the system will be discussed in the later chapters.

Functional Modeling

At the end of this chapter you will be able to know about functional modeling of system. You will also be able to know

about the design elements of the system.

Functional Requirements

Design elements

Modules

Processes

Input(s) and Output(s)

Design of Databases

Interfaces

Functional Modeling Techniques

Data Flow Diagrams

Elements of Data Flow Diagrams - Processes, External Entities, Data Flow, Data Stores

An Example of a DFD for a System That Pays Workers

Conventions used when drawing DFD's

116

DFD Example - General model of publisher's present ordering system

Data Dictionary

The procedure for producing a data flow diagram

Functional Requirements

After the thorough analysis of the system is done, the design process for the proposed system starts.

Designing of the system includes making the conceptual layout of the system using various modeling

techniques available and coding the proposed system for actual implementation.

The first step after the analysis of the system is making the conceptual design. Conceptual design consists of

two elements: data model and functional models.

Data modeling is a technique for organizing and documenting system's data. Process model is a technique for

organizing and documenting a system's processes, inputs, outputs and data stores. Generally, these models

give the following information.

What all processes make up a system?

What data are used in each process?

What data are stored?

What data enter and leave the system?

Information is transformed as it flows through a computer-based system. As we already know, information

transformation basically consists of: input, process and output. The system accepts input in variety of forms;

applies hardware, software, and human elements to transform input into output; and produces output in a

variety of forms. The transform(s) may comprise a single logical comparison, a complex numerical algorithm

or rule-inference approach of an expert system. We can create a flow model for any computer-based system,

regardless of size and complexity.

By flow models, we get to know the functionality of a system.

Data flow diagram is one of the tools used in the analysis phase. Data flow diagram is a graphical tool used to

analyze the movement of data through a system-manual or automated-including the processes, stores of data,

and delay in the system. The transformation of data from input to output, through processes, may be described

logically and independently of the physical components (for example, computers, file cabinets, disk units, and

word processors).

117

Structure chart is another tool used in designing phase of the life cycle

See Also

Design elements

Functional Modeling Techniques

Data Flow Diagrams

Elements of Data Flow Diagrams

An Example of a DFD

Conventions used when drawing DFD's

Data Dictionary

The procedure for producing a data flow diagram

Design Elements in Functional Modeling

This section describes the various design elements. These include

1. Modules

2. Processes

3. Inputs and Outputs

4. Design of Databases and Files

5. Interfaces

See Also

Functional Requirements

Functional Modeling Techniques

Data Flow Diagrams

Elements of Data Flow Diagrams

An Example of a DFD

Conventions used when drawing DFD's

Data Dictionary

The procedure for producing a data flow diagram

Modules

As discussed in lesson 1 - Introduction to Systems, a large system actually consists of various small

independent subsystems that combine together to build up the large systems. While designing the system too,

the complete system is divided into small independent modules which may further be divided if the need be.

Such independent modules are designed and coded separately and are later combined together to make the

system functional.

For the better understanding and design of the system, it should be made as a hierarchy of modules. Lower

118

level modules are generally smaller in scope and size compared to higher level modules and serve to partition

processes into separate functions. Following factors should be considered while working on modules:

Size:

The number of instructions contained in a module should be limited so that module size is generally small.

Shared use:

Functions should not be duplicated in separate modules, but established in a single module that can be

invoked by any other module when needed.

Other Design Elements

Processes

Inputs and Outputs

Design of Databases and Files

Interfaces

Processes

As already discussed, a system consists of many subsystems working in close coordination to achieve a

specific objective. Each of these subsystems carries out a specific function and each of these functions may in

turn be consisting of one or more processes.

Thus the system's functions can be subdivided into processes, as depicted by fig. 5.1. A process is a specific

act that has definable beginning and ending points. A process has identifiable inputs and outputs. Create

purchase requisition, follow up order etc are few examples of processes. For designing of any system, these

processes need to be identified as a part of functional modeling.

119

Fig 5.1 - Functional Decomposition

Source: Information Engineering: Planning & Analysis by James Martin

Every process may be different from the other but each of them has certain common characteristics, as:

A process is a specified activity in an enterprise that is executed repeatedly. This means that the

processes are ongoing, for example, generation of bills may be labeled as a process for a warehouse as

it is repeatedly carried out

A process can be described in terms of inputs and outputs. Every process would have certain inputs

required which are transformed into a certain output. For example, in case of a warehouse,

information related to the sale of various items is required for generation of bills. This information is

taken as input and the bills generated are the output of the process.

A process has definable starting and ending points.

A process is not based on organizational structures and is carried out irrespective of this structure.

A process identifies what is done, not how.

Other Design Elements

Input(s) and Output(s)

As discussed earlier, inputs and outputs are an important part of any system, so while designing a system

inputs and outputs of the system as a whole need to be identified and the inputs and outputs for the various

processes of the system need to be listed down.

During design of input, the analyst should decide on the following details:

What data to input

120

What medium to use

How data should be arranged

How data should be coded i.e. data representation conventions

The dialogue to guide users in providing input i.e. informative messages that should be provided when

the user is entering data. Like saying, "It is required. Don't leave it blank."

Data items and transactions needing validation to detect errors

Methods for performing input validation and steps to follow when errors occur

The design decisions for handling input specify how data are accepted for computer processing. The design of

inputs also includes specifying the means by which end-users and system operators direct the system in

performing actions.

Output refers to the results and information that are generated by the system. In many cases, output is the

main reason for developing the system and the basis on which the usefulness of the system is evaluated. Most

end-users will not actually operate the information system or enter data through workstations, but they will

use the output from the system.

While designing the output of system, the following factors should be considered:

Determine what information to present

Decide on the mode of output, i.e. whether to display, print, or "speak" the information and select the

output medium

Arrange the presentation of information in an acceptable format

Decide how to distribute the output to intended recipients

These activities require specific decisions, such as whether to use preprinted forms when preparing reports

and documents, how many lines to plan on a printed page, or whether to use graphics and color. The output

design is specified on layout forms, sheets that describe the location characteristics (such as length and type),

and format of the column heading, etc.

Design of Databases and Files

Once the analyst has decided onto the basic processes and inputs and outputs of the system, he also has to

decide upon the data to be maintained by the system and for the system. The data is maintained in the form of

data stores, which actually comprise of databases.

Each database may further be composed of several files where the data is actually stored. The analyst, during

the design of the system, decides onto the various file-relating issues before the actual development of the

system starts.

The design of files includes decisions about the nature and content of the file itself such as whether it is to be

used for storing transaction details, historical data, or reference information.

Following decisions are made during file design:

121

Which data items to include in a record format within the file?

Length of each record, based on the characteristics of the data items

The sequencing or arrangement of records within the file (the storage structure, such as sequential,

indexed, or relative)

In database design, the analyst decides upon the database model to be implemented.Database model can be

traditional file based, relational, network, hierarchical, or object oriented database model. These data models

are discussed in detail in lesson 7 on Data Modeling.

Interfaces - Designing the Interfaces

Systems are designed for human beings to make their work simpler and faster. Hence interaction of any

system with the human being should be an important area of concern for any system analyst. The analyst

should be careful enough to design the human element of the system in such a manner that the end user finds

the system friendly to work with. Interface design implies deciding upon the human computer interfaces. How

the end user or the operator will interact with the system. It includes designing screens,menus, etc.

122

Fig 5.2 Basic Steps in system design

The following factors should be considered while working on interfaces.

Use of a consistent format for menu, command input, and data display.

Provide the user with visual and auditory feedback to ensure that two-way communication is

established.

Provide undo or reversal functions.

Reduce the amount of information that must be memorized between actions.

Provide help facilities that are context sensitive.

Use simple action verbs or short verb phrases to name commands.

Display only that information that is relevant to the current context.

Produce meaningful error messages.

Use upper and lower case, indentation, and text grouping to aid in understanding.

Produce meaningful error messages.

123

Maintain consistency between information display and data input. The visual characteristics of the display

(e.g., text size, color, and placement) should be carried over to the input domain.

Interaction should be flexible but also tuned to user's preferred mode of input.

Deactivate commands that are inappropriate in the context of current actions.

Provide help to assist with all input actions

Functional Modeling Techniques

Now that we are familiar with the various design elements, let us take a look at the modeling techniques that

are used for designing the systems. Data Flow Diagrams are used for functional modeling. As the name

suggests, it is a diagram depicting the flow of data through the system. In the coming sections, we'll explore

this technique in detail.

Data Flow Diagrams

Elements of Data Flow Diagrams - Processes, External Entities, Data Flow, Data Stores

An Example of a DFD for a System That Pays Workers

Conventions used when drawing DFD's

DFD Example - General model of publisher's present ordering system

Data Dictionary

The procedure for producing a data flow diagram

Data Flow Diagrams (DFD)

Data Flow Diagrams - DFD (also called data flow graphs) are commonly used during problem analysis. Data

Flow Diagrams (DFDs) are quite general and are not limited to problem analysis for software requirements

specification. They were in use long before the software engineering decipline begin. DFDs are very useful in

understanding a system and can be effectively used during analysis.

A DFD shows the flow of data through a system. It views a system as a function that transforms the inputs

into desired outputs. Any complex system will not perform this transformation in a "single step", and a data

will typically undergo a series of transformations before it becomes the output. The DFD aims to capture the

transformations that take place within a system to the input data so that eventually the output data is

produced. The agent that performs the transformation of data from one state to another is called a process (or

a bubble). So a DFD shows the movement of data through the different transformation or process in the

system.

DFDs are basically of 2 types: Physical and logical ones. Physical DFDs are used in the analysis phase to

study the functioning of the current system. Logical DFDs are used in the design phase for depicting the flow

124

of data in proposed system.

Elements of Data Flow Diagrams

An example of a DFD for a system

Coventions used when drawing DFD's

DFD Example - General model of publisher's present ordering system

Elements of Data Flow Diagrams

Data Flow Diagrams are composed of the four basic symbols shown below.

The External Entity symbol represents sources of data to the system or destinations of data from the

system.

The Data Flow symbol represents movement of data.

The Data Store symbol represents data that is not moving (delayed data at rest).

The Process symbol represents an activity that transforms or manipulates the data (combines, reorders,

converts, etc.).

Any system can be represented at any level of detail by these four symbols.

External Entities

External entities determine the system boundary. They are external to the system being studied. They are

often beyond the area of influence of the developer.

These can represent another system or subsystem. These go on margins/edges of data flow diagram. External

entities are named with appropriate name.

Processes

Processes are work or actions performed on incoming data flows to produce outgoing data flows. These show

data transformation or change. Data coming into a process must be "worked on" or transformed in some way.

125

Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be

shown at more detailed levels of the diagrams. Each process in always "running" and ready to accept data.

Major functions of processes are computations and making decisions. Each process may have dramatically

different timing: yearly, weekly, daily.

Naming Processes

Processes are named with one carefully chosen verb and an object of the verb. There is no subject. Name is

not to include the word "process". Each process should represent one function or action. If there is an "and" in

the name, you likely have more than one function (and process). For example, get invoice ,update customer

and create Order Processes are numbered within the diagram as convenient. Levels of detail are shown by

decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-

14.4, and next level with Processes 14.3.1-14.3.6. Processes should generally move from top to bottom and

left to right.

Data Flow

Data flow represents the input (or output) of data to (or from) a process ("data in motion"). Data flows only

data, not control. Represent the minimum essential data the process needs. Using only the minimum essential

data reduces the dependence between processes. Data flows must begin and/or end at a process.

Data flows are always named. Name is not to include the word "data". Should be given unique names. Names

should be some identifying noun. For example, order, payment, complaint.

Data Stores

or

Data Stores are repository for data that are temporarily or permanently recorded within the system. It is an

"inventory" of data. These are common link between data and process models. Only processes may connect

with data stores.

There can be two or more systems that share a data store. This can occur in the case of one system updating

the data store, while the other system only accesses the data.

126

Data stores are named with an appropriate name, not to include the word "file", Names should consist of

plural nouns describing the collection of data. Like customers, orders, and products. These may be duplicated.

These are detailed in the data dictionary or with data description diagrams.

Related Topics

Functional Modeling Techniques

Data Flow Diagrams

Elements of Data Flow Diagrams - Processes, External Entities, Data Flow, Data Stores

An Example of a DFD for a System That Pays Workers

Conventions used when drawing DFD's

DFD Example - General model of publisher's present ordering system

Data Dictionary

The procedure for producing a data flow diagram

An Example of a DFD for a System That Pays Workers

An example of a Data Flow Diagram - DFD for a system that pays workers is shown in the figure below. In

this DFD there is one basic input data flow, the weekly time sheet, which originates from the source worker.

The basic output is the pay check, the sink for which is also the worker. In this system, first the employee's

record is retrieved, using the employee ID, which is contained in the time sheet. From the employee record,

the rate of payment and overtime are obtained.

These rates and the regular and overtime hours (from the time sheet) are used to complete the payment. After

total payment is determined, taxes are deducted. To computer the tax deduction, information from the tax

rate file is used. The amount of tax deducted is recorded in the employee and company records. Finally, the

paycheck is issued for the net pay. The amount paid is also recorded in company records.

127

DFD of a system that pays workers.

Conventions used when drawing DFD's

Some conventions used when drawing DFD's should be explained. Assuming the example DFD explained

earlier all external files such as employee record, company record and tax rates are shown as a one side open

rectangle. The need for multiple data flow by a process is represented by a * between the data flows. The

symbol represents the AND relationship. For example, if there is a * between the two input data flow A and B

for process, it means that A AND B are needed for the process. In the DFD, for the process "weekly pay" the

data flow "hours" and "pay rate" both are needed, as shown in the DFD. Similarly, the OR relationship is

represented by "+" between the data flows.

It should be pointed out that a DFD is not a flowchart. A DFD represents that flow of data, while flow chart

128

shows the flow of control. A DFD does not represent procedural information. So, while drawing a DFD, one

must not get involved in procedural details, and procedural thinking must be consciously avoided.

For example,

Consideration of loops and decisions must be ignored. In drawing the DFD the designer has to specify major

transforms in the path of the data flowing from the input to output. How those transforms are performed is not

an issue while drawing the data flow graph. There are no detailed procedures that can be used to draw a DFD

for a given problem. Only some directions can be provided. One way to construct a DFD is to start by

identifying the major inputs and outputs. Minor inputs and outputs (like error messages) should be ignored at

first. Then starting from the inputs, work towards the outputs, identifying the major inputs (remember that is

is important that procedural information like loops and decision not be shown in DFD, and designer should

not worry about such as issues while drawing the DFD).

Following are some suggestion for constructing a data flow graph

1. Klork your way consistently from the inputs to the outputs, or vice versa. If you get stuck, reverse

direction. Start with a high level data flow graph with few major transforms describing the entire

transformation from the inputs to outputs and then refine each transform with more detailed

transformation.

2. Never try to show control logic. If you find yourself thinking in terms of loops and decisions, it is time

to stop and start again.

3. Label each arrow with proper data elements. Inputs and outputs of each transform should be carefully

identified.

4. Make use of * and + operation and show sufficient detail in the data flow graph.

5. Try drawing alternate data flow graphs before setting on one.

Many systems are too large for a single DFD to describe the data processing clearly. It is necessary that some

decomposition and abstraction mechanism be used for such systems. DFDs can be hierarchically organized,

which helps in progressively partitioning and analyzing large systems. Such DFDs together are called a

leveled DFD set.

Related Topics

DFD Example - General model of publisher's present ordering system

Following are the set of DFDs drawn for the General model of publisher's present ordering system.

129

First Level DFD

Second Level DFD - Showing Order Verification & credit check

Third Level DFD - Elaborating an order processing & shipping

130

Fourth level DFD : Completed DFD, Showing Account Receivable Routine.

From the level one it shows the publisher's present ordering system. Let's expand process order to elaborate

on the logical functions of the system. First, incoming orders are checked for correct book titles, author's

names, and other information and then batched into other book orders from the same bookstore to determine

how may copies can be shipped through the ware house. Also, the credit status of each book stores is checked

before shipment is authorized. Each shipment has a shipping notice detailing the kind and numbers of booked

shipped. This is compared to the original order received (by mail or phone) to ascertain its accuracy. The

details of the order are normally available in a special file or data store, called "Bookstore Orders". It is

shown in the second level DFD diagram.

Following the order verification and credit check, a clerk batches the order by assembling all the book titles

ordered by the bookstore. The batched order is sent to the warehouse with authorization to pack and ship the

books to the customer. It is shown in the third level DFD diagram.

131

Further expansion of the DFD focuses on the steps in billing the bookstore shown in the fourth level DFD,

additional functions related to accounts receivable.

Data Dictionary

In our data flow diagrams, we have given names to data flows, processes and data stores. Although the

names are descriptive of the data, thy do not give details. So following the DFD, our interest is to build some

structures place to keep details of the contents of data flows, processes and data stores. A data dictionary is a

structured repository of data about data. It is a set of rigorous definitions of all DFD data elements and data

structures.

To define the data structure, different notations are used. These are similar to the notations for regular

expression. Essentially, besides sequence or composition ( represented by + ) selection and iteration are

included. Selection ( represented by vertical bar "|" ) means one or the other, and repitition ( represented by

"*" ) means one or more occurances.

The data dictionary for this DFD is shown below:

Weekly timesheet = Emplyee_Name + Employee_ID + {Regular_hours + overtime_hours}

Pay_rate = {Horly | Daily | Weekly} + Dollar_amount

Employee_Name = Last + First + Middle_Initial

Employee_ID = digit + digit + digit + digit

Most of the data flow in the DFD are specified here. Some of the most obvious ones are not shown here. The

data dictionary entry for weekly timesheet specifies that this data flow is composed of three basic data

entities - the employee name, employee ID and many occurrences of the two - tuple consisting of regular

hours and overtime hours. The last entity represents the daily working hours of the worker. The data

dictionay also contains entries for specifying the different elements of a data flow.

Once we have constructed a DFD and its associated data dictionary, we have to somehow verify that they are

"correct". There can be no formal verification of a DFD, because what the DFD is modeling is not formally

specify anywhere against which verification can be done. Human processes and rule of thumb must be used

for verification. In addition to the walkthrough with the client, the analyst should look for common errors.

Some common errors are

1. Unlabeled data flows.

2. Missing data flows: Information required by a process is not available.

3. Extraneous data flows: Some information is not bein used in the process

4. Consistency not maintained during refinement

132

5. Missing processes

6. Contains some control information

The DFDs should be carefully scrutinized to make sure that all the processes in the physical environment are

shown in the DFD. It should also be ensured that none of the data flows is actually carrying control

information.

The procedure for producing a data flow diagram

Identify and list external entities providing inputs/receiving outputs from system;

Identify and list inputs from/outputs to external entities;

Draw a context DFD

Defines the scope and boundary for the system and project

1. Think of the system as a container (black box)

2. Ignore the inner workings of the container

3. Ask end-users for the events the system must respond to

4. For each event, ask end-users what responses must be produced by the system

5. Identify any external data stores

6. Draw the context diagram

i. Use only one process

ii. Only show those data flows that represent the main objective or most common inputs/outputs

identify the business functions included within the system boundary;

identify the data connections between business functions;

confirm through personal contact sent data is received and vice-versa;

trace and record what happens to each of the data flows entering the system (data movement, data

storage, data transformation/processing)

Draw an overview DFD

- Shows the major subsystems and how they interact with one another

- Exploding processes should add detail while retaining the essence of the details from the more

general diagram

- Consolidate all data stores into a composite data store

Draw middle-level DFDs

- Explode the composite processes

Draw primitive-level DFDs

- Detail the primitive processes

- Must show all appropriate primitive data stores and data flows

verify all data flows have a source and destination;

verify data coming out of a data store goes in;

review with "informed";

explode and repeat above steps as needed.

133

Balancing DFDs

Balancing: child diagrams must maintain a balance in data content with their parent processes

Can be achieved by either:

exactly the same data flows of the parent process enter and leave the child diagram, or

the same net contents from the parent process serve as the initial inputs and final outputs for the child

diagram or

the data in the parent diagram is split in the child diagram

Rules for Drawing DFDs

A process must have at least one input and one output data flow

A process begins to perform its tasks as soon as it receives the necessary input data flows

A primitive process performs a single well-defined function

Never label a process with an IF-THEN statement

Never show time dependency directly on a DFD

Be sure that data stores, data flows, data processes have descriptive titles. Processes should use

imperative verbs to project action.

All processes receive and generate at least one data flow.

Begin/end data flows with a bubble.

Rules for Data Flows

A data store must always be connected to a process

Data flows must be named

Data flows are named using nouns

" Customer ID, Student information

Data that travel together should be one data flow

Data should be sent only to the processes that need the data

Use the following additional guidelines when drawing DFDs

Identify the key processing steps in a system. A processing step is an activity that transforms one

piece of data into another form.

Process bubbles should be arranged from top left to bottom right of page.

Number each process (1.0, 2.0, etc). Also name the process with a verb that describes the information

processing activity.

Name each data flow with a noun that describes the information going into and out of a process.

What goes in should be different from what comes out.

Data stores, sources and destinations are also named with nouns.

Realize that the highest level DFD is the context diagram. It summarizes the entire system as one

bubble and shows the inputs and outputs to a system

Each lower level DFD must balance with its higher level DFD. This means that no inputs and outputs

are changed.

134

Think of data flow not control flow. Data flows are pathways for data. Think about what data is

needed to perform a process or update a data store. A data flow diagram is not a flowchart and should

not have loops or transfer of control. Think about the data flows, data processes, and data storage that

are needed to move a data structure through a system.

Do not try to put everything you know on the data flow diagram. The diagram should serve as index

and outline. The index/outline will be "fleshed out" in the data dictionary, data structure diagrams,

and procedure specification techniques

Functional Modeling - Part II

At the end of this chapter you will able to know about the modular design of the system. You will also be able to know

how to make structure charts.

Process Specification (PSPEC)

Control Flow Model

Control Specifications (CSPEC)

Structure Charts

Top Down Structure of Modules

Cohesion

Coupling

Coding

DFDs pay a major role in designing of the software and also provide the basis for other design-related issues. Some of

these issues are addressed in this chapter. All the basic elements of DFD are further addressed in the designing phase of

the development procedure

135

Process Specification (PSPEC)

A process specification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD.

The process specification describes the input to a function, the algorithm, the PSPEC indicates restrictions and

limitations imposed on the process (function), performance characteristics that are relevant to the process, and design

constraints that may influence the way in which the process will be implemented. In other words, process specification

is used to describe the inner workings of a process represented in a flow diagram.

Control Flow Model

The Hatley and Pirbhai extensions focus on the representation and specification of the control-oriented

aspects of the software. Moreover, there exists a large class of applications that are driven by events rather

than data that produce control information rather than reports or displays, and that process information with

heavy concern for time and performance.

Such an application requires the use of control flow modeling in addition to data flow modeling. For this

purpose, control flow diagram is created. The CFD contain the same processes as the DFD, but shows

control rather than data flow.

Control flow diagrams show how events flow among processes and illustrate those external events that cause

various processes to be activated. The relationship between process and control model is shown in the

figures in the sections Control Specification and Structure Charts.

Drawing a control flow model is similar to drawing a data flow diagram. A data flow model is stripped of all

data flow arrows. Events and control items are then added to the diagram a "window" (a vertical bar) into the

control specification is shown.

Control Specifications (CSPEC)

The Control Specifications (CSPEC) is used to indicate (1) how the software behaves when an event or control signal is

sensed and (2) which processes are invoked as a consequence of the occurrence of the event. The control specification

(CSPEC) contains a number of important modeling tools.

The control specification represents the behavior of the system in two ways. The CSPEC contains a state transition

diagram that is sequential specification of behavior. It also contains a process activation table (PAT) -a combinatorial

specification of behavior.

136

Fig 6.1 - The relationship between data and control models

Structure Charts

Once the flow of data and control in the system is decided using tools like DFDs and CFDs, the system is given shape

through programming. Prior to this, the basic infrastructure of the program layout is prepared based on the concepts of

modular programming.

In modular programming, the complete system is coded as small independent interacting modules. Each module is

aimed at doing one specific task. The design for these modules is prepared in the form of structure charts.

A structure chart is a design tool that pictorially shows the relation between processing modules in computer software.

Describes the hierarchy of components modules and the data are transmitted between them. Includes analysis of input-

to-output transformations and analysis of transaction.

Structure charts show the relation of processing modules in computer software. It is a design tool that visually displays

the relationships between program modules. It shows which module within a system interacts and graphically depicts

the data that are communicated between various modules.

Structure charts are developed prior to the writing of program code. They identify the data passes existing between

individual modules that interact with one another.

They are not intended to express procedural logic. This task is left to flowcharts and pseudocode. They don't describe

the actual physical interface between processing functions.

137

Notation

Program modules are identified by rectangles with the module name written inside the rectangle.

Arrows indicate calls, which are any mechanism used to invoke a particular module.

Fig 6.2 - Notation used in structure charts.

Annotations on the structure chart indicate the parameter that are passed and the direction of the data movement. In fig.

6.3, we see that modules A and B interact. Data identified as X and Y are passed to module B, which in turn passes back

Z.

138

Fig 6.3 - Annotations and data passing in structure charts

A calling module can interact with more than one subordinate module. Fig. 6.3 also shows module L calling subordinate

modules M and N. M is called on the basis of a decision point in L (indicated by the diamond notation), while N is

called on the basis of the iterative processing loop (noted by the arc at the start of the calling arrow.

Data passing

When one module calls another, the calling module can send data to the called module so that it can perform the

function described in its name. The called module can produce data that are passed back to the calling module.

Two types of data are transmitted. The first, parameter data, are items of data needed in the called module to perform the

necessary work. A small arrow with an open circle at the end is used to note the passing of data parameters. In addition,

control information (flag data) is also passed. Its purpose is to assist in the control of processing by indicating the

occurrence of, say, errors or end-of-conditions. A small arrow with a closed circle indicates the control information. A

brief annotation describes the type of information passed.

Structure chart is a tool to assist the analyst in developing software that meets the objectives of good software design.

Structure of Modules

We have discussed in the previous chapter Functional Modeling - Part I that a system may be seen as a combination of

everal small independent units. So, while designing software also, it is designed as a collection of separately named and

addressable components called modules.

This property of software is termed as modularity. Modularity is a very important feature of any software and allows a

program to be intellectually manageable. For instance, while coding small programs in 'C' also, we make a program as a

collection of small functions.

A program for finding average of three numbers may make use of a function for calculating the sum of the numbers.

Each of these can be called as a separate module and may be written by a different programmer. But once such modules

are created, different programs may use them. Thus modularity in software provides several advantages apart from

making the program more manageable.

While designing the modular structure of the program, several issues are to be paid ention. The modular structure should

reflect the structure of the problem. It should have the following properties.

1. Intra-module property: Cohesion

Modules should be cohesive.

2. Inter module property: Coupling

Modules should be as loosely interconnected as possible.

- Highly coupled modules are strongly interconnected.

139

- Loosely coupled modules are weakly connected.

- De-coupled modules exhibit no interconnection.

3. A module should capture in it strongly related elements of the problem.

Cohesion

Cohesion, as the name suggests, is the adherence of the code statements within a module. It is a measure of how tightly

the statements are related to each other in a module.Structures that tend to group highly related elements from the point

of view of the problem tend to be more modular. Cohesion is a measure of the amount of such grouping.

Cohesion is the degree to which module serves a single purpose. Cohesion is a natural extension of the information-

hiding concept. A cohesive module performs a single task within a software procedure, requiring little interaction with

procedures being performed in other parts of a program. There should be always high cohesion.

Cohesion: modules should interact with and manage the functions of a limited number of lower-level modules.

There are various types of cohesion

Functional Cohesion

Sequential Cohesion

Communicational Cohesion

Procedural Cohesion

Temporal Cohesion

Logical Cohesion

Coincidental Cohesion

Functional Cohesion

Functional cohesion is the strogest cohesion. In a functionally bound module, all elements of the module are related to

erpforming a single function. Function like "computer square root" and "sort the away" are clear examples of

functionally cohesive modules.

How does one determine the cohesion level of a module? There is no mathematical formula that can be used. We have

to use our judgement for this. A useful technique for determining if a module has a functional cohesion is to write a

sentence that describes, fully and accurately, the function or purpose of the module. The following test can be made.

140

1. If the sentence must be compound sentence, if it contains comma, or has more than one verb, the module is

probably performing more than one function, and probably has sequential or communicational cohesion.

2. If the sentence contains words relating to time like "first", "next", "when", "after", etc. Then the module probably

has sequential or temporal cohesion.

3. If the predicate of the sentence does not contain a single specific object following the verb (such as "edit all

data"). The module probably has logical cohesion.

4. Words like "Initialize and setup" imply temporal cohesion.

Sequential Cohesion

When the elements are together in a module because the output of one forms the input to another, we get sequential

cohesion. Here it doesn't provide any guidelines on how to combine them into modules.

Fig 6.4 - P and Q modules show sequential cohesion

In terms of DFD, this combines a linear chain of successive transformations. This is acceptable.

Example:

1. READ-PROCESS; WRITE RECORD

2. Update the current inventory record and write it to disk

Communicational Cohesion

A module with communicationl cohesion has elements that are related by a reference to the same input or output data.

That is, in a communicationl bound module, the elements are together because they operate on the same input or output

data. An example of this could be a module to "print and puch record". Communicational cohesive modules may be

performing more than one function. However, communicational cohesion is sufficiently big so as to be generally

acceptable if alternate structures with higher cohesion cannot be easily identified.

Communicational cohesivemodule consists of all processing elements, which act upon the same input data set and/or

produce the same output data set.

141

Fig 6.5 - Communicational Cohesion

P and Q form a single module.

Module is defined in terms of the problem structure as captured in the DFD. It is commonly found in business or

commercial applications where one asks what are the things that can be done with this data set.

Procedural Cohesion

A procedurally cohesive module contains elements that belong to a common precedural limit. For example: a loop or a

sequence of decision procedurally cohesive modules often occur when module structure is determined from some form

to flowchart, procedural cohesion, often cuts accross functional lines. A module with only procedural cohesion may

contain only part of a complete function, or parts of a several functions.

142

Fig 6.6 - Procedural Cohesion

Often found when modules are defined by cutting up flowcharts or other procedural artifacts. There is no logical

reasoning behind this. Fig 6.6 illustrates this. In this all the elements that are being used in the procedure 2 are put in the

same module. It is not acceptable. Since elements of processing shall be found in various modules in a poorly structured

way.

Temporal Cohesion

Temporal cohesion is the same as logical cohesion, except that the elements are also related in time, and are executed

together. Modules that perform activities like "initigation", "clean-up", and "termination" are usually temporarilly

bound. Eventhough the elements in a temporally bound module are logicaly related, temporal cohesion is higher than

logical cohesion, since the elements are all executed together. This will avoid the problem of passing the flag, and the

code is usually simpler.

Logical Cohesion

143

A module has logical cohesion if there is some logical relationship between the elements of a module, and the elements

perform function that fall in the same logical class. In general, logically cohesive modules should be avoided, if

possible.

Logical Cohesion is module formation by putting together a class of functions to be performed. It should be avoided.

For example, Display_error on file, terminal, printer, etc.

Fig 6.7 Logical Cohesion

Fig 6.7 shows logical cohesion. Here function Display_error is for files, terminals, and printers. Since the function is to

display error, all three functions are put into same modules.

Coincidental Cohesion

Coincidental Cohesion is module formation by coincidence. Same code is recognized as occurring in some other

module. Pull that code into a separate module. This type of cohesion should be avoided since it does not reflect problem

structure. Coincidental cohesion can occur if an exixting program is "modularized" by chopping into pieces and making

different pieces of modules.

See Also

Coupling

Coupling is a measure of interconnection among modules in a program structure. Coupling depends on the interface

complexity between modules, the point at which entry or reference is made to a module, and what data pass across the

interface. Or, simply it is Strength of the connections between modules Coupling can be represented. As the number of

different items being passed (not amount of data) rises the module interface complexity rises. It is number of different

items that increase the complexity not the amount of data.

In general, the more we must know about module A in order to understand module B, the more closely connected A is

to B "Highly coupled".

144

Modules are joined by strong interconnections, "loosely coupled" modules have weak interconnections. Independent

modules have no interconnections, for being able to solve and modify a module separately, we would like the module to

be loosely coupled with other modules. Coupling in an abstract concept and is as yet not quantifiable. So, no formulas

can be given to determine the coupling between two modules. However, some major factors can be identified as

influencing coulping between modules. Among them the most important are the type of connection between modules

and the complexity of the interface, and the type of information flow between modules.

Coupling increases with the complexity and abscurity of the interface between modules. To keep coupling low we

would like to minimize the number of interface per module. And minimize the complexity of each interface. An

interface of a module is used to pass information to and from modules. There are two kinds of information that can flow

along an interface;

1. data

2. control

Passing or recieving back control information means that the action of the module will depend on this control

information, which makes it more difficult to understand the module and provide its abstraction. Transfer of data

information means that a module passes as input some data to another module and gets in return some data as output.

Coupling may also be represented on a spectrum as shown below:

Coupling

No Direct Coupling

145

No direct coupling between M1 and M2

The modules are subordinated to different modules. Therefore, no direct coupling

Data Coupling

In this the argument list data that is passed to the module. In this type of coupling only data flows across modules. Data

coupling is minimal.

Stamp Coupling

In stamp coupling dta structure is passed via argument list

Control Coupling

Control is passed via a flag (1 bit)

Common Coupling

Common coupling occurs when there are common data areas. That is there are modules using data that are global. It

should be avoided.

146

Content Coupling

If there is data access within the boundary of another. For example, passing pointer can be considered as content

coupling or branch into the middle of a module.

One module makes use of data or control information maintained within the boundary of another module.

Coding

Structure charts provide the framework for programmers to code the various modules of the system by providing all the

necessary information about each module of the system. From here the system analyst takes a backseat and programmer

comes into action. Programmer codes each and every module of the system, which gives a physical shape to the system.

Coding phase is aimed at converting the design of the system prepared during the design phase onto the code in a

programming language, which performs the tasks as per the design requirements and is executable by a computer. The

programs should be written such that they are simple, easy to read, understand and modify.

Program should also include comment lines to increase the readability and modifiability of the program. Tools like flow

charts and algorithms are used for coding the programs. In some cases, this phase may involve installation and

modification of the purchased software packages according to the system requirements.

From here, the system goes for testing.

147

Data Modeling Techniques

At the end of this chapter you will be able to understand the concepts involve in the data modeling of a

system. You will also be able to understand the Entity Relationship Model used for data modeling.

Contents

Data Modeling and Data Requirements

E-R Data Modeling Technique

E-R Model concept, Entities and Attributes

Types of Attributes

Entity Types

Value Sets (domain) of Attributes

Entity Relationships

Data Modeling and Data Requirements

Last chapter discusses about one part of the conceptual design process, the functional model. The other is the data

model, which discusses the data related design issues of the system. See fig 7.1. The data model focuses on what data

should be stored in the database while the function model deals with how the data is processed. In this chapter, we'll

look into details of data modeling.

Fig 7.1 - Elements of conceptual design

We have already discussed the Data Flow Diagrams, which make the foundation of the system under development.

While the system is being studied, the physical DFDs are prepared whereas at the design phase, the basic layout of the

proposed system is depicted in the form of a logical DFD. Taking this DFD as the basis the system is further developed.

Even at the Data Modeling phase, the DFD can provide the basis in the form of the data flows and the Data Stores

depicted in the DFD of the proposed system. The Data Stores from the DFD are picked up and based on the data being

148

stored by them the Data Model of the system is prepared.

Prior to data modeling, we'll talk of basics of database design process. The database design process can be described as

a set of following steps. (Also see figure below 7.2 Overall Database Design Process)

Requirement collection: Here the database designer interviews database users. By this process they are able to

understand their data requirements. Results of this process are clearly documented. In addition to this, functional

requirements are also specified. Functional requirements are user defined operations or transaction like

retrievals, updates, etc, that are applied on the database.

Conceptual schema: Conceptual schema is created. It is the description of data requirements of the users. It

includes description of data types, relationships and constraints.

Basic data model operations are used to specify user functional requirements.

Actual implementation of database.

Physical database design. It includes design of internal storage structures and files.

Fig 7.2 - Overall Database Design Process

In this chapter, our main concern is data model. There are various data models available. They fall in three different

groups.

Object-based logical models

Record-based logical models

Physical-models

Object-Based Logical Models

Object-based logical models are used in describing data at the logical and view levels. The main characteristic of these

models is that they provide flexible structuring capabilities and allows data constraints to be specified explicitly. Many

different models fall into this group. They are following.

Entity-relationship model

Object-oriented model

149

In this chapter, we‘ll discuss Entity-Relationship model in detail. The object-oriented model is covered in the next

chapter.

Record-Based Logical Models

Records-based logical models are used in describing data at the logical and view levels. They are used to specify the

overall logical structure of the database and to provide a higher-level description of the implementation.

In record-based models, the database is structured in fixed-format records of several types. Each record type defines a

fixed number of fields, or attributes, and each field is usually of a fixed length. The use of fixed-length records

simplifies the physical-level implementation of the database.

The following models fall in this group.

Relational model

Network model

Hierarchical model

Relational Model

This model uses a collection of tables to represent both data and relationship among those data. Each table has multiple

columns, and each column has a unique name. Figure shows a simple relational database.

Fig 7.3 - A sample relational model

Network Model

In network database, data is represented by collection of records, and relationships among data are represented by links.

The records are organized as a collection of arbitrary graphs. Figure 7.4 represent a simple network database.

150

Fig 7.4 - A sample network model

Hierarchical Model

The hierarchical model is similar to the network model. Like network model, records and links represent data and

relationships among data respectively. It differs from the network model in that the records are organized as collections

of trees rather than arbitrary graphs. Fig 7.5 represents a simple database.

Physical Data Models

Physical data models are used to describe data at the lowest level. A few physical data models are in use. Two such

models are:

Unifying model

Frame-memory model

Physical data models capture aspects of database-system implementation.

151

E-R Data Modeling Technique

Now we know various data models available. To understand the process of data modeling we'll study Entity

Relationship model. Peter P. Chen originally proposed the Entity- Relationship (ER) model in 1976. The ER model is a

conceptual data model that views the real world as a construct of entities and associations or relationships between

entities.

A basic component of the model is the Entity-Relationship diagram, which is used to visually represent data objects.

The ER modeling technique is frequently used for the conceptual design of database applications and many database

design tools employ its concepts.

ER model is easy to understand. Moreover it maps easily to relational model. The constructs used in ER model can

easily be transformed into relational tables. We will look into relational model in the next chapter, where other data

models are discussed. In the following section, we'll look at E-R model concepts.

We can compare ER diagram with a flowchart for programs. Flow chart is a tool for designing a program; similarly

ERD is a tool for designing databases. Also an ER diagram shows the kind and organization of the data that will be

stored in the database in the same way a flowchart chose the way a program will run.

E-R Model concept

The ER data modeling techniques is based on the perception of a real world that consists of a set of basic

objects called entities, and of relationships among these objects. In ER modeling, data is described as

entities, relationships, and attributes. In the following section, entities and attributes are discussed. Later,

entity types, their key attributes, relationship types, their structural constraints, and weak entity types are

discussed. In the last, we will apply ER modeling to our case study problem "Library management system".

Entities and Attributes

One of the basic components of ER model is entity. An entity is any distinguishable object about which

information is stored. These objects can be person, place, thing, event or a concept. Entities contain

descriptive information. Each entity is distinct.

An entity may be physical or abstract. A person, a book, car, house, employee etc. are all physical entities

whereas a company, job, or a university course, are abstract entities.

152

Fig 7.6 - Physical and Abstract Entity

Another classification of entities can be independent or dependent (strong or weak) entity.

ntities are classified as independent or dependent (in some methodologies, the terms used are strong and

weak, respectively). An independent entity is one, which does not rely on another entity for identification. A

dependent entity is one that relies on another entity for identification. An independent entity exists on its own

whereas dependent entity exists on the existence of some other entity. For example take an organization

scenario. Here department is independent entity. Department manager is a dependent entity. It exists for

existing depts. There won't be any department manager for which there is no dept.

Some entity types may not have any key attributes of their own. These are called weak entity types. Entities

belonging to a weak entity type are identified by being related to specific entities from another entity type in

combination with some of their attribute values. For example, take the license entity. It can't exist unless it is

related to a person entity.

Attributes

After you identify an entity, then you describe it in real terms, or through its attributes. Attributes are

basically properties of entity. We can use attributes for identifying and expressing entities. For example,

Dept entity can have DeptName, DeptId, and DeptManager as its attributes. A car entity can have modelno,

brandname, and color as its attributes.

A particular instance of an attribute is a value. For example, "Bhaskar" is one value of the attribute Name.

Employee number 8005 uniquely identifies an employee in a company.

The value of one or more attributes can uniquely identify an entity.

Fig 7.7 - Entity and its attributes

In the above figure, employee is the entity. EmpNo, Name, Designation and Department are its attributes.

An entity set may have several attributes. Formally each entity can be described by set of <attribute, data

value> pairs.

153

Fig 7.8 - Employee entity and its attribute values

Types of Attributes

Attributes can be of various types. In this section, we'll look at different types of attributes. Attributes can be categorized

as:

Key or non key attributes

Required or optional Attributes

Simple or composite Attributes

Single-valued and multi-valued Attributes

Stored, Coded or derived Attributes

Key or non-key attributes

Attributes can be classified as identifiers or descriptors. Identifiers, more commonly called keys or key attributes

uniquely identify an instance of an entity. If such an attribute doesn't exist naturally, a new attribute is defined for that

purpose, for example an ID number or code. A descriptor describes a non-unique characteristic of an entity instance.

An entity usually has an attribute whose values are distinct for each individual entity. This attribute uniquely identifies

the individual entity. Such an attribute is called a key attribute. For example, in the Employee entity type, EmpNo is the

key attribute since no two employees can have same employee number. Similarly, for Product entity type, ProdId is the

key attribute.

There may be a case when one single attribute is not sufficient to identify entities. Then a combination of attributes can

solve this purpose. We can form a group of more than one attribute and use this combination as a key attribute. That is

known as a composite key attribute. When identifying attributes of entities, identifying key attribute is very important.

154

Required or optional Attributes

An attribute can be required or optional. When it's required, we must have a value for it, a value must be known for each

entity occurrence. When it's optional, we could have a value for it, a value may be known for each entity occurrence.

For example, there is an attribute EmpNo (for employee no.) of entity employee. This is required attribute since here

would be no employee having no employee no. Employee's spouse is optional attribute because an employee may or

may not have a spouse.

Simple and composite Attributes

Composite attributes can be divided into smaller subparts. These subparts represent basic attributes with independent

meanings of their own. For example, take Name attributes. We can divide it into sub-parts like First_name,

Middle_name, and Last_name.

Attributes that can‘t be divided into subparts are called Simple or Atomic attributes. For example, EmployeeNumber is a

simple attribute. Age of a person is a simple attribute.

Composite Attributes

Single-valued and multi-valued Attributes

Attributes that can have single value at a particular instance of time are called singlevalued. A person can‘t have more

than one age value. Therefore, age of a person is a single-values attribute. A multi-valued attribute can have more than

one value at one time. For example, degree of a person is a multi-valued attribute since a person can have more than one

degree. Where appropriate, upper and lower bounds may be placed on the number of values in a multi-valued attribute.

For example, a bank may limit the number of addresses recorded for a single customer to two.

Stored, coded, or derived Attributes

There may be a case when two or more attributes values are related. Take the example of age. Age of a person can be

can be calculated from person‘s date of birth and present date. Difference between the two gives the value of age. In this

case, age is the derived attribute.

The attribute from which another attribute value is derived is called stored attribute. In the above example, date of birth

is the stored attribute. Take another example, if we have to calculate the interest on some principal amount for a given

time, and for a particular rate of interest, we can simply use the interest formula

Interest=NPR/100;

155

In this case, interest is the derived attribute whereas principal amount(P), time(N) and rate of interest(R) are all stored

attributes.

Derived attributes are usually created by a formula or by a summary operation on other attributes.

A coded value uses one or more letters or numbers to represent a fact. For example, the value Gender might use the

letters "M" and "F" as values rather than "Male" and "Female".

The attributes reflect the need for the information they provide. In the analysis meeting, the participants should list as

many attributes as possible. Later they can weed out those that are not applicable to the application, or those clients are

not prepared to spend the resources on to collect and maintain. The participants come to an agreement, on which

attributes belong with an entity, as well as which attributes are required or optional.

Entity Types

An entity set is a set of entities of the same type that share the same properties, or attributes. For example, all

software engineers working in the department involved in the Internet projects can be defined as the entity

set InternetGroup. The individual entities that constitute a set are called extension of the entity set. Thus, all

individual software engineers of in the Internet projects are the extensions of the entity set InternetGroup.

Entity sets don‘t need to be disjointed. For example, we can define an entity set Employee. An employee

may or may not be working on some Internet projects. In InternetGroup we will have some entries that are

there in Employee entity set. Therefore, entity sets Employee and InternetGroup are not disjoint.

A database usually contains groups of entities that are similar. For example, employees of a company share

the same attributes. However, every employee entity has its own values for each attribute. An entity type

defines a set of entities that have same attributes. A name and a list of attributes describe each entity type.

Fig. 7.10 shows two entity types Employee and Product. Their attribute list is also shown. A few members of

each entity type are shown.

156

Fig. 7.10 Two entity types and some of the member entities of each

An entity type is represented in ER diagrams as rectangular box and the corresponding attributes are shown

in ovals attached to the entity type by straight lines. See fig 7.7. in the section E R Model Concept

An entity type is basically the schema or intension or structure for the set of entities that share the same

structure whereas the individual entities of a particular entity type are collectively called entity set. The

entity set is also called the extension of the entity type.

Value Sets (domain) of Attributes

Each attribute of an entity type is associated with a value set. This value set is also called domain. The

domain of an attribute is the collection of all possible values an attribute can have.

The value set specifies the set of values that may be assigned for each individual entity. For example, we can

specify the value set for designation attribute as <―PM‖, ―Assit‖, ―DM‖, ―SE‖>. We can specify ―Name‖

attribute value set as <strings of alphabetic characters separated by blank characters>. The domain of Name

is a character string.

Entity Relationships

After identification of entities and their attributes, the next stage in ER data modeling is to identify the relationships

between these entities.

We can say a relationship is any association, linkage, or connection between the entities of interest to the business.

Typically, a relationship is indicated by a verb connecting two or more entities. Suppose there are two entities of our

library system, member and book, then the relationship between them can be ―borrows‖.

Member borrows book

157

Each relationship has a name, degree and cardinality. These concepts will be discussed nex

Degree of an Entity Relationship Type

Relationships exhibit certain characteristics like degree, connectivity, and cardinality. Once the relationships are

identified their degree and cardinality are also specified.

Degree: The degree of a relationship is the number of entities associated with the relationship. The n-ary relationship is

the general form for degree n. Special cases are the binary, and ternary, where the degree is 2, and 3, respectively.

Binary relationships, the association between two entities are the most common type in the real world.

Fig 7.11 shows a binary relationship between member and book entities of library system

Fig. 7.11 Binary Relationship

A ternary relationship involves three entities and is used when a binary relationship is inadequate. Many modeling

approaches recognize only binary relationships. Ternary or n-ary relationships are decomposed into two or more binary

relationships.

Connectivity and Cardinality

By connectivity we mean how many instances of one entity are associated with how many instances of other entity in a

relationship. Cardinality is used to specify such connectivity. The connectivity of a relationship describes the mapping

of associated entity instances in the relationship. The values of connectivity are "one" or "many". The cardinality of a

relationship is the actual number of related occurrences for each of the two entities. The basic types of connectivity for

relations are: one-to-one, one-to-many, and many-tomany.

A one-to-one (1:1) relationship is when at most one instance of an entity A is associated with one instance of entity B.

For example, take the relationship between board members and offices, where each office is held by one member and no

member may hold more than one office.

158

A one-to-many (1:N) relationship is when for one instance of entity A, there are zero, one, or many instances of entity B

but for one instance of entity B, there is only one instance of entity A. An example of a 1:N relationships is

a department has many employees;

each employee is assigned to one department.

A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance of entity A, there are zero,

one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. An

example is employees may be assigned to no more than three projects at a time; every project has at least two employees

assigned to it.

Here the cardinality of the relationship from employees to projects is three; from projects to employees, the cardinality

is two. Therefore, this relationship can be classified as a many-to-many relationship.

If a relationship can have a cardinality of zero, it is an optional relationship. If it must have a cardinality of at least one,

the relationship is mandatory. Optional relationships are typically indicated by the conditional tense. For example,

An employee may be assigned to a project.

Mandatory relationships, on the other hand, are indicated by words such as must have. For example,

a student must register for at least three courses in each semester.

Designing basic model and E-R Diagrams

E-R diagrams represent the schemas or the overall organization of the system. In this section, we‘ll apply the

concepts of E-R modeling to our ―Library Management System‖ and draw its E-R diagram.

In order to begin constructing the basic model, the modeler must analyze the information gathered during the

requirement analysis for the purpose of: and

classifying data objects as either entities or attributes,

identifying and defining relationships between entities,

naming and defining identified entities, attributes, and relationships,

documenting this information in the data document.

Finally draw its ER diagram.

To accomplish these goals the modeler must analyze narratives from users, notes from meeting, policy and

procedure documents, and, if lucky, design documents from the current information system.

E-R diagrams constructs

159

In E-R diagrams, entity types are represented by squares. See the table below. Relationship types are shown

in diamond shaped boxes attached to the participating entity types with straight lines. Attributes are shown in

ovals, and each attribute is attached to its entity type or relationship type by a straight line. Multivalued

attributes are shown in double ovals. Key attributes have their names underlined. Derived attributes are

shown in dotted ovals.

Weak entity types are distinguished by being placed in double rectangles and by having their identifying

relationship placed in double diamonds.

Attaching a 1, M, or N on each participating edge specifies cardinality ratio of each binary relationship type.

The participation constraint is specified by a single line for partial participation and by double lines for total

participation. The participation constraints specify whether the existence of an entity depends on its being

related to another entity via the relationship type. If every entity of an entity set is related to some other

entity set via a relationship type, then the participation of the first entity type is total. If only few member of

an entity type is related to some entity type via a relationship type, the participation is partial.

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED

ATTRIBUTE

DERIVED ATTRIBUTE

160

TOTAL PARTICIPATION

OF E2 IN R

Cardinality Ratio 1:N FOR

E1:E2 IN R

Structural

Constraint(Min,Max) On

Participation Of E In R

Naming Data Objects

The names should have the following properties:

unique,

have meaning to the end-user.

contain the minimum number of words needed to uniquely and accurately describe the object.

For entities and attributes, names are singular nouns while relationship names are typically verbs.

E-R Diagram for library management system

In the library Management system, the following entities and attributes can be identified.

Book -the set all the books in the library. Each book has a Book-id, Title, Author, Price, and

Available (y or n) as its attributes.

Member-the set all the library members. The member is described by the attributes Member_id,

Name, Street, City, Zip_code, Mem_type, Mem_date (date of membership), Expiry_date.

Publisher-the set of all the publishers of the books. Attributes of this entity are Pub_id, Name, Street,

City, and Zip_code.

Supplier-the set of all the Suppliers of the books. Attributes of this entity are Sup_id, Name, Street,

City, and Zip_code.

Assumptions: a publisher publishes a book. Supplier supplies book to library. Members borrow the book

(only issue).

Return of book is not taken into account

161

Fig. 7.13 E-R Diagram of Library Management System.

Relational Data Modeling and Object Oriented Data Modeling Techniques

At the end of this chapter, you will be able to know about relational data modeling and Object Oriented data modeling

techniques.In the last chapter we saw one data modeling technique, Entity Relationship data model. Having the basic

knowledge of data modeling we can now explore other methods for data modeling. There are many data models

available. Network, hierarchical, relational and object oriented databases. In this section, we'll take relational model and

object oriented model.

Relational Database Model

Different Types of Keys in Relational Database Model

Integrity Rules

162

Extensions and intensions

Key Constraints

Relational Algebra

Traditional set operators

Special Relational Operators

Object oriented Model

Encapsulation of Operations, Methods, and Persistence

Comparison Between Relational Database Model and Object Oriented Model

Relational Database Model

E.F.Codd proposed this model in the year 1970. The relational database model is the most popular data

model. It is very simple and easily understandable by information systems professionals and end users.

Understanding a relational model is very simple since it is very similar to Entity Relationship Model. In ER

model data is represented as entities similarly here data in represented in the form of relations that are

depicted by use of two-dimensional tables.

Also attributes are represented as columns of the table. These things are discussed in detail in the following

section.

The basic concept in the relational model is that of a relation. In simple language, a relation is a two-

dimensional table. Table can be used to represent some entity information or some relationship between

them. Even the table for an entity information and table for relationship information are similar in form.

Only from the type of information given in the table can tell if the table is for entity or relationship. The

entities and relationships, which we studied in the ER model, are similar to relations in this model. In

relational model, tables represent all the entities and relationships identified in ER model.

Rows in the table represent records; and columns show the attributes of the entity.

163

Fig. 8.1 Structure of a relation in a relational model.

Fig 8.1 shows structure of a relation in a relational model.

A table exhibits certain properties. It is a column homogeneous. That is, each item in a particular column is

of same type. See fig 8.2. It shows two columns for EmpNo and Name. In the EmpNo column it has only

employee numbers that is a numeric quantity. Similarly in Name column it has alphabetic entries. It is not

possible for EmpNo to have some non-numeric value (like alphabetic value). Similarly for Name column

only alphabetic values are allowed.

EmpNo Name ....................... .......................

1001 Jason

1002 William

1003 Mary

1004 Sarah

Fig. 8.2 Columns are homogeneous

Another important property of table is each item value is atomic. That is, item can‘t be further divided. For

example, take a name item. It can have first name, middle name, or last name. Since these would be three

different strings so they can‘t be placed under one column, say Name. All the three parts are placed in three

different columns. In this we can place them under, FirstName, MiddleName, and LastName. See fig 8.3.

FirstName MiddleName LastName .................

Jason Tony White .................

William Bruce Turner .................

164

Jack Pirate Sparrow .................

Fig. 8.3 Table columns can have atomic values

Every table must have a primary key. Primary key is some column of the table whose values are used to

distinguish the different records of the table. We‘ll take up primary key topic later in the session. There must

be some column having distinct value in all rows by which one can identify all rows. That is, all rows should

be unique. See fig. 8.4.

EmpNo EName DOJ

1001 Jason 20-Jun-2007

1002 William 12-Jul-2007

1002 William 20-Jul-2007

1010 Smith 20-Jul-2007

Fig. 8.4 Table with primary key “EmpNo” and degree “3”

In this table, EmpNo can be used as a primary key. Since it is the only column where the values are all

distinct. Whereas in Ename there are two William and in DOJ column, 15-Jul- 1998 is same for three row no

1,3, and 4. If we use DOJ as primary key then there would be three records that have same DOJ so there

won‘t be any way to distinguish these three records. For this DOJ can‘t be a primary key for this table. For

similar reasons, Ename cannot be used as primary key.

Next property we are going to discuss is for ordering of rows and columns within a table. Ordering is

immaterial for both rows and columns. See fig. 8.5. Table (a) and (b) represent the same table.

DName DeptID Manager

SD 1 Smith

HR 2 William

FIN 3 Jonathan

EDU 4 Jason

165

DName DeptID Manager

William HR 2

Mary EDU 7

Jason FIN 4

Smith SD 1

Fig. 8.5 Ordering of rows and columns in a table is immaterial

Names of columns are distinct. It is not possible to have two columns having same name in a table. Since a

column specifies a attribute, having two columns with same name mean that we are specifying the same

property in two columns, which is not acceptable. Total number of columns in a table specifies its degree. A

table with n columns is said to have degree n. See fig. 8.1. Table represented there is of degree 3.

Domain in Relational Model

Domain is set of all possible values for an attribute. For example there is an Employee table in which there is

a Designation attribute. Suppose, Designation attribute can take ―PM‖, ―Trainee‖, ―AGM‖, or ―Developer‖.

Then we can say all these values make the domain for the attribute Designation. An attribute represents the

use of a domain within a relation. Similarly for name attribute can take alphabetic strings. So domain for

name attribute will be set of all possible valid alphabetic strings.

Different Types of Keys in Relational Database Model

Now we‘ll take up another feature of relational tables. That is different type of keys. There are different

types of keys, namely Primary keys, alternate keys, etc. The different types of keys are described below.

Primary key

Within a given relation, there can be one attribute with values that are unique within the relation that can be

used to identify the tuples of that relation. That attribute is said to be primary key for that relation.

Composite primary key

Not every relation will have single-attribute primary key. There can be a possibility that some combination

of attribute when taken together have the unique identification property. These attributes as a group is called

composite primary key. A combination consisting of a single attribute is a special case.

Existence of such a combination is guaranteed by the fact that a relation is a set. Since sets don‘t contain

duplicate elements, each tuple of a relation is unique with respect to that relation. Hence, at least the

166

combination of all attributes has the unique identification property.

In practice it is not usually necessary to involve all the attributes-some lesser combination is normally

sufficient. Thus, every relation does have a primary (possibly composite) key.

Tuples represent entities in the real world. Primary key serves as a unique identifier for those entities.

Candidate key

In a relation, there can be more than one attribute combination possessing the unique identification property.

These combinations, which can act as primary key, are called candidate keys.

EmpNo SocSecurityNo Name Age

1011 2364236 Harry 21

1012 1002365 Sympson 19

1013 1056300 Larry 24

Fig. 8.6 Table having “EmpNo” and “SocSecurityNo” as candidate keys

Alternate key

A candidate key that is not a primary key is called an alternate key. In fig. 8.6 if EmpNo is primary key then

SocSecurityNo is the alternate key.

Integrity Rules in Relational Database Model

Integrity rule 1: Entity integrity

It says that no component of a primary key may be null.

All entities must be distinguishable. That is, they must have a unique identification of some kind. Primary keys perform

unique identification function in a relational database. An identifier that was wholly null would be a contradiction in

terms. It would be like there was some entity that did not have any unique identification. That is, it was not

distinguishable from other entities. If two entities are not distinguishable from each other, then by definition there are

not two entities but only one.

167

Integrity rule 2: Referential integrity

The referential integrity constraint is specified between two relations and is used to maintain the consistency among

tuples of the two relations.

Suppose we wish to ensure that value that appears in one relation for a given set of attributes also appears for a certain

set of attributes in another. This is referential integrity.

The referential integrity constraint states that, a tuple in one relation that refers to another relation must refer to the

existing tuple in that relation. This means that the referential integrity is a constraint specified on more than one relation.

This ensures that the consistency is maintained across the relations.

Table A

DeptID DeptName DeptManager

F-1001 Financial Nathan

S-2012 Software Martin

H-0001 HR Jason

Table B

EmpNo DeptID EmpName

1001 F-1001 Tommy

1002 S-2012 Will

1003 H-0001 Jonathan

168

Extensions and intensions in Relational Database Model

A relational in a relational database has two components, an extension and an intension.

Extension

The extension of a given relation is the set of tuples appearing in that relation at any given instance. The

extension thus varies with time. It changes as tuples are created, destroyed, and updated.

Relation: Employee at time= t1

EmpNo EmpName Age Dept

1001 Jason 23 SD

1002 William 24 HR

1003 Jonathan 28 Fin

1004 Harry 20 Fin

Relation: Employee at time= t2 after adding more records

EmpNo EmpName Age Dept

1001 Jason 23 SD

1002 William 24 HR

1003 Jonathan 28 Fin

1004 Harry 20 Fin

1005 Smith 22 HR

1006 Mary 19 HR

1007 Sarah 23 SD

169

Relation: Employee at time= t2 after adding more records

EmpNo EmpName Age Dept

1001 Jason 23 SD

1002 William 24 HR

Intension

The intension of a given relation is independent of time. It is the permanent part of the relation. It

corresponds to what is specified in the relational schema. The intension thus defines all permissible

extensions. The intension is a combination of two things : a structure and a set of integrity constraints.

The naming structure consists of the relation name plus the names of the attributes (each with its associated

domain name).

The integrity constraints can be subdivided into key constraints, referential constraints, and other constraints.

For example,

Employee(EmpNo Number(4) Not NULL, EName Char(20), Age Number(2), Dept Char(4) )

This is the intension of Employee relation.

Key Constraints in Relational Database Model

Key constraint is implied by the existence of candidate keys. The intension includes a specification of the attribute(s)

consisting the primary key and specification of the attribute(s) consisting alternate keys, if any. Each of these

specifications implies a uniqueness constraint(by definition of candidate key);in addition primary key specification

implies a no-nulls constraint( by integrity rule 1).

Referential constraints

Referential constraints are constraints implied by the existence of foreign keys. The intension includes a specification of

all foreign keys in the relation. Each of these specifications implies a referential constraint ( by integrity rule 2).

Other constraints

170

Many other constraints are possible in theory.

Examples

salary >= 10000

Relational Algebra

Once the relationships are identified, then operations that are applied on the relations are also identified. In

relational model, the operations are performed with the help of relational algebra. Relational algebra is a

collection of operations on relations.

Each operation takes one or more relations as its operand(s) and produces another relation as its result. We

can compare relational algebra with traditional arithmetic algebra.

In arithmetic algebra , there are operators that operate on operands( data values) and produce some result.

Similarly in relational algebra there are relational operators that operate upon relations and produce relations

as results.

Relational algebra can be divided into two groups:

1. Traditional set operators that includes union, intersection, difference, and Cartesian product.

2. Special relational operators that includes selection, projection, and division

. Traditional set operators in Relational Database Model

Union:

The union of two relations A and B is the set of all tuples belonging to either A or B (or both).

Example:

A = The set of employees whose department is S/W Development

B = The set of employee whose age is less than 30 years.

A UNION B = The set of employees whose are either in S/W development department or having age less than 30 years.

Intersection:

The intersection of two relations A and B is the set of all tuples t belonging to both A and B.

171

Example:

A = The set of employees whose department is S/W Development

B = The set of employee whose age is less than 30 years.

A INTERSECTION B = The set of employees whose are in S/W development department having age less than 30

years.

Difference:

The difference between two relations A and B( in that order) is the set of all tuples belonging to A and not to B.

Example:

A = The set of employees whose department is S/W Development

B = The set of employee whose age is less than 30 years.

A MINUS B = The set of employees whose department is S/W development and not having age less than 30 years.

Cartesian Product:

The Cartesian product of two relations A and B is the set of all tuples t such that t is the concatenation of a tuple a

belonging to A and a tuple b belonging to B. The concatenation of a tuple a = (a1, ………., am) and tuple b=(bm+1 ,

……., bm+n)- in that order- is the tuple t =(a1, ….., am, bm+1, ……..bm+n).

Example:

A = The set of employees whose department is S/W Development

B = The set of employee whose age is less than 30 years.

A TIMES B = is the set of all possible employee no/department ids pairs

172

Special Relational Operators in Relational Database Model

Selection:

The selection operator yields a 'horizontal' subset of a given relation - that is, the subset of tuples within the

given relation for which a specified predicate is satisfied.

The predicate is expressed as a Boolean combination of terms, each term being a simple comparison that can

be established as true or false for a given tuple by inspecting that tuple in isolation.

Book WHERE Author = ‗Kruse‘

BookID BookName Author

A-112 Algorithms Jack

C-12 Data Mining Jack

F-348 Software Engineer Jack

Employee WHERE Desig=‘Manager‘ AND Dept =‘SD‘

EmpNo EmpName Designation Depat

2001 Morrison Manager SD

2002 Steve Manager SD

2003 Fleming Manager SD

Projection:

The projection yields a 'vertical' subset of a given relation- that is, the subset obtained by selecting specified

attributes, in a specified left-to-right order, and then eliminating duplicate tuples within the attributes

selected.

Example: Issue[BookId,ReturnDate]

BookID ReturnDate

173

q-110 20-May-2008

w-990 21-Jun-2008

f-100 23-Jun-2008

r-800 27-Jun-2008

q-501 15-Jul-2008

Book[BookName]

BookName

Software Concepts

Data Structures

Programming

AssemblyLanguage

SSAD

PC-Troubleshooting

Compiler Design

Now we know about the constructs of relational data model. We also know how to specify constraints and

how to use relational algebra for illustrating various functions. We now take up another data model that is

entirely different from relational model.

Division:

The division operator divides a dividend relation A of degree m+n by a divisor relation B of degree n, and

produces a result relation of degree m.

Let A be set of pairs of values <x, y> and B a set of single values, <y>. Then the result of dividing A by B -

that is A DIVIDEDBY B- is the set of values x such that the pair <x, y> appears in A for all values y

174

appearing in B.

Object Oriented Model

Nowadays people are moving towards the object oriented approach in many fields. These fields include

programming, software engineering, development technologies, implementation of databases, etc. Object

oriented concepts have their roots in the object oriented programming languages. Since programming

languages were the first to use these concepts in practical sense. When these concepts became widely

popular and accepted, other areas started to implement these ideas in them. It became possible due to the fact

the object-oriented concepts try to model things as they are. So today it is a common practice to use object-

oriented concepts in data modeling. In this session we‘ll try to look at the process of applying object oriented

concepts to data modeling.

Object Oriented data Modeling Concepts

As discussed earlier Object oriented model has adopted many features that were developed for object

oriented programming languages. These include objects, inheritance, polymorphism, and encapsulation.

In object-oriented model main construct is an object. As in E-R model we have entities and in relational

model, there are relations similarly we have objects in OO data modeling. So first thing that is done in OO

model is to identify the objects for the systems. Examining the problem statement can do it. Other important

task is to identify the various operations for these objects. It is easy to relate the objects to the real world. In

the section that follows we will try to understand the basic concepts of OO data model.

Objects and object identity:

In this model, everything is modeled as objects. An object can be any physical or abstract thing. It can be a

person, place, thing, or a concept. An object can be used to model the overall structure not just a part of it.

Also the behavior of the thing that is being modeled is also specified in the object. This feature is called

encapsulation. Encapsulation is discussed later in the chapter. Only thing we need to know at this stage is

object can store information and behavior in the same entity i.e. an object. Suppose a car is being modeled

using this method. Then we can have an object ‗Car‘ that has the following information.

Car:

Color, Brand, ModelNo, Gears, EngineCylinders, Capacity, No of gates. All this information is sufficient to

model any car.

All the objects should be unique. For this purpose, every object is given an identity. Identity is the property

of an object, which distinguishes it from all other object. In OO databases, each object has a unique identity.

This unique identity is implemented via a unique, system generated object identifier (OID). OID is used

internally by the system to identify each object uniquely and to create and manage inter-object references.

But its value is not visible to the user.

175

The main properties of OID :

1. It is immutable: The value of OID for a particular object should not change. This preserves the

identity of the real world object being represented.

2. It is used only once: Even if an object is removed its OID is not assigned to other objects.

The value of OID doesn‘t depend upon any attributes of the object since the values of attributes may change.

OID should not be based on the physical address of the object in memory since physical reorganization of

the database could change the OID. There should be some mechanism for generating OIDs.

Another feature of OO databases is that objects may have a complex structure. It is due to contain all of the

significant information that describes the object. In contrast, in traditional database systems, information

about a complex object is often scattered over many relations or records. See fig. 8.12. It leads to loss of

direct correspondence between a real-world object and its database representation.

The internal structure of an object includes the specification of instance variables, which hold the values, that

defines the internal state of the object.

In OO databases, the values (or states) of complex objects may be constructed from other objects. These

objects may be represented as a triple t(i, c, v), where i is a unique object identifier, c is a constructor (that is,

an indication of how the object value is constructed), and v is the object value (or state).

There can be several constructors, depending upon or the OO system. The basic constructors are the atom,

tuple, set, list, and array constructors. There is also a domain D that contains all basic atomic values that are

directly available in the system. These include integers, real numbers, character strings, Boolean, dates, and

any other data types that the system supports directly.

An object value v is interpreted on the basis of the value of the constructor c in the triple (i,c,v) that

represents the object.

If c = atom, the value is an atomic value from domain D of basic values supported by the system.

If c = set, the value v is a set of objects identifiers{i1,i2,……..,in), which are the identifiers(OIDs) for a set

of objects that are typically of the same type.

If c= tuple, the value v is a tuple of the form <a1:i1,…………., an:in), where each aj is an attribute name(

sometimes called an instance variable name in OO terminology) and each ij is an object identifier(OID).

If c = list, the value v is an ordered list of object identifiers[i1,i2,……….., in] of the same type. For c =

array, the value v, is an array of object identifier.

Consider the following example:

O1 = (i1, atom, Roger)

176

O2 = (i2, atom, Jane)

O3 = (i3, atom, Goerge)

O4 = (i4, set, {i1,i2,i3})

O5 = (i5, atom, SE)

O6 = (i6, atom, NEPZ)

O7 = (i7,tuple,<DNAME:i5,DNUMBER:i8,LOCATION:i6,ENAME:i3>)

O8 = (i8,atom,1)

Here value of object 4 is constructed from object values of objects O1, O2, and O3. Similarly value of object

7 is constructed from the value of O1, O3, O6, and O8. These constructors can be used to define the data

structures for an OO database schema.

Encapsulation of Operations, Methods, and Persistence

Encapsulation is related to the concepts of abstract data types and information hiding in programming languages. Here

the main idea is to define the behavior of a type of object based on the operations that can be externally applied to

objects of that type. The internal structure of the object is hidden, and the object is only accessible through a number of

predefined operations. Some operations may be used to create or destroy objects; other operations may update the object

value and other may be used to retrieve parts of the object value or to apply some calculations to the object value.

The external users of the object are only made aware of the interface of the object, which defines the names and

arguments of each operation. The implementation of the object is hidden from the external users; it includes the

definition of the internal data structure of the object and the implementation of the operations that access these

structures.

In object oriented - OO terminology, the interface part of each operation is called the signature, and the operation

implementation is called a method. A method is invoked by sending a message to the object to execute the

corresponding method.

Not all objects are meant to be stored permanently in the database. Transient objects exist in the executing program and

disappear once the program terminates.

Persistent objects are stored in the database and persist after program terminates. The typical mechanism for persistence

involves giving an object a unique persistent name through which it can be retrieved.

Inheritance

177

Inheritance is deriving objects from existing objects. The derived objects inherit properties from their parent object.

Parent objects are those objects from which other objects are derived. Inheritance is a way of reusing the existing code.

Polymorphism

Polymorphism concept allows the same operator name or symbol to be bound to two or more different implementation

of the operator, depending on the type of objects to which the operator is applied.

Major features of Object Oriented databases

Object Oriented databases store persistent objects permanently on secondary storage, and allow the sharing of these

objects among multiple programs and applications.

Object Oriented databases provide a unique system-generated object identifier for each object. Object Oriented

databases maintain a direct correspondence between real-world and database objects so that objects don‘t lose their

integrity and identify and can be easily be identified and operated upon.

In Object Oriented databases, objects can be very complex in order to contain all significant information that may be

required to describe the object completely.

Object Oriented databases allow us to store both the class and state of an object between programs. They take the

responsibility for maintaining the links between stored object behavior and state away from the programmer, and

manage objects outside of programs with their public and private elements intact. They also simplify the whole process

of rendering objects persistent by performing such tasks invisibly.

Persistence has to do with time i.e. a persistent object can exist beyond the program that created it. It also has to do with

space (the location of the object may vary between processors, and even change its representation in the process).

178

Comparison Between Relational Database Model and Object Oriented Model

Now we know about both relational and object oriented approach, we can now compare these two models. In

this session, we compare the relational model and object oriented model. We compare model representation

capabilities, languages, system storage structures, and integrity constraints.

Data Model Representation

Different database models differ in their representation of relationships. In relational model, connections

between two relations are represented by foreign key attribute in one relation that reference the primary key

of another relation. Individual tuples having same values in foreign and primary key attribute are logically

related. They are physically not connected. Relational model uses logical references.

In object oriented model, relationships are represented by references via the object identifier (OID). This is

in a way similar to foreign keys but internal system identifiers are used rather than user-defined attributes.

The Object Oriented model supports complex object structures by using tuple, set, list, and other

constructors. It supports the specification of methods and the inheritance mechanism that permits creation of

new class definitions from existing ones.

Storage Structures

In relational model, each base relation is implemented as a separate file. If the does not specify any storage

structure, most RDBMS will store the tuples as unordered records in the file. It allows the user to specify

dynamically on each file a single primary or clustering index and any number of secondary indexes. It is the

responsibility of user to chObject Orientedse the attributes on which the indexes are set up. Some RDBMSs

give the user the option of mixing records from several base relations together. It is useful when related

records from more than one relation are often accessed together. This clustering of records physically places

a record from one relation followed by the related records from another relation. In this way the related

records may be retrieved in most efficient way possible.

Object Oriented systems provide persistent storage for complex-structured objects. They employ indexing

techniques to locate disk pages that store the object. The objects are often stored as byte strings, and the

object structure is reconstructed after copying the disk pages that contain the object into system buffers.

Integrity Constraints

Relational model has keys, entity integrity, and referential integrity. The constraints supported by Object

Oriented systems vary from system to system. The inverse relationship mechanism supported by some

Object Oriented systems provides some declarative constraints.

Data manipulation Languages

There are languages such as SQL, QUEL, and QBE are available for relational systems. These are based on

179

the relational calculus.

In Object Oriented systems, the DML is typically incorporated into some programming language, such as

C++. Hence, the structures of both stored persistent objects and programminglanguage transient objects are

often compatible. Query languages have been developed for Object Oriented databases. Work on a standard

Object Oriented model and language is progressing, but no complete detailed standard has emerged as yet.

Fundamentals of Software Testing

Testing is basically a process to detect errors in the software product. Before going into the details of testing techniques

one should know what errors are. In day-to-day life we say whenever something goes wrong there is an error. This

definition is quite vast. When we apply this concept to software products then we say whenever there is difference

between what is expected out of software and what is being achieved, there is an error.

For the output of the system, if it differs from what was required, it is due to an error. This output can be some numeric

or alphabetic value, some formatted report, or some specific behavior from the system. In case of an error there may be

change in the format of out, some unexpected behavior from system, or some value different from the expected is

obtained. These errors can due to wrong analysis, wrong design, or some fault on developer's part.

All these errors need to be discovered before the system is implemented at the customer's site. Because having a system

that does not perform as desired be of no use. All the effort put in to build it goes waste. So testing is done. And it is

equally important and crucial as any other stage of system development. For different types of errors there are different

types of testing techniques. In the section that follows we'll try to understand those techniques.

Objectives of testing

First of all the objective of the testing should be clear. We can define testing as a process of executing a program with

the aim of finding errors. To perform testing, test cases are designed. A test case is a particular made up artificial

situation upon which a program is exposed so as to find errors. So a good test case is one that finds undiscovered errors.

If testing is done properly, it uncovers errors and after fixing those errors we have software that is being developed

according to specifications.

180

Test Information Flow

Testing is a complete process. For testing we need two types of inputs. First is software configuration. It includes

software requirement specification, design specifications and source code of program. Second is test configuration. It is

basically test plan and procedure.

Software configuration is required so that the testers know what is to be expected and tested whereas test configuration

is testing plan that is, the way how the testing will be conducted on the system. It specifies the test cases and their

expected value. It also specifies if any tools for testing are to be used. Test cases are required to know what specific

situations need to be tested. When tests are evaluated, test results are compared with actual results and if there is some

error, then debugging is done to correct the error. Testing is a way to know about quality and reliability. Error rate that

is the occurrence of errors is evaluated. This data can be used to predict the occurrence of errors in future.

Fig 9.1 Testing Process

Test Case design

We now know, test cases are integral part of testing. So we need to know more about test cases and how these test cases

are designed. The most desired or obvious expectation from a test case is that it should be able to find most errors with

the least amount of time and effort.

A software product can be tested in two ways. In the first approach only the overall functioning of the product is tested.

Inputs are given and outputs are checked. This approach is called black box testing. It does not care about the internal

functioning of the product.

The other approach is called white box testing. Here the internal functioning of the product is tested. Each procedure is

tested for its accuracy. It is more intensive than black box testing. But for the overall product both these techniques are

crucial. There should be sufficient number of tests in both categories to test the overall product.

181

Comparison Between Relational Database Model and Object Oriented Model

Now we know about both relational and object oriented approach, we can now compare these two models. In this

session, we compare the relational model and object oriented model. We compare model representation capabilities,

languages, system storage structures, and integrity constraints.

Data Model Representation

Different database models differ in their representation of relationships. In relational model, connections between two

relations are represented by foreign key attribute in one relation that reference the primary key of another relation.

Individual tuples having same values in foreign and primary key attribute are logically related. They are physically not

connected. Relational model uses logical references.

In object oriented model, relationships are represented by references via the object identifier (OID). This is in a way

similar to foreign keys but internal system identifiers are used rather than user-defined attributes. The Object Oriented

model supports complex object structures by using tuple, set, list, and other constructors. It supports the specification of

methods and the inheritance mechanism that permits creation of new class definitions from existing ones.

Storage Structures

In relational model, each base relation is implemented as a separate file. If the does not specify any storage structure,

most RDBMS will store the tuples as unordered records in the file. It allows the user to specify dynamically on each file

a single primary or clustering index and any number of secondary indexes. It is the responsibility of user to chObject

Orientedse the attributes on which the indexes are set up. Some RDBMSs give the user the option of mixing records

from several base relations together. It is useful when related records from more than one relation are often accessed

together. This clustering of records physically places a record from one relation followed by the related records from

another relation. In this way the related records may be retrieved in most efficient way possible.

Object Oriented systems provide persistent storage for complex-structured objects. They employ indexing techniques to

locate disk pages that store the object. The objects are often stored as byte strings, and the object structure is

reconstructed after copying the disk pages that contain the object into system buffers.

Integrity Constraints

Relational model has keys, entity integrity, and referential integrity. The constraints supported by Object Oriented

systems vary from system to system. The inverse relationship mechanism supported by some Object Oriented systems

provides some declarative constraints.

Data manipulation Languages

There are languages such as SQL, QUEL, and QBE are available for relational systems. These are based on the

relational calculus.

182

In Object Oriented systems, the DML is typically incorporated into some programming language, such as C++. Hence,

the structures of both stored persistent objects and programminglanguage transient objects are often compatible. Query

languages have been developed for Object Oriented databases. Work on a standard Object Oriented model and language

is progressing, but no complete detailed standard has emerged as yet.

Fundamentals of Software Testing

Testing is basically a process to detect errors in the software product. Before going into the details of testing techniques

one should know what errors are. In day-to-day life we say whenever something goes wrong there is an error. This

definition is quite vast. When we apply this concept to software products then we say whenever there is difference

between what is expected out of software and what is being achieved, there is an error.

For the output of the system, if it differs from what was required, it is due to an error. This output can be some numeric

or alphabetic value, some formatted report, or some specific behavior from the system. In case of an error there may be

change in the format of out, some unexpected behavior from system, or some value different from the expected is

obtained. These errors can due to wrong analysis, wrong design, or some fault on developer's part.

All these errors need to be discovered before the system is implemented at the customer's site. Because having a system

that does not perform as desired be of no use. All the effort put in to build it goes waste. So testing is done. And it is

equally important and crucial as any other stage of system development. For different types of errors there are different

types of testing techniques. In the section that follows we'll try to understand those techniques.

Objectives of testing

First of all the objective of the testing should be clear. We can define testing as a process of executing a program with

the aim of finding errors. To perform testing, test cases are designed. A test case is a particular made up artificial

situation upon which a program is exposed so as to find errors. So a good test case is one that finds undiscovered errors.

If testing is done properly, it uncovers errors and after fixing those errors we have software that is being developed

according to specifications.

Test Information Flow

Testing is a complete process. For testing we need two types of inputs. First is software configuration. It includes

software requirement specification, design specifications and source code of program. Second is test configuration. It is

basically test plan and procedure.

Software configuration is required so that the testers know what is to be expected and tested whereas test configuration

is testing plan that is, the way how the testing will be conducted on the system. It specifies the test cases and their

expected value. It also specifies if any tools for testing are to be used. Test cases are required to know what specific

situations need to be tested. When tests are evaluated, test results are compared with actual results and if there is some

error, then debugging is done to correct the error. Testing is a way to know about quality and reliability. Error rate that

is the occurrence of errors is evaluated. This data can be used to predict the occurrence of errors in future.

183

Fig 9.1 Testing Process

Test Case design

We now know, test cases are integral part of testing. So we need to know more about test cases and how these test cases

are designed. The most desired or obvious expectation from a test case is that it should be able to find most errors with

the least amount of time and effort.

A software product can be tested in two ways. In the first approach only the overall functioning of the product is tested.

Inputs are given and outputs are checked. This approach is called black box testing. It does not care about the internal

functioning of the product.

The other approach is called white box testing. Here the internal functioning of the product is tested. Each procedure is

tested for its accuracy. It is more intensive than black box testing. But for the overall product both these techniques are

crucial. There should be sufficient number of tests in both categories to test the overall product.

White Box Testing

White box testing focuses on the internal functioning of the product. For this different procedures are tested. White box

testing tests the following

Loops of the procedure

Decision points

Execution paths

For performing white box testing, basic path testing technique is used. We will illustrate how to use this technique, in

the following section.

Basis Path Testing

184

Basic path testing a white box testing technique .It was proposed by Tom McCabe. These tests guarantee to execute

every statement in the program at least one time during testing. Basic set is the set of all the execution path of a

procedure.

Flow graph Notation

Before basic path procedure is discussed, it is important to know the simple notation used for the repres4enttation of

control flow. This notation is known as flow graph. Flow graph depicts control flow and uses the following constructs.

These individual constructs combine together to produce the flow graph for a particular procedure

Sequence - Until -

If - While - Case -

Basic terminology associated with the flow graph

Node: Each flow graph node represents one or more procedural statements. Each node that contains a condition is called

a predicate node.

Edge: Edge is the connection between two nodes. The edges between nodes represent flow of control. An edge must

terminate at a node, even if the node does not represent any useful procedural statements.

Region: A region in a flow graph is an area bounded by edges and nodes. Cyclomatic complexity: Independent path is

an execution flow from the start point to the end point. Since a procedure contains control statements, there are various

execution paths depending upon decision taken on the control statement. So Cyclomatic complexity provides the

number of such execution independent paths. Thus it provides a upper bound for number of tests that must be produced

because for each independent path, a test should be conducted to see if it is actually reaching the end point of the

procedure or not.

Cyclomatic Complexity

185

Cyclomatic Complexity for a flow graph is computed in one of three ways:

1. The numbers of regions of the flow graph correspond to the Cyclomatic complexity.

2. Cyclomatic complexity, V(G), for a flow graph G is defined as

V(G) = E – N + 2

where E is the number of flow graph edges and N is the number of flow graph nodes.

3. Cyclomatic complexity, V(G), for a graph flow G is also defined as

V(G) = P + 1

Where P is the number of predicate nodes contained in the flow graph G.

Example: Consider the following flow graph

Region, R= 6

Number of Nodes = 13

Number of edges = 17

Number of Predicate Nodes = 5

Cyclomatic Complexity, V( C) :

186

V( C ) = R = 6;

Or

V(C) = Predicate Nodes + 1

=5+1 =6

Or

V( C)= E-N+2

= 17-13+2

Deriving Test Cases

The main objective of basic path testing is to derive the test cases for the procedure under test. The process of deriving

test cases is following

1. From the design or source code, derive a flow graph.

2. Determine the Cyclomatic complexity, V(G) of this flow graph using any of the formula discussed above.

· Even without a flow graph, V(G) can be determined by counting the number of conditional statements in the

code and adding one to it.

3. Prepare test cases that will force execution of each path in the basis set.

· Each test case is executed and compared to the expected results.

Graph Matrices

Graph matrix is a two dimensional matrix that helps in determining the basic set. It has rows and columns each equal to

number of nodes in flow graph. Entry corresponding to each node-node pair represents an edge in flow graph. Each

edge is represented by some letter (as given in the flow chart) to distinguish it from other edges. Then each edge is

provided with some link weight, 0 if there is no connection and 1 if there is connection.

For providing weights each letter is replaced by 1 indicating a connection. Now the graph matrix is called connection

matrix. Each row with two entries represents a predicate node. Then for each row sum of the entries is obtained and 1 is

subtracted from it. Now the value so obtained for each row is added and 1 is again added to get the cyclomatic

complexity.

Once the internal working of the different procedure are tested, then the testing for the overall functionality of program

structure is tested. For this black box testing techniques are used which are discussed in the following pages.

Black Box Testing

Black box testing test the overall functional requirements of product. Input are supplied to product and outputs are

verified. If the outputs obtained are same as the expected ones then the product meets the functional requirements. In

this approach internal procedures are not considered. It is conducted at later stages of testing. Now we will look at black

187

box testing technique.

Black box testing uncovers following types of errors.

1. Incorrect or missing functions

2. Interface errors

3. External database access

4. Performance errors

5. Initialization and termination errors.

The following techniques are employed during black box testing

Equivalence Partitioning

In equivalence partitioning, a test case is designed so as to uncover a group or class of error. This limits the number of

test cases that might need to be developed otherwise.

Here input domain is divided into classes or group of data. These classes are known as equivalence classes and the

process of making equivalence classes is called equivalence partitioning. Equivalence classes represent a set of valid or

invalid states for input condition.

An input condition can be a range, a specific value, a set of values, or a boolean value. Then depending upon type of

input equivalence classes is defined. For defining equivalence classes the following guidelines should be used.

1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined.

2. If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.

3. If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined.

4. If an input condition is Boolean, then one valid and one invalid equivalence class are defined.

For example, the range is say, 0 < count < Max1000. Then form a valid equivalence class with that range of values and

two invalid equivalence classes, one with values less than the lower bound of range (i.e., count < 0) and other with

values higher than the higher bound( count > 1000).

Boundary Value Analysis

It has been observed that programs that work correctly for a set of values in an equivalence class fail on some special

values. These values often lie on the boundary of the equivalence class. Test cases that have values on the boundaries of

equivalence classes are therefore likely to be error producing so selecting such test cases for those boundaries is the aim

of boundary value analysis.

In boundary value analysis, we choose input for a test case from an equivalence class, such that the input lies at the edge

of the equivalence classes. Boundary values for each equivalence class, including the equivalence classes of the output,

should be covered. Boundary value test cases are also called ―extreme cases‖.

188

Hence, a boundary value test case is a set of input data that lies on the edge or boundary of a class of input data or that

generates output that lies at the boundary of a class of output data.

In case of ranges, for boundary value analysis it is useful to select boundary elements of the range and an invalid value

just beyond the two ends (for the two invalid equivalence classes. For example, if the range is 0.0 <= x <= 1.0, then the

test cases are 0.0,1.0for valid inputs and –0.1 and 1.1 for invalid inputs.

For boundary value analysis, the following guidelines should be used:

For input ranges bounded by a and b, test cases should include values a and b and just above and just below a and b

respectively.

If an input condition specifies a number of values, test cases should be developed to exercise the minimum and

maximum numbers and values just above and below these limits.

If internal data structures have prescribed boundaries, a test case should be designed to exercise the data structure at its

boundary.

Now we know how the testing for software product is done. But testing software is not an easy task since the size of

software developed for the various systems is often too big. Testing needs a specific systematic procedure, which should

guide the tester in performing different tests at correct time. This systematic procedure is testing strategies, which

should be followed in order to test the system developed thoroughly. Performing testing without some testing strategy

would be very cumbersome and difficult. Testing strategies are discussed the following pages of this chapter.

Strategic Approach towards Software Testing

Developers are under great pressure to deliver more complex software on increasingly aggressive schedules and with

limited resources. Testers are expected to verify the quality of such software in less time and with even fewer resources.

In such an environment, solid, repeatable, and practical testing methods and automation are a must.

In a software development life cycle, bug can be injected at any stage. Earlier the bugs are identified, more cost saving it

has. There are different techniques for detecting and eliminating bugs that originate in respective phase.

Software testing strategy integrates software test case design techniques into a wellplanned series of steps that result in

the successful construction of software. Any test strategy incorporate test planning, test case design, test execution, and

the resultant data collection and evaluation.

Testing is a set of activities. These activities so planned and conducted systematically that it leaves no scope for rework

or bugs.

Various software-testing strategies have been proposed so far. All provide a template for testing. Things that are

common and important in these strategies are

Testing begins at the module level and works ―outward‖ : tests which are carried out, are done at the module level where

189

major functionality is tested and then it works toward the integration of the entire system.

Different testing techniques are appropriate at different points in time: Under different circumstances, different testing

methodologies are to be used which will be the decisive factor for software robustness and scalability. Circumstance

essentially means the level at which the testing is being done (Unit testing, system testing, Integration testing etc.) and

the purpose of testing.

The developer of the software conducts testing and if the project is big then there is a testing team: All programmers

should test and verify that their results are according to the specification given to them while coding. In cases where

programs are big enough or collective effort is involved for coding, responsibilities for testing lies with the team as a

whole.

Debugging and testing are altogether different processes. Testing aims to finds the errors whereas debugging is the

process of fixing those errors. But debugging should be incorporated in testing strategies.

A software strategy must have low-level tests to test the source code and high-level tests that validate system functions

against customer requirements.

Verification and Validation in Software Testing

Verification is a process to check the deviation of actual results from the required ones. This activity is carried out in a

simulated environment so that actual results could be obtained without taking any risks.

Validation refers by the process of using software in a live environment in order to find errors. The feedback from the

validation phase generally produces changes in the software to deal with bugs and failures that are uncovered.

Validation may continue for several months. During the course of validating the system, failure may occur and the

software will be changed. Continued use may produce additional failures and the need for still more changes.

Planning for Testing

One of the major problem before testing is while planning. Because of natural reasons a developer would like to declare

his program as bug free. But this does not esantially mean that the pragrammer himself should not test his program. He

is the most knowledgable person with context his own program. Therefore, he is always responsible for testing the

individual units (modules) of the program, ensuring that each module performs the function for which it was designed.

In many cases, the developer also conducts integration testing- a testing step that leads to the construction(and testing)

of thecomplete program structure.

Only after the software architecture is complete does an independent test group(ITG) become involoved. ITG test the

product very thoroughly. Both the developer and ITGs should be made responsible for testing. First developer should

test the product after that ITG can do it. In this case since the developer knew that there are other people who will again

test their product they'll conduct tests thoroughly. When developer and ITG work together, the product is tested

thoroughly and unbiased.

Testing Strategies

190

Once it is decided who'll do testing then the main issue is how to go about testing. That is in which manner testing

should be performed. As shown in fig. 9.3 first unit testing is performed. Unit testing focuses on the individual modules

of the product. After that integration testing is performed. When modules are integrated into bigger program structure

then new errors arise often. Integration testing uncovers those errors. After integration testing, other high order tests like

system tests are performed. These tests focus on the overall system. Here system is treated as one entity and tested as a

whole. Now we'll take up these different types of tests and try to understand their basic concepts.

Unit Testing

We know that smallest unit of software design is a module. Unit testing is performed to check the functionality of these

units. it is done before these modules are integrated together to build the overall system. Since the modules are small in

size, individual programmers can do unit testing on their respective modules. So unit testing is basically white box

oriented. Procedural design descriptions are used and control paths are tested to uncover errors within individual

modules. Unit testing can be done for more than one module at a time.

The following are the tests that are performed during the unit testing:

Module interface test: here it is checked if the information is properly flowing into the program unit and properly

coming out of it.

Local data structures: these are tested to see if the local data within unit(module) is stored properly by them.

Boundary conditions: It is observed that much software often fails at boundary conditions. That's why boundary

conditions are tested to ensure that the program is properly working at its boundary conditions.

Independent paths: All independent paths are tested to see that they are properly executing their task and

terminating at the end of the program.

Error handling paths: These are tested to check if errors are handled properly by them.

See fig. 9.4 for overview of unit testing

191

Fig 9.4 Unit Testing

Unit Testing Procedure

Fig 9.5 Unit Test Procedure

Unit testing begins after the source code is developed, reviewed and verified for the correct syntax. Here design

documents help in making test cases. Though each module performs a specific task yet it is not a standalone program. It

may need data from some other module or it may need to send some data or control information to some other module.

Since in unit testing each module is tested individually, so the need to obtain data from other module or passing data to

other module is achieved by the use of stubs and drivers. Stubs and drivers are used to simulate those modules. A driver

is basically a program that accepts test case data and passes that data to the module that is being tested. It also prints the

relevant results. Similarly stubs are also programs that are used to replace modules that are subordinate to the module to

be tested. It does minimal data manipulation, prints verification of entry, and returns. Fig. 9.5 illustrates this unit test

procedure.

Drivers and stubs are overhead because they are developed but are not a part of the product. This overhead can be

reduced if these are kept very simple.

Once the individual modules are tested then these modules are integrated to form the bigger program structures. So next

stage of testing deals with the errors that occur while integrating modules. That's why next testing done is called

integration testing, which is discussed next.

Integration Testing

Unit testing ensures that all modules have been tested and each of them works properly individually. Unit testing does

not guarantee if these modules will work fine if these are integrated together as a whole system. It is observed that many

errors crop up when the modules are joined together. Integration testing uncovers errors that arises when modules are

192

integrated to build the overall system.

Following types of errors may arise:

Data can be lost across an interface. That is data coming out of a module is not going into the desired module.

Sub-functions, when combined, may not produce the desired major function.

Individually acceptable imprecision may be magnified to unacceptable levels. For example, in a module there is

error-precision taken as +- 10 units. In other module same error-precision is used. Now these modules are

combined. Suppose the errorprecision from both modules needs to be multiplied then the error precision would

be +-100 which would not be acceptable to the system.

Global data structures can present problems: For example, in a system there is a global memory. Now these

modules are combined. All are accessing the same global memory. Because so many functions are accessing that

memory, low memory problem can arise.

Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover

errors associated with interfacing. The objective is to take unit tested modules, integrate them, find errors, remove them

and build the overall program structure as specified by design.

There are two approaches in integration testing. One is top down integration and the other is bottom up integration. Now

we'll discuss these approaches.

Top-Down Integration

Bottom-Up Integration

Top-Down Integration in Integration Testing

Top-down integration is an incremental approach to construction of program structure. In top down integration, first

control hierarchy is identified. That is which module is driving or controlling which module. Main control module,

modules sub-ordinate to and ultimately sub-ordinate to the main control block are integrated to some bigger structure.

For integrating depth-first or breadth-first approach is used.

193

Fig. 9.6 Top down integration

In depth first approach all modules on a control path are integrated first. See fig. 9.6. Here sequence of integration

would be (M1, M2, M3), M4, M5, M6, M7, and M8. In breadth first all modules directly subordinate at each level are

integrated together.

Using breadth first for fig. 9.6 the sequence of integration would be (M1, M2, M8), (M3, M6), M4, M7, andM5.

Another approach for integration is bottom up integration, which we discuss in the following page.

Bottom-Up Integration in Integration Testing

Bottom-up integration testing starts at the atomic modules level. Atomic modules are the lowest levels in the program

structure. Since modules are integrated from the bottom up, processing required for modules that are subordinate to a

given level is always available, so stubs are not required in this approach.

A bottom-up integration implemented with the following steps:

1. Low-level modules are combined into clusters that perform a specific software subfunction. These clusters are

sometimes called builds.

2. A driver (a control program for testing) is written to coordinate test case input and output.

3. The build is tested.

4. Drivers are removed and clusters are combined moving upward in the program structure.

194

Fig. 9.7 (a) Program Modules (b)Bottom-up integration applied to program modules in (a)

Fig 9.7 shows the how the bottom up integration is done. Whenever a new module is added to as a part of integration

testing, the program structure changes. There may be new data flow paths, some new I/O or some new control logic.

These changes may cause problems with functions in the tested modules, which were working fine previously.

To detect these errors regression testing is done. Regression testing is the re-execution of some subset of tests that have

already been conducted to ensure that changes have not propagated unintended side effects in the programs. Regression

195

testing is the activity that helps to ensure that changes (due to testing or for other reason) do not introduce undesirable

behavior or additional errors.

As integration testing proceeds, the number of regression tests can grow quite large. Therefore, regression test suite

should be designed to include only those tests that address one or more classes of errors in each of the major program

functions. It is impractical and inefficient to re-execute every test for every program functions once a change has

occurred.

Validation Testing

After the integration testing we have an assembled package that is free from modules and interfacing errors. At this

stage a final series of software tests, validation testing begin. Validation succeeds when software functions in a manner

that can be expected by the customer.

Major question here is what are expectations of customers. Expectations are defined in the software requirement

specification identified during the analysis of the system. The specification contains a section titled ―Validation Criteria‖

Information contained in that section forms the basis for a validation testing.

Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements.

There is a test plan that describes the classes of tests to be conducted, and a test procedure defines specific test cases that

will be used in an attempt to uncover errors in the conformity with requirements.

After each validation test case has been conducted, one of two possible conditions exists:

The function or performance characteristics conform to specification and are accepted, or

A deviation from specification is uncovered and a deficiency list is created. Deviation or error discovered at this stage in

a project can rarely be corrected prior to scheduled completion. It is often necessary to negotiate with the customer to

establish a method for resolving deficiencies.

Alpha and Beta testing

For a software developer, it is difficult to foresee how the customer will really use a program. Instructions for use may

be misinterpreted; strange combination of data may be regularly used; and the output that seemed clear to the tester may

be unintelligible to a user in the field.

When custom software is built for one customer, a series of acceptance tests are conducted to enable the customer to

validate all requirements. Acceptance test is conducted by customer rather than by developer. It can range from an

informal ―test drive‖ to a planned and systematically executed series of tests. In fact, acceptance testing can be

conducted over a period of weeks or months, thereby uncovering cumulative errors that might degrade the system over

time.

If software is developed as a product to be used by many customers, it is impractical to perform formal acceptance tests

with each one. Most software product builders use a process called alpha and beta testing to uncover errors that only the

196

end user seems able to find.

Customer conducts the alpha testing at the developer‘s site. The software is used in a natural setting with the developer.

The developer records errors and usage problem. Alpha tests are conducted in a controlled environment.

The beta test is conducted at one or more customer sites by the end user(s) of the software. Here, developer is not

present. Therefore, the beta test is a live application of the software in an environment that cannot be controlled by the

developer. The customer records all problems that are encountered during beta testing and reports these to the developer

at regular intervals. Because of problems reported during beta test, the software developer makes modifications and then

prepares for release of the software product to the entire customer base.

System Testing

Software is only one element of a larger computer-based system. Ultimately, software is incorporated with other system

elements and a series of system integration and validation tests are conducted. These tests fall outside the scope of

software engineering process and are not conducted solely by the software developer.

System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based

system. Although each test has a different purpose, all work to verify that all system elements have been properly

integrated and perform allocated functions. In the following section, different system tests are discussed.

Recovery Testing

Many computer-based systems must recover from faults and resume operation within a pre-specified time. In some

cases, a system may be fault tolerant; that is, processing faults must not cause overall system function to cease. In other

cases, a system failure must be corrected within a specified period or severe economic damage will occur.

Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is

properly performed. It the recovery is automated (performed by system itself), re-initialization mechanisms, data

recovery, and restart are each evaluated for correctness. If the recovery requires human intervention, the mean time to

repair is evaluated to determine whether it is within acceptable limits.

Stress Testing

Stress tests are designed to confront program functions with abnormal situations. Stress testing executes a system in a

manner that demands resources in abnormal quantity, frequency, or volume. For example, (1) special tests may be

designed that generate 10 interrupts are seconds, when one or two is the average rate; (2) input data rates may be

increased by an order of magnitude to determine how input functions will respond; (3) test cases that require maximum

memory or other resources may be executed; (4) test cases that may cause excessive hunting for disk resident data may

be created; or (5) test cases that may cause thrashing in a virtual operating system may be designed. The testers attempt

to break the program.

Security Testing

197

Any computer-based system that manages sensitive information or causes actions that can harm or benefit individuals is

a target for improper or illegal penetration.

Security testing attempts to verify that protection mechanism built into a system will protect it from unauthorized

penetration. During security testing, the tester plays the role of the individual who desires to penetrate the system. The

tester may attack the system with custom software designed to break down any defenses that have been constructed;

may overwhelm the system, thereby denying service to others; may purposely cause system errors, hoping to find the

key to system entry; and so on.

Given enough time and resources, good security testing will ultimately penetrate a system. The role of the system

designer is to make penetration cost greater than the value of the information that will be obtained in order to deter

potential threats.

Role of Quality in Software Development

Till now in this chapter we have talked about the testing of the system. Testing is one process to have a error free

system, but it is only a small part of the quality assurance activities, which are employed for achieving the good quality

and error free system. We have not yet talked about quality of system produced. Quality enforcement is very important

in system development. In this part we'll study how we can apply quality factors in order to produce a quality system.

Here mainly software system and quality is considered.

We employ software to solve and simplify our real-life problems and it goes without saying that it should be of high

class i.e. quality software, thus here the software quality and it's assurance come into the picture. Software quality

assurance is an umbrella activity, which must be applied throughout the software engineering process. But this leads us

to few questions such as how to define quality and what exactly it is with respect to software. Hence it becomes a

subjective issue but then there are some basic do's and don‘ts to be taken care of during the course of software cycle

which if applied thoroughly will lead to a reasonable quality software and that is what the following definition of

software quality states- Conformance to explicitly stated functional and performance requirements, explicitly

documented development standards and implicit characteristics that are expected of all professionally developed

software.

Though this definitions speak a volume about the matter, to further make it more simple for our understanding we can

focus on the points given below.

Software requirements have to be met by the newly developed system and thus any lack of conformance in them will be

serious quality lag.

Specified standards define a development criteria which displays the manner in which the software is engineered. Any

deviation from the given criteria will result into lack of the quality.

No matter how much vocal, straight, honest and frank the client may be but then there are always a set of implicit

requirements which are not mentioned but they should be met.

The dominant nature of the software market is its dynamic growth. New application areas are continually emerging

198

along with birth of new technologies. New methods of information processing and new programming environments

have created a dilemma in management of software development. For software developers whatever they produce , it

must be sold in order to survive in this dynamic software industry. Also these companies should always try for

continuous improvement in quality.

For quality, Software Engineering Institute Carnegie Mellon University, Pennsylvania has devised a quality model

known as Capability Maturity Model CMM. This model is based on the principles of Total Quality Management(TQM)

for improving the entire software development process. The goal of CMM is that a firm's process capability is reflected

to the extent to which it plans for and monitors software quality and customer satisfaction. As organizations grow,

software project management practices are adequately utilized and software development undergoes a more refined

process. In CMM , the process capability of a company is understood in five advancing maturity levels, a brief overview

of them is given below:

LEVEL 1 : Initial - processes are not adequately defined and documented.

LEVEL 2 : Repeatable - implementation of project management tools.

LEVEL 3 : Defined - all projects use an organized, documented and standardized set of activities that are implemented

throughout the project life cycle.

LEVEL 4 : Managed - Specific process and quality outcome measures are implemented.

LEVEL 5 : Optimized - Continuous process improvement is adopted in the entire organization. Sophisticated methods

of defect prevention, technology changes management and process change management is implemented.

The CMM has become tool to evaluate the potential of an organization to achieve high quality in software development.

Each software company should aim to achieve high CMM level.

Software Quality Factors

Till now we have been talking software quality in general. What it means to be a quality product. We also looked at

CMM in brief. We need to know various quality factors upon which quality of a software produced is evaluated. These

factors are given below.

The various factors, which influence the software, are termed as software factors. They can be broadly divided into two

categories. The classification is done on the basis of measurability. The first category of the factors is of those that can

be measured directly such as number of logical errors and the second category clubs those factors which can be

measured only indirectly for example maintainability but the each of the factors are to be measured to check for the

content and the quality control. Few factors of quality are available and they are mentioned below.

Correctness - extent to which a program satisfies its specification and fulfills the client's objective.

Reliability - extent to which a program is supposed to perform its function with the required precision.

Efficiency - amount of computing and code required by a program to perform its function.

Integrity - extent to which access to software and data is denied to unauthorized users.

199

Usability- labor required to understand, operate, prepare input and interpret output of a program

Maintainability- effort required to locate and fix an error in a program.

Flexibility- effort needed to modify an operational program.

Testability- effort required to test the programs for their functionality.

Portability- effort required to run the program from one platform to other or to different hardware.

Reusability- extent to which the program or it‘s parts can be used as building blocks or as prototypes for other

programs.

Interoperability- effort required to couple one system to another.

Now as you consider the above-mentioned factors it becomes very obvious that the measurements of all of them to some

discrete value are quite an impossible task. Therefore, another method was evolved to measure out the quality. A set of

matrices is defined and is used to develop expressions for each of the factors as per the following expression

Fq = C1*M1 + C2*M2 + …………….Cn*Mn

where Fq is the software quality factor, Cn are regression coefficients and Mn is metrics that influences the quality

factor. Metrics used in this arrangement is mentioned below.

Auditability- ease with which the conformance to standards can be verified.

Accuracy- precision of computations and control

Communication commonality- degree to which standard interfaces, protocols and bandwidth are used.

Completeness- degree to which full implementation of functionality required has been achieved.

Conciseness- program‘s compactness in terms of lines of code.

Consistency- use of uniform design and documentation techniques throughout the software development.

Data commonality- use of standard data structures and types throughout the program.

Error tolerance – damage done when program encounters an error.

Execution efficiency- run-time performance of a program.

Expandability- degree to which one can extend architectural, data and procedural design.

Hardware independence- degree to which the software is de-coupled from its operating hardware.

Instrumentation- degree to which the program monitors its own operation and identifies errors that do occur.

Modularity- functional independence of program components.

Operability- ease of programs operation.

Security- control and protection of programs and database from the unauthorized users.

Self-documentation- degree to which the source code provides meaningful documentation.

Simplicity- degree to which a program is understandable without much difficulty.

Software system independence- degree to which program is independent of nonstandard programming language

features, operating system characteristics and other environment constraints.

Traceability- ability to trace a design representation or actual program component back to initial objectives.

Training- degree to which the software is user-friendly to new users.

There are various ‗checklists‘ for software quality. One of them was given by Hewlett-Packard that has been given the

acronym FURPS – for Functionality, Usability, Reliability, Performance and Supportability.

Functionality is measured via the evaluation of the feature set and the program capabilities, the generality of the

functions that are derived and the overall security of the system.

200

Considering human factors, overall aesthetics, consistency and documentation assesses usability.

Reliability is figured out by evaluating the frequency and severity of failure, the accuracy of output results, the mean

time between failure (MTBF), the ability to recover from failure and the predictability of the program.

Performance is measured by measuring processing speed, response time, resource consumption, throughput and

efficiency. Supportability combines the ability to extend the program, adaptability, serviceability or in other terms

maintainability and also testability, compatibility, configurability and the ease with which a system can be installed.

Software Quality Assurance

Software quality assurance is a series of planned, systematic sequential actions that enable the quality of the software

produced. Usually all software development units have their own Software quality assurance (SQA) team.

This Software quality assurance (SQA) team takes care of the quality at the high end that is the overall product and at

the lower order the quality is the sole responsibility of the individual who may engineer, review and test at any level.

Fig. 9.9 The adoption of the philosophy of Continuous Improvement in the software development life cycle.

Software quality has to be a characteristic of the software produced and thus it is designed into it rather than to be

imposed later. It is the duty of every individual in the software development team that quality is maintained even before

some formal quality assurance procedures are applied. This practice can improve the quality of all the software

produced by the organization.

Activities Involved in Software Quality Assurance

Application of Technical methods

FTR (Formal Technical Review)

Software Testing

201

Control of change

Measurement

Record keeping and reporting

Activities Involved in Software Quality Assurance

Software quality assurance clubs together various tasks and activities. There are seven major activities namely

application of technical methods, conducting of Formal Technical Reviews (FTR), software testing, control of change,

measurement and record keeping and reporting.

Software Quality Assurance (SQA) starts early along with the process of software development. It is initiated with the

help of technical methods and tools that enable the analyst to achieve a high quality specification and help the designer

to develop a high-quality design. We can always point specifications ( or the prototype ) and the design are individually

checked for quality.

Formal Technical Reviews (FTR) is employed for this purpose and by its means the members of the technical staff

undergo a meeting to identify the quality problems. Many-a-times reviews are found to be equally effective just as the

testing of uncovering defects in software. The next step in the software testing which involves a series of test case

design methods to enable effective error detection. It is believed that the software testing can dig out most of the errors

but practically as the fact goes no matter how rigorous the testing may be it is unable to uncover all the errors. Some

errors remain uncovered. Hence we have to look up to other measures also but this should not diminish the importance

of software testing.

Application of formal and systematic standards and procedures vary from project to project and company to company.

Either the standards are self-imposed in the whole of the software engineering process by the software development

team or they are carried out as per the client‘s dictation or as a regulatory mandate. If formal i.e. written,

welldocumented standards are not available then it becomes imperative to initiate an Software Quality Assurance (SQA)

activity so that the standards are complied with. Also an assessment of this compliance must be regularly undertaken

either by the means of Formal Technical Reviews (FTR) or as an Software Quality Assurance (SQA) group audits

which the team may do on its own.

Nothing bothers the whole of the software engineering process more than the changes. Any and every change to

software will almost incorporate an error or trigger side effects that will propagate errors. The ill influence of changes

can vary with nature of the change and it also depends at which stage they are to be incorporated. Early changes are

much less harmful than the ones, which are taken into design at a later stage. This is so because any change in the

specification or the design will demand a re-lay out of all the work done so far and in the subsequent plans.

Hence the importance of a well-defined specification and detail design are again highlighted. Before the coding starts

these designs are to be freezed and all the software development process after the detail design takes the design skeleton

as the base on which the software is built. Therefore both the client and the software development team should be sure

202

of the design developed before they freeze it and the process goes to the next step.

Any doubts or requests should be taken into account then and there only. Any further request to add new features from

the client will lead to changes in the design and it will result in more effort and time requirements on the software

development team‘s behalf. Needless to add, this will invariably result in the increase in the software cost. Hence to

minimize these effects, change control process activity is used. It contributes to the software quality by formalizing the

requests for change by evaluating its nature and also controlling its impact. Change control is applied during software

development and also later during the maintenance phase.

Measurement is such an activity that it cannot be separated from any engineering discipline as it is an integral part of it.

So it comes into action here also. Software metrics is used to track software quality and to evaluate the impact of

methodological and procedural changes. These metrics encompass a broad array of technical and management oriented

measures.

Records are usually developed, documented and maintained for reference purposes. Thus record keeping and recording

enable the collection and distribution of Software Quality Assurance (SQA) information.

The documents of reviews, results of Formal Technical Reviews (FTR), audits, change control, testing and other

Software Quality Assurance (SQA) activities become a part of the project and can be referred by the development staff

on a need to know basis.

We now know various activities involved in quality assurance activity. Now we‘ll take one activity at a time and look

into it in detail.

Application of Technical methods in Software Quality Assurance

There are two major objectives to be achieved by employing technical methods, firstly the analyst should achieve a high

quality specification and the designer should develop a high quality design.

Firstly we will take up the specification part. There is no doubt on the fact that a complete understanding and clarity of

software requirements is essential for the appropriate and suitable software development. No matter how well designed,

well coded but a poorly analyzed and specified program will always be a problem for the end-user and bring

disappointment to the developer.

The analyst plays the major role in the requirements analysis phase and he must exhibit the following traits…

The ability to grasp abstract concepts, reorganize into logical divisions and synthesize ―solutions‖ based on each

division.

The ability to absorb pertinent facts from conflicting or confused sources.

The ability to understand the user/client environment.

The ability to apply the hardware and/or software system elements to the user/client environments.

Software requirements must be uncovered in a ―top-down‖ manner, major functions, interfaces and information must be

fully understood before successive layers of detail are specified.

203

Modeling

During software requirements analysis, models of the system to be built are created and these models focus on what the

system must do and not on how it has to do. These models are a great help in the following manner….

The model aids the analyst in understanding about the system‘s function, behavior and it‘s other information thus

making the analysis task easier and systematic.

The model is the standard entity for review and it is the key to determine completeness, consistency and accuracy of the

specification.

The model is the base/foundation for the design and thus it serves as the representation of the software that can be

―mapped‖ into an implementation context.

Partitioning

Quite often problems are too large and complex to be grasped as a whole and then it is very reasonable to

partition/divide them into smaller parts so that they individually become much easier to understand and in the end one

can establish interfaces between the parts so that the overall function can be accomplished. During the requirement

analysis the information, functional and behavioral domains of software can be partitioned.

Specification Principles

Specification methods irrespective of the modes via which they are carried out are basically a representation process.

Requirements are represented in such a manner that leads to successful software implementation. Blazer and Goldman

proposed eight principles of good specification and they are given as follows..

1. Separate functionality from implementation: As per the definition, the specification is a description of what is

desired rather than how it is to be realized/implemented. Specification can have two forms. The first form is that

of mathematical functions in which as per the given set of inputs a particular set of outputs is produced. In such

specifications , the result to be obtained is entirely expressed in a what rather than how form. Thus the result is

the mathematical function of the input.

2. A process-oriented systems specification language is required: Here we will take up the second form of the

specification. In this situation the environment is dynamic and its changes affect the behavior of some entity

interacting with the environment. This is similar to the case of embedded computer system.

Here no mathematical function can express the behavior. To express the same we have to use process-oriented

description in which the what specification is expressed by specifying a model of the required behavior in the

terms of functional responses to various inputs from the environment. Now such kind of process-oriented

specifications, which represent the model of the system behavior, have been usually excluded from the formal

specification languages but one can not do without them if more complex dynamic situations are to be expressed.

3. A specification must encompass the system of which the software is a component. Interacting components make

up a system. The description of each component is only possible in the complete context of the ent ire system

therefore usually a system can be modeled as collection of passive and active components. These objects are

interrelated and their relationship to each other is time-variant. Stimulus to active objects or agents as they are

204

called are given by the dynamic relationships and to these the agents respond which may further cause changes

to which again the agents respond.

4. A specification must encompass the environment in which the system operates. Similarly, the environment in

which the system operates and with which it interacts must be specified.

Conduct of Formal Technical Reviews (FTR)

The FTR (Formal Technical Review) is a software quality assurance activity with the objectives to uncover errors in

function, logic or implementation for any representation of the software; to verify that the software under review meets

its requirements; to ensure that the software has been represented according to predefined standards; to achieve software

that is developed in a uniform manner and to make projects more manageable.

FTR (Formal Technical Review) is also a learning ground for junior developers to know more about different

approaches to software analysis, design and implementation. It also serves as a backup and continuity for the people

who are not exposed to the software development so far. FTR (Formal Technical Review) activities include

walkthroughs, inspection and round robin reviews and other technical assessments. The above-mentioned methods are

different FTR (Formal Technical Review) formats.

Review meetings

Review meeting is important form of FTR (Formal Technical Review) and there are some essential parameters for the

meeting such as there should be reasonable number of persons conducting the meeting and that too after each one of

them has done his/her homework i.e. some preparation and the meeting should not be carried out very long which may

lead to wastage of time but rather for duration just enough to churn out some constructive results. FTR (Formal

Technical Review) is effective when a small and specific part of the overall software is under scrutiny. It is easier and

more productive to review in small parts like each module one by one rather than to review the whole thing in one go.

The target of the FTR (Formal Technical Review) is on a component of the project, a single module.

The individual or the team that has developed that specific module or product intimates the product is complete and a

review may take place. Then the project leader forwards the request to the review leader who further informs the

reviewers who undertake the task. The members of the review meeting are reviewers who undertake the task. The

members of the review meeting are reviewers, review-leader, product developers ( or the module leader alone ) and

there one of the reviewers takes up the job of the recorder and notes down all the important issues raised in the meeting.

At the end of each review meeting the decision has to be taken by the attendees of the FTR (Formal Technical Review)

on whether to accept the product without further modification or to reject the product due to severe errors or to accept

the product provisionally. All FTR (Formal Technical Review) attendees sign off whatever decision taken. At the end of

the review a review issues list and a review summary is report is generated.

Software Testing

System Quality Assurance (SQA) is incomplete without testing and testing is carried out to verify and confirm that the

software developed is capable enough to implement, carry out the tasks for which it has been developed. Tests carried

should be able to determine any previous undetected errors that might hamper the smooth functioning of the system.

205

There are two different approaches to it. First is the classroom testing where we test and retest the program until they

work but in our business environment a more professional approach is taken where we actually try to make the

programs fail and then continue testing until we cannot deliberately make them fail any more.

Hence the objective is to take care of all possible flaws so that no null, void, vague case or doubt remains before it is

installed at the client‘s site. The data used for testing can either be an artificial or mock data when the system is new or

it can be taken from the old system when a new system has replaced it.

The volume of data required is very high for adequate testing. This is because all the data used may not be able to mirror

all the real situations that the system will encounter later. Testing is such an important stage in the software development

that usually 30% of the software development cycle time is dedicated to it.

Control of change in Software Quality Assurance

During the development of software product, changes are difficult to avoid. There is always a need for some change in

the software product. Though these changes must be incorporated into software product, but there should be a specific

procedure that must be followed for putting the changes in the product. Before a change is implemented, the required

change should be thoroughly analyzed, recorded and reported to people who are responsible for controlling them for

quality and errors.

For all these activities there is software configuration management(SCM). It is applied throughout the software

engineering process as changes can occur at any stage of software development. SCM activities identifies and control

changes and ensures that these changes are properly implemented. A typical change control process that is followed in

many software development process is illustrated in fig 9.10.

First thing is need for change is recognized and request of change is submitted. Developers analyze the request and

makes a change report and it is submitted to change control authority. It is up to the authority to grant permission or

deny request. In case change request is denied, the user is informed about it.

If permission is granted then an Engineer Change Order (ECO) is generated which contains details of the changes to be

made. The individual software engineer is assigned the configuration object that requires change. These objects are

taken out of system, changes are made upon them and finally changes are reviewed and again they are put into system.

Testing strategy is finalized. Quality assurance and testing activities are performed. Changes done to the system are

promoted. New version of software is built. Changes made to the software product are again reviewed and finally the

new version with the required changes is distributed.

There are two more activities in SCM. These are ‗check in‘ and ‗check out‘ processes for access control and

synchronization control.

Access control determines which software engineer has the authority to change and modify a configuration object. More

than one software engineer can have the authority over a particular object. Access control is very important it is not

advisable to grant access to objects to everyone. Then everybody can make changes to the object Synchronization

206

controls the parallel changes, done by two or more developers. It ensures one developer is not writing over the work of

the other developer.

Fig. 9.10 Change Control Process

207

Fig. 9.11 Access and synchronization control

Once it is assigned to a software engineer for change then it is locked for other software engineers who might also have

access for it. This process is check-out for that object. The software engineer modifies the object and it is reviewed. It is

then check in. That lock that has been put on the object is unlocked and can be given to other software engineers if

required. In this way there is no chance of one developer writing over the work of other developer.

Measurement - Software Quality Assurance Activities

Earlier in this chapter we discussed what is the objective and meaning of the quality with respect to software

development. We defined a set of qualitative factors of the software quality measurement. Since there is no such thing

as absolute knowledge we can‘t expect to measure software quality exactly. Therefore SQ metrics is developed and

employed to figure out the measure, content of the quality. A set of software metrics is applied to the quantitative

assessment of software quality. In all cases these metrics use indirect measures therefore quality as such in itself is never

measured but rather some manifestation of it.

There are a number of software quality indicators that are based on the measurable design characteristics of a computer

program. Design structural quality index (DSQI) is one such measure. The following values must be ascertained to

compute the DSQI

S1 = the total number of modules defined in the program architecture

S2 = the number of modules whose correct function depends on the source of data input or that produces data to be used

elsewhere {in general control modules (among others) would not be counted as part of S2}

S3 = the number of modules whose correct function depends on prior processing

S4 = the number of database items (includes data objects and all attributes that define objects)

208

S5 = the total number of unique database items

S6 = the number of database segments ( different records or individual objects)

S7 = the number of modules with a single entry and exit ( exception processing is not considered to be a multiple exit)

When all these values are determined for a computer program, the following intermediate values can be computed:

Program structure: D1, where D1 is defined as follows:

If the architectural design was developed using a distinct method( e.g., data flow-oriented design or object oriented

design), then D1 = 1; otherwise D1 = 0.

Module independence: D2 = 1 -(S2/S1)

Module not dependent on prior processing: D3 = 1- (S3/S1)

Database size : D4 = 1- (S5/S4)

Database compartmentalization: D5 = 1- (S6/S4)

Module entrance/exit characteristic: D6 = 1- (S7/S1)

With the intermediate values determined, the DSQI is computed in the following manner: DSQI = Swi Di

Where i = 1 to 6, wi is the relative weighting of the importance of each of the intermediate values, and Swi = 1 ( if all Di

are weighted equally, then wi = 0.167).

The value of DSQI for past designs can be determined and compared to a design that is currently under development. If

the DSQI is significantly lower than average, further design work and review is indicated. Similarly, if major changes

are to be made to an existing design, the effect of those changes on DSQI can be calculated.

IEEE Standard 982.1-1988 suggests a software maturity index (SMI) that provides an indication of the stability of a

software product ( based on changes that occur for each release of the product). The following information is

determined:

MT = the number of modules in the current release

Fc = the number of modules in the current release that have been changed

Fa = the number of modules in the current release that have been added

Fd = the number of modules from the preceding release that were deleted in the current release

209

The software maturity index is computed as :

As SMI approaches 1.0, the product begins to stabilize

Record keeping and reporting in Software Quality Assurance

Record keeping and reporting are another quality assurance activities. It is applied to different stages of software

development.

During the FTR, it is the responsibility of reviewer (or recorder) to record all issues that have been raised.

At the end of review meeting, a review issue list that summarizes all issues, is produced. A simple review summary

report is also compiled.

A review summary report answers the following questions.

1. What was reviewed?

2. Who reviewed it ?

3. What were the findings and conclusions?

Following figure shows a sample summary report. This becomes an important document and may be distributed to

project leader and other interested parties.

Technical Review Summary Report

Review identification :

Project: XXX00

Date : 11th July'1996

Review Number : X-00012

Location: Old Bldg, Room# 4 Time: 10:00 AM

Product Identification

Material Reviewed : Detailed Design module for penalty collection

210

Producer : Griffin

Brief Description : Penalty collection module for books

returned after due date.

Material Reviewed : ( note each item separately )

1. Penalty rules

Review Team: Signature

1. Griffin (Leader)

2. Hardy (Recorder)

3. Watson

Product Appraisal:

Accepted : as is ( ) with minor modifications ( )

Not Accepted: major revision ( ) minor revision ( )

Review Not completed: ( Explanation follows )

Supplementary material attached:

Issue list( ) Annotated Materials ( )

Other (describe)

The review issue list serves the following purpose.

1. To identify problem areas within the product.

211

2. To serve as an action item checklist that guides the producer as corrections are made.

Follwong figure shows a issue list.

Review Number : XX10

Date of Review : 07-07-98

Review leader : Griffin Recorder : Hardy

ISSUE LIST

1. Penalty rules ambiguous. The penalty rules are not clear. Needs more clarity.

Review team recommends a modification in the penalty rules module.

It is important to establish a follow-up procedure to ensure that items on the issue list have been properly corrected.

Review issue list provides the basis for the follow-up procedure to be carried out. After the follow-up procedure, review

issue list can be used to cross-check the corrections made. Once all this is done and review findings are incorporated, the

quality of the system is ensured. This is how various techniques and procedures may be used for delivering a quality

system to the vendors.

Software Maintenance

It is impossible to produce systems of any size, which do not need to be changed. Over the lifetime of a system, its

original requirements will be modified to reflect changing user and customer needs. The system's environment will

change as new hardware is introduced. Error, undiscovered during system validaton, may merge and require repair.

The process of changing of a system after it has been delivered and is in use is called Software maintenance. The

changes may involve simple changes to correct coding errors, more extensive changes to correct design errors or

significant enhancement to correct specification errors or accomodate new requirements. Maintenance therefore, in this

context, really means evolution. It is the process of changing a system to maintain its ability to survive.

There are three types of software maintenance with very blurred distinction between them.

1. Corrective maintenance

2. Adaptive maintenance

3. Perfective maintenance

Follwing figure illustrates the maintenance effort distributionin software maintenance.

212

Maintenance Effort Distribution

Corrective Maintenance

Corrective Maintenance is concerned with fixing reported errors in the software. Coding errors are usually relatively

cheap to correct; design errors are more expensive as they may involves the rewriting of several programs components.

Requirements errors are the most expensive to repair because of the extensive system redesign with may be necessary.

Adaptive maintenance

Adaptive maintenance means changing the software to new environment such as different hardware platform or for use

with a different operating systems. The software functionality does not radically change.

Perfective maintenance

Perfective maintenance involves implementing ne wfunctional or non-functional system requirements. These are

generated by software customers as their organization are business changes.

It is difficult to find up-to-date figures for their relative effort devoted to these different types of maintenance. A survey

by Lientz and Swanson (1980) discovered that about 65% of maintenance was perfective, 18% adaptive and 17%

corrective shown in figure. And also Lientz and Swanson found that large organizations devoted at least 50% of their

total programming effort for maintaining existing systems. The costs of adding functionality to a system after it has been

put into operation are usually much greater than providing similar functionality when software is originally developed.

There are a number of reasons for this:

1. Maintenance staffs are often relatively inexperienced and unfamiliar with the applications domain. Maintenance

has a poor image among software engineers. It is seen as a less skilled process than system development and is

often allocated to the most junior staff.

2. The program being maintained may have been developed many years ago without modern software engineering

techniques. Thay may be unstructured and optimized for efficiency rather than understandability.

3. Changes made to a program may introduce new faults, which trigger further change requests. New faults may be

introduced because the complexity of the system may make it difficult to access the effects of a change.

4. As a system is changed, its structure tends to degrade. This makes the system harder to understand and makes

213

further changes difficult as the program becomes less cohesive.

5. The links between a program and its associated documentation are sometimes lost during the maintenance

process. The documentation may therefore be an unreliable aid to program understanding.

The first of these problems can only be tackled by organization adapting enlightened maintenance management policies.

management must demonstrate to engineer that maintenance is of equal value and is as challenging as original software

development. The best designers and programmers should be challenged and motivated by system maintenance. Boehm

(1983) suggested several steps that can improve maintenance staff motivation.

1. Couple software objectives to organizational goals.

2. Couple software maintenance rewards to organizational performance

3. Integrate software maintenance personnel into operational teams.

4. Create a discretionary, preventive maintenance budget, which allows the maintenance team to decide when to re-

engineer parts of the software. Preventive maintenance means making changes to the software, which improve

its structure so that future maintenance is simplified.

5. Involve maintenance staff early in the software process during standard preparation, reviews and test

preparation.

The second of the above problems, namely unstructured code, can be tackled using re-engineering and design recovery

tecniques.

The other maintenance problems are process problems. Structure naturally degrades with changes. Organizations must

plan to invest extra effort and resources in preventive maintenance with the aim of maintaining the structure. Good

software engineerign practice such as the use of information hiding or object-oriented development helps minimize the

structure degradation but effort for structure maintenance is still required.