c:documents and settingssudhe - niilm university · 1 systems anal ysis chapter-1 lesson 01: life...

System Analysis & Management

Subject: SYSTEM ANALYSIS & MANAGEMENT Credits: 4

SYLLABUS

Introduction to analysis and designSDLC, case tools for analyst, role of system analyst, ER data models, feasibility study-economic, technical, operational

Design of applicationDFDs, form design, screen design, report design, structure chart, data base definition, equipment specification and selection personnel extimates, I-O design.

ImplementationData dictionary, decision tables, decision trees, logical design to physical implementation.

Introduction to distributed data processing and real time systemEvaluating distributing system, designing distributed data base, event based real time analysis tools state transition diagrams.

Suggested Readings:

1. James A., Analysis and Design of Information System, McGraw Hill.2. Len, Fertuck, System Analysis and Design, McGraw Hill3. Powers, Cray, System Analysis and Design, McGraw Hill4. Elias, M., System Analysis and Design, Prentice Hall of India

i

SYSTEM ANALYSIS

COURSE OVERVIEW

The study of data structures is an essential part of virtually

every computer course, as data structures show how data is

actually organized and used by the computer. This unit

provides the student with a range of experiences in using the

algorithms and data structures that underpin much of today’s

computing. The various techniques presented should be seen in

the context of solving problems using computers.

This subject is too big to be covered in its entirety in the time

available, so the aim must be to provide a range of experi-

ences, which can be applied to problems, and the performance

and resource issues which ensue.

This should allow students to develop solutions using data

structures for a range of commercial needs.

iii

. Lesson No. Topic Page No.

Lesson 1 The System Definitions 1

Lesson 2 Objective of a System 6

Lesson 3 Role of System Analyst 11

Lesson 4 Elements of a System 17

Lesson 5 Characteristics of a System 21

Lesson 6 Introduction to Types of System 24

Lesson 7 Types of models 27

Lesson 8 Overview of SDLC 33

Lesson 9 Stages of SDLC 37

Lesson 10 Stages of SDLC System Approaches 41

Lesson 11 Stages of SDLC 48

Lesson 12 Definition of validation and verification 51

Lesson 13 Validation and Verification 56




Lesson 17 Evaluation of models 74

Lesson 18 Object Based Methods 79

Lesson 19 Object Based Methods 87

Lesson 20 Introduction to System Investigation fact Finding Techniques 100

Lesson 21 Fact Finding Techniques 106



CONTENT

SYSTEMS ANALYSIS

iv

SY

ST

EM

SA

NA

LYS

IS

. Lesson No. Topic Page No.

Lesson 24 Fact recording Flow diagrams 121

Lesson 25 Stanadard Documentation Techniques 126

Lesson 26 Overview of Functional and data Modelling 129

Lesson 27 Data Flow Diagram 134

Lesson 28 Data Flow Diagram and Entity Diagram 137

Lesson 29 Overview of Data Modelling 140

Lesson 30 Entity Identification 143

Lesson 31 Entity Relationships 146

Lesson 32 Context Diagrams 150

Lesson 33 System Modeling 154

Lesson 34 Normalization 160

Lesson 35 Information Analysis 164

CONTENT

SYSTEMS ANALYSIS

1

SYSTEM

S AN

ALY

SIS

CHAPTER-1LIFE CYCLE MODELSLESSON 01:

SYSTEM DEFINITIONS

Topics Covered• Introduction to System Concept• The System Definitions• Objectives• Introduction to Computer Base Information System (CBIS)

Objectives• Upon completion of this Lesson, you should be able to:• Explain the Nature and Scope of System• Explain the need of system analysis.

Introduction

What is a System?Generally we come into daily contact with the transportationsystem, the telephone system, the accounting system, theproduction system , and for over tow decades, the “computersystem”.

Introduction to System ConceptThere are many common types of systems that we come intocontact with every day. It is important to be familiar with differentkinds of systems for at least two reasons:• First, even though your work as a systems analyst (we will

discuss about system analyst in detail in the later lessons)willprobably focus on one kind of system – an automated,computerized information system – it will generally be a partof a larger system.

• For example, you may be working on a payroll system, whichis part of a larger “human resources” system, which is, in turn,part of an overall business organization (which is itself, asystem), which is, in turn, part of al larger economic system,and so on.

• Thus, to make your system successful, you must understandthe other systems with which it will interact. Many of thecomputer systems that we build are replacements, or newimplementations of, non-computerized systems that arealready in existence.

• Also, most computer systems interact with, or interface with, avariety of existing systems (some of which may becomputerized and some which may not).

If our new computer system is to be successful, we mustunderstand, in reasonable detail, how the current system behaves.• Second, even though many types of systems appear to be

quite different, they turn out to have many similarities.• There are common principles and philosophies and theories

that apply remarkably well to virtually all kinds of systems.• Thus, we can often apply to systems that we build in the

computer field, what we have learned about other systems,

based on our own day-to-day experience, as well as the experienceof scientists and engineers in a variety of fields.

• Thus, if we understand something of general systems theory,it can help us better understand computerized (automated)information systems.

• Today, this is more and more important, because we want tobuild stable, reliable systems that will function well in ourcomplex society, and of course, there are many examples ofnon-computer systems that have survived for thousands ofyears.

And now, we can consider a definition of the basic term “system”.It provides several definitions:• A regularly interacting or interdependent group of items

forming a unified whole.• An organized set of ideas, or principles, usually intended to

explain the arrangements or working of a systematic whole.• An organized or established procedure.• Harmonious arrangement or pattern: order.

The System DefinitionsDo u know from where the term system is derived?

• The term system is derived from the Greek word systema,which means an organized relationship among functioningunits or components.

• A system exists because it is designed to achieve one or moreobjective.

• Similarly, we talk of the business system and of the organizationas a system consisting of interrelated departments (subwaysterms) such as production, sales, personnel, and an informationsystem.

• What is an Information System?• An information system is an arrangement of people, data,

processes, interfaces, networks, and technology that interact forthe purpose of supporting and improving both day-to-dayoperations in a business (sometimes called data processing), aswell as supporting the problem solving and decision making

needs of management (sometimes called information services).

What is a Computer Application System?

• A computer application is computer-based solution to one ormore business problems and needs. One or more computerapplications are typically contained within an informationsystem.

2

SalesSystem

ProductionSystem

PersonnelSystem

InformationSystem

• None of these subsystems is of much use as a single,independent unit. When they are properly coordinated,however, the firm can function effectively and profitably.

The noun “system” has 9 senses such as.

1. SystemA group of independent but interrelated elements comprising aunified whole; “a vast system of production and distribution andconsumption keep the country going”.

2. SystemInstrumentality that combines interrelated interacting artifactsdesigned to work as a coherent entity; “he bought a new stereosystem”; “the system consists of a motor and a small computer”.

3. System, System of RulesA complex of methods or rules governing behavior; “they haveto operate under a system they oppose”.

4. SystemA procedure or process for obtaining an objective.

5. SystemA group of physiologically or anatomically related organs or parts;“the body has a system of organs for digestion”.

6. System (Arrangement)An organized structure for arranging or classifying; “he changedthe arrangement of the topics”; “the facts were familiar but it wasin the organization of them that he was original”; “he tried tounderstand their system of classification”.

7. System (Physical Chemistry)A sample of matter in which substances in different phases are inequilibrium; “in a static system oil cannot be replaced by water ona surface”; “a system generating hydrogen peroxide”.

8.System The living body considered as made up of interdependentcomponents forming a unified whole; “exercise helped him getthe alcohol out of his system”.

9. System (Organization)An ordered manner; orderliness by virtue of being methodicaland well organized; “his compulsive organization was not anendearing quality”; “we can’t do it unless we establish some systemaround here”.

There are more than a hundred definitions of the

word ‘system’ some important definitions of the

term systems are as follows:

• A system is an orderly grouping of interdependent componentslinked together according to a plan to achieve a specific objective.

• A system is an organized interacting, interdependent andintegrated set of components/variables/parts. A system hasobjectives/goals.

• Webster dictionary describes system as asset or arrangement ofthings so related or connected to from a unity or organization.

• A system is a set of elements forming an activity or a processingprocedure or a scheme, seeking common goal(s) by operatingon data/energy/matter (inputs) in a time reference to yieldinformation on energy/output.

• McGraw-Hill dictionary of computers describes system as acombination of two or more sets generally physically separatedwhen in operation, and such other assemblies, sub-assembles,and pars necessary to perform an operational function(s).

• System definition is the most critical phase in any manufacturingproject. The functionality and performance of a product aredefined in this stage, which becomes the basis for determiningproduct specifications and capabilities.

The System Concept• Ludwig von Bertalanffy, a biologist, developed a general systems

theory that applies to any arrangement of elements such ascells, people, societies, or even planets.

• Norbert Wiener, a mathematician, observed that informationand communications provide connection links for unifyingfragments or elements. His systems concept of informationtheory, which shows the parallel between the functioning ofhuman beings and electronic systems, laid the foundation fortoday’s computer systems.

• Herbert A. Simon, a political scientist, related the systemsconcept to the study of organizations by viewing an ongoingsystem as a processor of information for making decisions.

• Systems analysis and design for information systems werefounded in general systems theory, which emphasizes a closelook at all parts of a systems. Too often analysts focus on onlyone component and overlook other equally importantcomponents.

• General systems theory is concerned with “developing asystematic, theoretical framework upon which to makedecisions.” . The idea of system has become most practicaland necessary in conceptualizing the interrelationships andintegration of operations, especially when using computers.Thus, a systems is away of thinking about organizations andtheir problems. It also involves a set of techniques that helpsin solving problems.

3

Introduction to Computer BaseInformation System(CBIS)• Systems analysis and design provide a structural approach to

the design and development of Computer Base InformationSystem (CBIS).

• The tasks involve in the design and development of CBIS canbe broadly classified into three categories, namely,(a) Systems Analysis.(b) Logical System Design.(c) Physical System Design.

• Our subject deals with only the first part System Analysis.• The second part logical design provides logic for obtaining the

desired outputs for available inputs.• The third part physical design maps the logical design onto the

physical hardware of a computer system.

There are many ways of classifyingsystems.Common classifications are• Natural or man-made system.• Closed/open system.• Conceptual/physical system.Natural systems occur in nature, e.g., solar system, whereas man-made systems are specially created for specific objectives, e.g., defensesystem, telephone system, accounting system, production system,etc. Other types are discussed in the later chapters.

System Analysis–What and Why?• Systems analysis is the reduction of an entire system by

studying various operations performed and their relationshipwithin the system; an examination of a business activity with aview to identifying problem area and recommending alternativesolutions.

• System analysis thus emerges as a means through which thetotal system is conceived, designed, implemented and madeoperational to achieve the desired objective.

• Thus, systems analysis specifically• Offers a means to greater understanding of the complex

structures.• Is a means to trade off between functional requirement of a

subsystem (component) and its immediately relatedsubsystem?

• Helps in understanding and comparing functional impacts ofsubsystems to the total systems.

• Helps in achieving inter-compatibility and unity of purpose ofsubsystems.

• Helps in discovering means to design systems where subsystemmay have apparently conflicting objectives.

• Helps in placing each subsystem in its proper perspective andcontext, so that the system as a whole may best achieve itsobjective with minimum available resources. It this createssynchronization between system and objectives.

• Thus, systems analysis is one of the important techniques thatprovide a systematic and broader outlook to understanding,examining and creating or modifying systems to meet specificobjectives. Systems analysis and design is an interactive andcreative process.

System Analysis Definition• A systematic investigation of a real or planned system to

determine the functions of the system and how they relate toeach other and to any other system.

• The analysis of the requirements of a task and the expressionof those requirements in a form that permits the assembly ofcomputer hardware and software to perform the task.

• The analysis of the role of a proposed system and theidentification of the requirements that it should meet. SAD(System Analysis and Design) is the starting point for systemdesign. The term is most commonly used in the context ofcommercial programming, where software developers are oftenclassed as either systems analysts or programmers. The systemsanalysts are responsible for identifying requirements (i.e. systemsanalysis) and producing a design. The programmers are thenresponsible for implementing it.

• A systematic investigation of a real or planned system todetermine the functions of the system and how they relate toeach other and to any other system.

• The Concise Oxford Dictionary of Current English statesthat system analysis is the analysis of a complex process or

operation in order to improve its efficiency.

• The beginning step of systems analysis, inwhich the end user’s requirements are defined in

order to get an idea of what kind of system must be designedto meet those needs.

Types of Information SystemsOrganisations and individuals use different types of systems fordifferent purposes. Here are some of the main types ofinformation systems and their uses.

Transaction processing system (TPS)A TPS collects and stores information about transactions, andcontrols some aspects of transactions. A transaction is an eventof interest to the organisation. e.g. a sale at a store.

A Tps is A Basic Business System. It

• Serves the most elementary day-to-day activities of anorganisation;

• Supports the operational level of the business;• Supplies data for higher-level management decisions.• Is often critical to survival of the organisation• Mostly for predefined, structured tasks• Can have strategic consequences (eg airline reservation system)• Usually has high volumes of input and output

4

• Provides data which is summarised into information by systemsused by higher levels of management

• Need to be fault-tolerant.On-line transaction processing: A transaction processing mode inwhich transactions entered on-line are immediately processed bythe CPU.Sub-species of TPS:

Manufacturing and production systemsSystems that supply data to operate, monitor and control theproduction process. e.g. purchasing, receiving, shipping, processcontrol, robotics, inventory systems, scheduling, engineering,operations, quality control, resource management etc.

E.G. A system in a factory that:

• Gets information from measuring samples of products• Does statistical analysis of samples• Shows when operators should take corrective actionSales and Marketing systems: Systems that support the sales andmarketing function by facilitating the movement of goods andservices from producers to customers.

Examples:• Sales support - keep customer records, follow-up• Telemarketing - use phone for selling• Order processing - process orders, produce invoices, supply

data for sales analysis and inventory control• Point-of-sale - capture sales data at cash register often by scanner• Customer credit authorisation - advise on credit to be allowed

to customer.• Example: A Store’s Sales System would:• Automatically record and total purchase transactions and prints

out a packing list• Improve customer service• Maintain customer dataFinance & Accounting Systems: Systems that maintain recordsconcerning the flow of funds in the firm and produce financialstatements, such as balance sheets and income statements.e.g. forBudgeting; General Ledger; Billing: Cost Accounting, AccountsReceivable / Payable; Funds Management Systems, Payroll. Theywere among the earliest systems to be computerised.Examples of financial systems: cash management, loanmanagement, check processing, securities trading, Example: Visa’sCredit Card payment system.Human Resources System: Systems that deal with recruitment,placement, performance evaluation, compensation, and careerdevelopment of the firm’s employees.Examples: personnel record keeping, applicant tracking.

Office automation system (OAS)OAS provides individuals effective ways to process personal andorganisational data, perform calculations, and create documents.e.g. word processing, spreadsheets, file managers, personalcalendars, presentation packages For are used for increasingpersonal productivity. They reduce “paper warfare”. OAS software

tools are often integrated (e.g. Word processor can import a graphfrom a spreadsheet) and designed for easy operation.

OAS SubspeciesCommunication systems: helps people work together by sharinginformation in many different formsTeleconferencing (includingaudioconferencing, computer conferencing, videoconferencing),electronic mail, voice mail, faxGroupware system: helps teams work together by providing accessto team data, structuring communication, and making it easier toschedule meetings. For sharing information, controlling workflows, communication/integration of work

Management information system (MIS)converts TPS data into information for monitoring performanceand managing an organisation. Transactions recorded in a TPS areanalyzed and reported by an MIS.They have large quantities of input data and they produce summaryreports as output. Used by middle managers. An example is anannual budgeting system.

Executive information system (EIS)Also known as an Executive Support System (ESS), it providesexecutives information in a readily accessible, interactive format.They are an MIS for executive use. An EIS/ESS usually allowssummary over the entire organisation and also allows drillingdown to specific levels of detail.Used by top level (strategic) management. They are designed tothe individual. They let the CEO of an organisation tie in to alllevels of the organisation. They are very expensive to run andrequire extensive staff support to operate.

Decision support system (DSS)helps strategic management staff (often senior managers) makedecisions by providing information, models, or analysis tools.For support of semistructured and unstructured decisions(structured decisions can be automated). Used for analytical work,rather than general office support.They are flexible, adaptable and quick. The user controls inputsand outputs. They support the decision process and often aresophisticated modelling tools so managers can make simulationsand predictions.Their inputs are aggregate data, and they produce projections. Anexample job for a DSS would be a 5 year operating plan.Knowledge Work Systems (Kws) are used by technical staff.KWS use modelling functions to convert design specificationsinto graphical designs. They may include computer-aided design/manufacture (CAD/CAM).

Summary

• A system is an orderly grouping of interdependent componentslinked together according to a plan to achieve a specific objective.

• Example business system has subsystems production, sales,personnel, and an information system which can also be asystem.

• CBIS can be broadly classified into three categories, namely,

5

Systems Analysis.Logical System Design.

Physical System Design.

System Analysis Definition

A systematic investigation of a real or planned system to determinethe functions of the system and how they relate to each other andto any other system.

Questions1. What do you mean by system?2. Give any two examples for system.3. What do you mean by computerized system?4. Do you know from where the term system is derived?5. Define system.6. Why we go for system analysis and what is system analysis.What is a System? What is System Analysis?

ReferencesHoffer, Jeffrey A.

Modern systems analysis and design2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.Systems analysis, data processing and quantitativetechniquesNew Delhi : Galgotia Publications, 1997

Hawryszkiewycz, IgorIntroduction to systems analysis & design4th ed. New Delhi : Prentice Hall of India, 2002

Awad, Elias M.Systems analysis and designNew Delhi : Galgotia Publications, 1997

Refer to Website address

http://www.sce.carleton.ca http://www.umsl.edu

Notes

6

LESSON 02:OBJECTIVE OF THE SYSTEM

Topics Covered• Objective of a System• Methodology of Systems Analysis Participants to system

development• Role of system analyst

Objectives

Upon completion of this Lesson, you should be able to

• Define the Objective of a system• Discuss the various participants in system development

Objective of a SystemThe study of systems concepts, has three basic implications:• A system must be designed to achieve a predetermined

objective.• Interrelationships and interdependence must exist among the

components or subsystem.• The objective of the organization as a whole has a higher priority

than the objectives of its subsystems.• For example, computerizing personnel applications must

conform to the organization’s policy on privacy, confidentiality,and security, as well as making selected data (e.g., payroll) availableto the accounting division on request.

Methodology of Systems Analysis

1. Identification of objectives• This is very important. If the correct objectives are not identified,

the correct problem will not be solved!• Consult others .• Use multi-disciplinary team

• May have multiple objectives• Determine your client - usually person paying the bill!• Establish the needs of the client - sometimes difficult to

establish• Identify the clients single most important objective• Choose a measure of effectiveness.• Discuss the project objective with the client

2.Development of a system model• Most often this is the responsibility of the systems analyst or

engineer• Keep in mind that the model is an abstraction of the system• A two stage process is sometimes used:• Model decoupling - simplifying step where system components

are modeled and analyzed as subsystems. This can be helpfulin better understanding the system.

• Model integration - entire system is modeled (e.g., the subsystemcomponents are integrated)

• Delicate balance exists between model detail and the ability toeffectively and efficiently analyze the mode. Modeling detailmay offer better reality at increased computational expense.Under certain circumstances, a simple model may prove morevaluable than a more complex model. The project objectivesshould dictate the level of detail required.

• Many types of models are available for use• The type of model chosen depends on system, the objectives,

perspective (time scale) of models• One should select the most “appropriate model” - by the end

of the semester you should have a better feel for this

3.Evaluation of alternatives• Goal is to find an optimum solution• Identify alternative solutions• Gather as much information about alternative solutions as

possible - may require searching the literature, obtaining technicaland cost data on equipment, operation, maintenance, and otherpertinent information

• Perform sensitivity analysis to determine response to change inmodel parameters

• Verification - computer code reproduces model chosen• Validation - model of system faithfully reproduces the actual

system

7

Participants to system developmentIn the role of a systems analyst, you will work on systemsdevelopment projects with a variety of other people. The cast ofcharacters will change from project to project, the personalities willdiffer dramatically, and the number of people that you interactwith will range from as few as one to as many as several dozen.However, the roles are fairly consistent, and you will see them overand over again.In a typical systems development project, there are the followingmajor categories of players:• ·User• Management• Auditors, quality assurance people, and ‘standards bearers”• Systems analysts• Systems designers• Programmers• Operations personnel

UsersThe user, the most important player in the systems game, is theperson (or group of people) for whom the system is being built.He or she is the person, whom will be interviewed, often in greatdetail, to learn what features the new system must have to besuccessful.The user is the “owner” in the sense that he or she receives, orinherits-and thus owns- the system when it is finally built. Andthe user is the “customer” in at least two important respects:1. As in so many other professions, “the customer is always

right”, regardless of how demanding, unpleasant, or irrationalhe or she may seem.

2. The customer is ultimately the person paying for the systemand usually has the right and/or the ability to refuse to pay ifhe or she is unhappy with the product received.

Who makes a formal request for a system?In most cases, it is fairly easy to identify the user: the user istypically the person who makes a formal request for a system.In a small organization, this is usually a very informal process.

In a large organization, the initiation of a systems developmentproject is usually much more formalized.Whenever possible, the systems analyst should try to establishdirect contact with the user. Even if other people are involved asintermediaries, it is important to have regular, face-to-face meetingwith the person who will ultimately inherit the system.If it is not possible to communicate directly with the user, thenthe documentation produced by the systems analyst becomes evenmore crucial.

The heterogeneity of UsersOne mistake often made by computer programmers, andsometimes by systems analysts is to assume that all users are thesame.“User” implies that the systems analyst will only have to interactwith one person, even when it is obvious that more than one useris involved, there is a tendency to think of them as a formless,shapeless, homogeneous group of humans.

Job category,or level ofSupervision.

Here are two ways of categorizing users:Level ofexperiencewithdataprocessing

Categorizing Users by Job categoryOn a typical systems analysis project, we can usually count oninteracting with three main job categories:

(a) Operational users:are the clerical, operational, and administrative people most likelyto have the most day-to-day contact with the new system. Thereare three things should be kept in mind when working withoperational-level users:• Operational users are very much concerned with the functions

that the system will perform, but they are likely to be evenmore concerned with the human interface issues.

• Operational users tend to have a “local” view of the system,they tend to be knowledgeable about the specific job that theydo and the people with whom they have immediate contact.But they often are unfamiliar with the “big picture”, that is,they may have trouble describing how their activity fits into theoverall organization or what the overall organization’s chartreally is.

• Operational users tend to think of systems in very physicalterms, that is, in terms of the implementation technologycurrently used to implement the system or in terms oftechnology that they imagine could be used.

(b) Supervisory users are employed in a supervisorycapacity:

They usually manage a group of operational users and areresponsible for their performance. The significant things toremember about supervisory users are these

8

• Many of them are former operational users who have beenpromoted to their current position.

• One reason that the supervisory user may be perceived as outof touch with the operational user is that he or she is oftenmeasured and motivated by performance against a budget.

• It is usually the supervisory user who thinks of a new systemas a way of reducing the number of operational users or avoidingfurther increases in their numbers as the volume of workincreases.

• The supervisory user will often act as a middleman betweenthe systems analyst and the operational user.

• The supervisory user often thinks in the same physical termsas the operational user, and this perspective is often just as localas that of the operational user.

• Finally, the supervisory user will be contacted day-to-day. He orshe is the one who will typically define the requirements anddetailed business policy that the system must implement. Heor she may be a passive member of the team, a full-time memberof the team, or even the project manager.

(c) Executive-level usersGenerally not directly involved in a systems development project,unless the project is so large and so important that it has a majorimpact on the organization.

Categorizing Users by Level of ExperienceDifferent users will have different levels of experience. Today, wecan distinguish between rank amateurs, cocky novices, and a small(but rapidly growing) number of true computer experts.• The amateur is the one who has never seen a computer and

who exclaims loudly and frequently that he or she doesn’tunderstand all this computer stuff. The real problem with theamateur user is somewhat more subtle: he or she may find itdifficult to understand the “language” that the systems analystuses to describe the features, functions and characteristics ofthe system to be built, even though that language avoidsobvious computer-related terminology.

• The second type of user is the “cocky novice”, the person whohas been involved in one or two systems development projects,or the user who has a personal computer and who has writtenone or two basic programs. This user often claims to knowexactly what he or she wants the system to do and is prone topoint out all the mistakes that the systems analyst made on thelast project.

• Of course, there are some users who really understand systemsanalysis, as well as the underlying technology of computers. Itis a pleasure working with these people. The only problemmay be that the user and the systems analyst derive so muchpleasure talking about the tools and techniques of systemsanalysis that they forget that their true objective is to build afunctioning system.

ManagementManagement is a rather loose term. The systems analyst is likely tocome into contact with several different kinds of managers:• User managers: managers in charge of several people in the

operational area where the new system will be used. These areusually middle-level managers who want systems that will

produce a variety of internal reports and short-term trendanalyses.

• Executive development project (EDP)/MIS managers: theperson in charge of the systems development project itself,and the higher-level managers who are concerned with theoverall management and allocation of resources of all thetechnical staff in the systems development organization.

• General management: top-level managers who are not directlyinvolved in the EDP organization or in the user organization.This might include the president and/ or chairman of theorganization.

The primary interaction between the systems analyst and all thesemanagers has to do with the resources that will be assigned to theproject. It is the systems analyst’s job to identify and documentthe user’s requirements and the constraints within which thesystem must be built.

AuditorsDepending on the size of the project and the nature of the

organization you work in, you may or may not have auditors.

Systems analystsThe system analyst is a key member of any systems developmentproject. In a boarder sense, the systems analyst plays several roles:• Archaeologist and scribe: As a systems analyst, one of the main

jobs is to uncover detail and to document business policy thatmay exist only as “tribal folklore”, passed down fromgeneration to generation of users.

• Innovator: The systems analyst must separate the symptomsof the user’s problem from the true causes. With his or herknowledge of computer technology, the analyst must help theuser explore useful, new applications of computers.

• Mediator: The systems analyst who often finds himself in themiddle of users, managers, programmers, auditors, andvarious other players, all of whom frequently disagree withone another.

• Project leader: Because the systems analyst is usually moreexperienced than the programmers on the project, and since heis assigned to the project before the programmers beginworking, there is a natural tendency to assign projectmanagement responsibilities to the analyst.

Systems designersThe systems designer is the person (or group of people) who willreceive the output of the systems analysis work. His or her job isto transform a technology-free statement of user requirementsinto a high-level architectural design that will provide the frameworkwithin which the programmer can work. In many case, the systemsanalyst and the systems designer are the same person, or memberof the same unified group of people. It is important for thesystems analyst and systems designer to stay in close touchthroughout the project.

ProgrammersParticularly on large systems development projects, the systemsdesigners are likely to be a “buffer” between the systems analystsand the programmers.

9

The systems analysts deliver their product to the system designers,and the system designers deliver their product to the programmer.There is another reason why the systems analyst and theprogrammer may have little or no contact with each other: work isoften performed in a strictly serial sequence in many systemsdevelopment projects.Thus, the work of systems analysis takes place first and iscompletely finished before the work of programming begins.

Operations personnelThe operations personnel who are responsible for the computercenter, telecommunications network, security of the computerhardware and data, as well as the actual running of computerprograms, mounting of disk packs, and handling of output fromcomputer printers.All this happens after a new system has not only been analyzedand designed, but has also been programmed and tested.

SummaryObjective of a System

Methodology of Systems Analysis

1. Identification of objectives2. Development of a system model3. Evaluation of alternatives

Participants in system development projectUser Management Auditors, quality assurance people, and‘standards bearers” Systems analysts Systems designersProgrammers Operations personnel

QuestionsWhat is the systems analyst’s role and responsibilities in themodern business?1234Why are organizations recruiting computer end-users to partnerwith the traditional systems analyst?12345On what basis we choose the model for a project?12345List down the career opportunities for systems analysts?123

45Who are the systems analyst’s customers and partners in systemsdevelopment.12345What business trends are influencing the careers of systemsanalysts?12345How can you prepare yourself for a career as a systems or businessanalyst?12345What does the future hold for systems analysts?12345List down the various participants in the system development12345On what basis you categorize the users. Give your explanationbelow.12345

10

ReferencesHeuring, Vincent P.

Computer systems design and architectureDelhi : Pearson Education Asia, 1997

Whitten, Jeffrey L.Systems analysis and design methods5th ed. New Delhi : Galgotia Publications, 2001

Shelly, Gary B.Systems analysis and design3rd ed. New Delhi : Galgotia Publications, 1999


Website address

http://www.sce.carleton.cahttp://www.umsl.edu

Notes

11

LESSON 03:ROLE OF SYSTEM ANALYST

Topics Covered• Role of system analyst• Modern Business trends

• Tips for preparing for a career as system analyst

ObjectivesUpon completion of this Lesson, you should be able to:• Explain the need of System analyst

• Discuss the various roles played by system analyst whiledeveloping a project.

Express the various tips for preparing as a career for system analyst

The Systems AnalystIn the last lesson we had a brief introduction about system analyst.Hope u know why we have system analyst in the systemdevelopment? If not, here in this lesson we shall go through indetail about the various roles played by the system analyst.• Many organizations consider information systems and

computer applications as essential to their ability to compete orgain competitive advantage.

• Information has become a management resource equal inimportance to property, facilities, employees, and capital.

• All workers need to participate in the development of thesesystems and applications – not just the computer andinformation specialists.

• But one specialist plays a special role in systems and applicationsdevelopment, the systems analyst.

• A systems analyst(s) facilitates the development of informationsystems and computer applications.

• The systems analyst performs systems analysis and design.• Systems analysis is the study of a business problem domain

for the purpose of recommending improvements andspecifying the business requirements for the solution.

• Systems design is the specification or construction of a technical,computer-based solution for the business requirementsidentified in a systems analysis. (Note: Increasingly, the designtakes the form of a working prototype.).

Why do businesses need Systems Analysts?

• The system analyst bridges the communications gap betweenthose who need the computer and those who understand thetechnology.

Who is a Systems Analyst?

• Systems analysts are people who understand both businessand computing.

• Systems analysts study business problems and opportunitiesand then transform business and information requirementsof the business into the computer-based information systems

and computer applications that are implemented by various

technical specialists including computer programmers.

A formal DefinitionA systems analyst facilitates the study of the problems and needsof a business to determine how the business system andinformation technology can best solve the problem and accomplishimprovements for the business. The product of this activity maybe improved business processes, improved information systems,or new or improved computer applications frequently all three.When information technology is used, the systems analyst isresponsible for:• The efficient capture of data from its business source• The flow of that data to the computer• The processing and storage of that data by the computer• The flow of useful and timely information back to the business

and its peopleInformation technology is a contemporary term that describes thecombination of computer technology (hardware and software)with telecommunications technology (data, image, and voicenetworks).A systems analyst is a business problem solver.A systems analyst helps the business by solving its problemsusing system concepts and information technology.A systems analyst sell business management and computer usersthe services of information technology.A systems analyst sells change.

The role of systems analyst is changing into twodistinct positions or roles, business analyst andapplication analyst.

• A business analyst is a systems analyst that specializes inbusiness problem analysis and technology-independentrequirements analysis.

• An application analyst is a systems analyst that specializes inapplication design and technology-dependent aspects ofdevelopment. A synonym is system or application architect.

What Does A System Analyst Do?

A system analyst is a system-oriented problemsolver.• System problem solving is the act of studying a problem

environment in order to implement corrective solutions thattake the form of new or improved systems.

Most systems analysts use some variation of a system problemsolving approach called a system development life cycle.• A systems development life cycle (SDLC) is a systematic and

orderly approach to solving system problems.

12

The SDLC usually incorporates the followinggeneral-purpose problem solving steps:

• Planning - identify the scope and boundary of the problem,and plan the development strategy and goals.

• Analysis - study and analyze the problems, causes, and effects.Then, identify and analyze the requirements that must befulfilled by any successful solution.

• Design - if necessary, design the solution not all solutionsrequire design.

• Implementation - implement the solution.• Support - analyze the implemented solution, refine the design,

and implement improvements to the solution. Differentsupport situations can thread back into the previous steps.

System analysts are responsible for other aspects ofa system including:

• People, including managers, users, and other developers – andincluding the organizational behaviors and politics that occurwhen people interact with one another.

• Data, including capture, validation, organization, storage, andusage.

• Processes, both automated and manual, that combines toprocess data and produce information.

• Interfaces, both to other systems and applications, as well tothe actual users (e.g., reports and display screens).

• Networks, which effectively distribute data, processes, andinformation to the people.

Systems analysts can be found in most businesses; however, theorganization of information services in many businesses is inturmoil as those businesses reorganize to improve service, quality,and value.

The Systems Analyst in the Traditional Business.

• Information services are centralized for the entire organizationor a specific line of business.

• Information Services reports directly to chief executive officer,

or the chief executive for a line of business.

Where Do System Analysts Work?

The Systems Analyst in the Traditional Business.Information Services is organized according to the followingfunctions or centers:· Systems and Applications Development.· Most systems analysts work here, along with most

programmers.· The systems analysts and programmers are organized into

permanent teams that support the information systems andapplications for specific business functions.

· The Systems and Applications Development unit may includea development center.

· A development center establishes and enforces the methods,tools, techniques, and quality of all development projects.

Data Administration

• This center manages the data and information resource in theorganization.

• Data Administration usually employs several systems analyst-like specialists called data analysts who analyze databaserequirements and design and construct the correspondingdatabases.

Telecommunications• This center designs, constructs, and manages the computer

networks that have become integral to most businesses.• Network analysts perform many of the same tasks as applied

to designing local and wide area networks that will ultimatelybe used by systems and applications.

End-User Computing• This center supports the growing base of personal computers

and local area networks in end user community.• They provide installation services, training, and help desk

services (call-in help for various PC related problems).• In mature businesses, they also provide standards and

consulting to end users who develop their own systems withPC power tools such as spreadsheets and PC databasemanagement systems.

In this latter role, they employ analyst-like end user computingWhere Do System Analysts Work?

The Systems Analyst in the Traditional Business.

• Information Services is organized according to the followingfunctions or centers

Computer Operations• This center runs all of the shared computers including

mainframes, minicomputers, and non-departmental servers.• This unit rarely employs systems analysts.• Consultants.

Modern Information Services in a Business

• Dramatic reorganization trend in medium-to-large informationservices units that are highly decentralized with a focus onempowerment and dynamic teams.

• Result is a federation of information systems centers that reportdirectly to their functional business units (or groups of businessunits).

• Each of these centers is empowered to set priorities and makedecisions on behalf of their constituent management and users.

• Decentralized information services can, however, lead toinformation anarchy and systems that do not interoperate tothe benefit of the business as a whole.

• There will always be systems and applications that supportmore than one business function perhaps the entire enterprise.

• There still exists a need for a central Information Services unit.• The central Information Services unit is responsible for:• Information Strategy Planning• The information strategy planning team establishes direction

and priorities for aligning information services for the entirebusiness with the corporate mission, vision, and goals.

13

• Experienced systems analysts often play key roles indevelopment.

• Information Technology Competency Centers• The centers provide a pool of technology specific specialists,

which are provided to both, centralized and decentralized unitsfor project work.

• Each expert contributes their expertise to any project to whichthey are assigned, for both centralized and decentralized projects

• Cross Functional Systems and Applications Development• This center develops and supports the shared information

systems and cross-functional applications for the business.• This center employs experienced systems analysts.• As projects are started and completed, both systems analysts

and technical specialists are assigned to and released from projectteams.

• Departmental Computing Coordination• This unit provides both consulting services and quality

management services to the decentralized information andcomputing centers.

• Experienced systems analysts may be employed here to helpestablish standards and guidelines, and to provide trainingand consultation to departmental projects.

Consulting

1. A variation on consulting firms is systems integration.• System integration involves helping organizations integrating

systems and applications that don’t work together properly, orthat run on very different technical platforms from differentcomputer manufacturers.

• Systems analysts that specialize in systems integration arefrequently called systems engineers or systems integrators.

Application Software Solution Providers• Application software solution providers are in the business of

building information systems and application software packagesfor resale to other businesses.

• Many businesses have a policy of not building any system theycan purchase.

• Software packages are typically written to the greatest commondenominator of their intended market – that is, they aredesigned to meet general requirements and offer limitedcustomizability.

• Software and solutions vendors usually hire two types ofsystems analyst.

• Software engineers, are responsible for designing (andprogramming) the package itself.

• Sales engineers, are responsible for helping customers thatpurchase the package to integrate it into their businessoperations.

Customers, Partners and Expectations• Customers – Users and Management

What is a user?

• A user is a person, or group of persons, for whom the systemsanalyst builds and maintains business information systemsand computer applications. A common system is client.

• There are at least two specific user/customer groups: systemusers and system owners.

• System users are those individuals who either have direct contactwith an information system or application or they useinformation generated by a system.

• System owners provide sponsorship of information systemsand computer applications. In other words, they pay to havethe systems and applications developed and maintained.

A manager can also be one of the end users of a system.

Two types of system users• Information technology managers and system analysts are

making a demonstrated attempt to get closer to their customersby forming a partnership.A manager can also be one of the endusers of a system.

• Two types of system users:• Traditionally, most system users were internal users, that is

employees of the business for which a system or application isdesigned.

• Today’s user community includes external users as businessesseek to make their information systems and applicationsinteroperate with other businesses and the consumer.

• Information technology managers and system analysts aremaking a demonstrated attempt to get closer to their customersby forming a partnership.

The Roles of Management and Users in Systems Problem Solving

The roles of management and users in• Implementation• Users participate in system construction and testing. They are

the recipients of training necessary to enable the full usercommunity to work with the solution.

• Support• Users and management should routinely evaluate the working

solution and suggest improvements.Modern Business Trends and Implications for the System AnalystSystems analysts must keep up with rapidly changing technologies,but today’s priorities are rapidly shifting from technology-drivensolutions to business-driven solutions.Total Quality Management (TQM)• One of the major business trends of the 1990s is Total Quality

Management.• Total Quality Management or TQM is a comprehensive

approach to facilitating quality improvements and managementwithin a business.

• TQM commitments require every business function, includinginformation services, identify quality indicators, measure quality,and make appropriate changes to improve quality.

• TQM impacts systems analysts on at least two fronts.

14

• First, the very nature of systems analysis encourages analysts tolook for business quality problems.

• The two most important questions in the analyst’s repertoireare ‘why’ and ‘why not.’

• Second, systems analysis and design provides the specificationsfor the #1 quality problem in modern information systemsbuggy software.

• Incomplete and inconsistent specifications from analysts are asignificant contributor to poor software quality.

Business Process Redesign (BPR)• Total quality management has forced many businesses to

radically rethink and redesign their fundamental businessprocesses.

• Business process redesign is the study, analysis, and redesignof fundamental business processes to reduce costs andimprove value added to the business.

• A BPR project begins with identification of a value chain, acombination of processes that should result in some value tothe business.

• The business processes are documented and analyzed inexcruciating detail.

• The business processes are subsequently streamlined formaximum efficiency.

• The new business processes are analyzed for opportunities forfurther improvement through information technology.

• Systems analysts figure prominently in BPR because:• Systems analysts are often included in BPR projects because

their ‘system’ perspective is valued.• The skill competencies for BPR and systems analysis and design

are somewhat similar.• A typical BPR project identifies several opportunities for new

and revised computer applications (which systems analystsfacilitate).

Continuous Process Improvement (CPI)• Another TQM related trend is continuous process

improvement.• Continuous process improvement is the continuous

monitoring of business processes to affect small but measurableimprovements to cost reduction and value added.

• In a sense, CPI is the opposite of BPR.• BPR is intended to implement dramatic change.• CPI implements a continuous series of smaller changes.• Another TQM related trend is continuous process

improvement.• Continuous process improvement is the continuous

monitoring of business processes to affect small but measurableimprovements to cost reduction and value added.

• In a sense, CPI is the opposite of BPR.• BPR is intended to implement dramatic change.• CPI implements a continuous series of smaller changes.

Globalization of the Economy

• Competition became global with emerging industrial nationsoffer lower cost or higher quality alternatives to many products.

• Most businesses have been forced to reorganize to competeglobally

• Systems analysts are affected by the following:• Information systems and computer applications must be

internationalized.• They must support multiple languages, currency exchange rates,

international trade regulations, accepted business practices(which differ in different countries), and so forth.

• Most information systems ultimately require informationconsolidation for the purpose of performance analysis anddecision-making.

Working Knowledge of InformationTechnology• The systems analyst is an agent of change.• The systems analyst is responsible for showing end-users and

management how new technologies can benefit their businessand its operations.

• The systems analyst must be aware of both existing andemerging information technologies and techniques.

Computer Programming Experience andExpertise• A systems analyst must know how to program because they

are the principle link between business users and computerprogrammers.

• It is wrong to assume that a good programmer will become agood analyst or that a bad programmer could not become agood analyst.

• Most systems analysts need to be proficient in one or morehigh-level programming languages.

• Historically, the language of choice has been COBOL forbusiness applications, but many organizations are shifting tovisual programming languages or to object-orientedprogramming languages .

• The reasons for the shift are as follows:• The transition to graphical user interfaces.• The desire to downsize applications from the mainframe to

networks of PCs.• The pressures to improve productivity in applications

development through rapid, iterative prototyping and the reuseof programming modules called objects and components.

• Visual and object-oriented programming requires a completelydifferent style of program design, construction, and testing.

General Business Knowledge• The systems analysts are expected to immerse themselves in

the business and be able to specify and defend technicalsolutions that address the bottom-line value returned to thebusiness.

• Systems analysts should be able to communicate with businessexperts to gain knowledge of problems and needs.

15

• It is not uncommon for systems analysts to develop so muchexpertise over time they move out of information systemsand into the user community.

Problem-Solving Skills• The systems analyst must have the ability to take a large business

problem, break that problem down into its component parts,analyze the various aspects of the problem, and then assemblean improved system to solve the problem.

• The systems analyst must learn to analyze problems in termsof causes and effects rather than in terms of simple remedies.

• The systems analyst must be well organized.• System analysts must be able to creatively define alternative

solutions to problems and needs.

Preparing For a Career as a SystemsAnalystInterpersonal Communications Skills

• The systems analyst must be able to communicate effectively,both orally and in writing.

• The systems analyst should have a good command of theEnglish language.

• Almost without exception, communications skills, not technicalskills, prove to be the single biggest factor in career success orfailure.

• Systems analysts work in teams composed of IS professionals,end-users, and management.

• Being able to cooperate, to comprise, and to function as partof a team, is critical for success in most projects.

• Because development teams include people with dramaticallydifferent levels of education and experience, group dynamics isan important skill to develop.

Flexibility and Adaptability• No two systems development projects encountered by a systems

analyst are identical.• There is no single, magical approach or solution applicable to

systems development.• Successful systems analysts learn to be flexible and adapt to

special challenges or situations presented by specific systemsdevelopment projects.

• The systems analyst must be able to recognize when variationsupon (or single-instance exceptions to) development standardsare necessary and beneficial to a particular project.

• The systems analyst must be aware of the implications of notfollowing the standards.

Character and Ethics• The nature of the systems analyst’s job requires a strong character

and sense of ethics.• Ethics is a personal character trait in which an individual(s)

understands the difference between ‘right’ and ‘wrong’ andacts accordingly.

• Systems analysts must be very careful not to share theirorganization’s sensitive and secret information with others,either within or outside the organization.

• Systems analysts must be very careful not to tell sensitive andprivate data and information about customers, suppliers,employees with the wrong people.

• Systems analysts must not take (or sell) designs and programsthey developed to another company.

• Systems analysts have a moral obligation to set a good examplefor end-users and management, especially in the area of softwarecopyrights.

Systems Analysis and Design Skills• All systems analysts need thorough and ongoing training in

systems analysis and design.• Systems analysis and design skills can be conveniently factored

into three subsets:• Concepts and principles• Tools• Techniques

Summary

System AnalystsSystems analysts are people who understand both business andcomputing. Systems analysts study business problems andopportunities and then transform business and informationrequirements of the business into the computer-based informationsystems and computer applications that are implemented byvarious technical specialists including computer programmers.

Business needs for System AnalystThe system analyst bridges the communications gap between thosewho need the computer and those who understand the technology.

Tips for a career as system analystGood Communication skills, Flexibility and adaptability, systemanalysis and design skills

QuestionsWhy we need a system analyst?12345What are the major roles of system analyst?12345Why do business need system analyst?12345

16

Explain about modern business trends and implications forsystem analyst.12345Give some tips to become a system analyst(career).1234

5What qualities you look for in a good Systems Analyst.

ReferencesAwad, Elias M.Systems analysis and designNew Delhi : Galgotia Publications, 1997Hoffer, Jeffrey A.Modern systems analysis and design2nd ed. Delhi : Pearson Education Asia, 2000Hawryszkiewycz, IgorIntroduction to systems analysis & design4th ed. New Delhi : Prentice Hall of India, 2002


http://www.sce.carleton.ca http://www.wiwd.uscourts.govhttp://www.masi.com

Notes

17

LESSON 04:ELEMENTS OF SYSTEMS

Topics CoveredElements of systems

ObjectivesUpon completion of this Lesson, you should be able to:• Explain about the various elements of a system• Discuss the attributes with the elements.

Elements of a system:Recall about the role of system analyst…..System analysts operatein a dynamic environment where changes are a way of life. Theenvironment may be a business firm, a business application, or acomputer system.To reconstruct a system the following key elements must beconsidered:• Outputs• Inputs.• Processor(s).• Control.• Feedback.• Environment.• Boundaries and interface.

Outputs• A major objective of a system is to produce an output• The output may be goods, services or information it should

satisfy the expectations of the user.• Outputs are the outcome of processing.

Inputs

• Inputs may be material, human resources, information thatenters the system for processing.

Processor (s)

• The processor is the element of a system that involves theactual transformation of input into output.

• Processors may modify the input totally or partially dependingon the specifications of the output.

• This means that as the output specifications change, so doesthe processing.

Control

• The control element guides the system.• Management as a decision-making body controls the inflow,

handling, and outflow of activities that affect the business.

Feedback

• Control in a dynamic system is achieved by feedback.• Feedback may be positive or negative, routine or informational.• Positive feedback reinforces the performance of the system. It

is routine in nature.• Negative feedback generally provides the controller with

information for action.

Environment

• The environment is the supra system within which anorganization operates.

• The organization environment consists of vendors,competitors, and others, which provides constraints andinfluences the actual performance of the business.

Boundaries and InterfacesA system should be defined by its boundaries-the limits thatidentify its components, processes, and interrelationships when itinterfaces with another system.

Elements of a System and TheirAttributes

How to Use This Checklist

• What follows is essentially a checklist of elements of systemsand the attributes that these elements may have.

• Most systems have all of the seven major elements, but not allthe attributes are necessarily relevant to every system.

• This checklist has been prepared for the use of people engagedin the kind of careful analysis of systems, existing or planned,that is implied by the label “systems analysis.”

• As a systems analyst works his or her way through the manyaspects of a typical system that is being studied (i.e., analyzedand/or designed), the analyst can use the attributes in thechecklist as reminders of questions that need to be asked aboutthe aspects under study.

Types of Elements• Data.

18

• Equipment.• Personnel.• Data Vehicles.• Information Stores.• Procedures and Programming.• Training.

Data: The Ingredients Of The informationthat the system uses, processes, and/orproduces

Attributes to be Considered:

• Unambiguous name: Does each type of data have anunambiguous name within the system?

• Relevance to system tasks: To which task(s) is each type of datarelevant? is the type of data under consideration relevant toonly one task or to two or tasks?

• Source: What is the source of this type of data? what is thereliability of the source? what is the authenticity of the source?

• Processing needed• Destination• Logical relationships, if any: E.g., have both the invoice for the

book and the physical book arrived?

Personnel: Users And OperatorsAttributes to be considered:

• Functions performed by humans: What functions areperformed by humans? should be performed by humans?

• Human-decision points: stated vs. actual• Nature of human decisions: Could some of the decisions be

made programmatically? Could some of the decisions be madeby lower-level staff members?

• Authority and information links with other personnel, bothformal and informal

• Extra-system responsibilities of staff members: committeesassigned to? community involvement?

• Attitudes toward system and fellow workers, especially towardfellow workers as grouped by departments or otheradministrative units

• Reliability• Turnover

Equipment: Machinery And OtherPhysical EquipmentAttributes to be Considered:

• Functions performed by machines: What functions areperformed by machines? should be performed by machines?

• Machine-decision points• Data-storage size• Data input and output rates• Format requirements• Compatibility

• Reliability: includes preventive maintenance, backup alternatives,recovery from breakdown)

• ModifiabilityPhysical requirements: light, power supply, weight, size, noise, air-conditioning (temperature and humidity) needs• Location, and provision for possible need to move equipment

in futureFuture availability of this type of equipment? of equipmentperforming the same function(s)?• Interface with users and/or operators• Cost: lease, purchase, maintenance (including comparison of

the costs of maintenance on purchased equipment vs. the costsof leasing)

• Warranties and maintenance arrangements• Security (against accidental and/or willful damage)

Data Vehicles: Databases, Files, etc.

Attributes to be ConsideredNote: Attributes in this category need to be checked against thoseof personnel and equipment, since data vehicles share manyattributes with those categories.• Degree of aggregation: how many items are handled together?• Format (for both human and machine use): machine coding;

human coding (e.g., maps, charts, tables, prose)• Timeliness: how up-to-date must the data be? are only current

data desired? or current data plus historical data (e.g., to showtrends)?

• Selection criteria: all data? summary data? exceptions only? howfiltered?

• Initiation or access: routine? when and as scheduled? asaccumulated? on demand only? who initiates access?

• Transudation: mechanism(s) involved in changing the formof data (microcomputer, computer printer, typewriter, terminal,copier, camera, etc.)

• Correctness: what are the chances for error? how can errors bedetected and corrected? how much error is tolerable?

• Cost: physical costs of vehicle? costs of preparing data invehicle?

• Appropriateness of data vehicle to data items?• Retention and security• Source, handler(s), and destination• Relation to other data vehicles

Information Stores: Disk Drives, BookCollections, World-wide Web Sites, TapeCartridges, Etc.Attributes to be Considered

• Size, measured in various ways• Input and output rates desired and/or expected• Growth rate expected• Logical format(s) used• Physical format(s) used• Equipment needed for storage

19

• Equipment needed for input and output• Location• Permanence: what happens if lost? Security measures?• Accessibility and privacy considerations• Importance or value (cost)• Replacement and/or backup

Procedures And Programming

Attributes to be ConsideredInterpret functions in terms of specific sequences of tasks to beperformed by• Organizational units, existing or proposed• Persons• Equipment• Detail procedures for personnel in terms of• Steps in processing• Decision points• Organizational responsibilities• Individual responsibilities .Detailed procedures for use of equipment (e.g., specifications forcomputer programs) in terms of• Steps in processing• Decision points• Organizational responsibilities• Individual responsibilities .

Training: System staff and system usersAttributes to be Considered

• Skills needed: internally acquired? Externally acquired?• Knowledge needed: internally acquired? Externally acquired?• Information handled in performing the task• Definition of externally acquired skills and knowledge (e.g.,

qualifications for being hired for the task)• Definition of skills and knowledge to be provided though

internal training• Quantities of training needed, as an effect of turnover and of

system rate of change• Possibilities of cross training or re-training of present skills• Procedures for providing training, including staff needed and

equipment needed• Training to be provided by manufacturers of equipment or

vendors of software systems.

Review Check List

Elements of a system

• Outputs• Inputs.• Processor(s).• Control.• Feedback.• Environment.• Boundaries and interface.

Elements of a system & the attributesv• Data.• Equipment.• Personnel.• Data Vehicles.• Information Stores.• Procedures and Programming.• Training.

QuestionsWith the help of a system (any real example) explain the keyelements of that system.• Outputs• Inputs.• Processor(s).• Control.• Feedback.• Environment, Boundaries & InterfacesExplain about the elements of a system and the attributes of thesystem with a real example.12345Can you have a viable system without feedback? Explain.12345

References:

20

Heuring, Vincent P.Computer systems design and architecture Delhi : Pearson Education Asia, 1997



Awad, Elias M.Systems analysis and design New Delhi : Galgotia Publications, 1997

Hoffer, Jeffrey A.Modern systems analysis and design2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.Systems analysis, data processing andquantitative techniques New Delhi : Galgotia Publications, 1997



http://www.sce.carleton.cahttp://www.wiwd.uscourts.govhttp://www.umsl.edu

Notes

21

LESSON 05:CHARACTERISTICS OF A SYSTEM

Topics Covered• ·Characteristics of a system• Example of an organization• Integrated information system

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss with the real example about the characteristics of a

system.• Explain about information system.

Characteristics of a systemThe system definition suggests some characteristics that are presentin all systems:• Organization• Interaction• Interdependence• Integration• Central objective

OrganizationWhat is an organization?

• “Organizations tell about structure and order”• Organization is the arrangement of components, which helps

to achieve objectives.• For example in the design of business system the hierarchical

relationships shown below in the figure (Organization structureAn Example) starting with the president on top and downwardblue collar workers represents the organization structure.

Organization Structure an Example

President

Vice PresidentSales

Vice President Production

Vice PresidentAccounting

FormalOrganizationalPositions

Department Head Assembly

Department HeadPainting

Lines of Authority

Workers Workers

Interaction

What is interaction?

• Interaction refers how each component functions with othercomponents of the system.

• For example in an organization purchasing must interact withproduction, advertising with sales, and payroll with personnel.

• In a computer system, the central processing unit (CPU) mustinteract with the input device to solve a problem. The mainmemory holds programs and data that the arithmetic unit usesfor computation. The interrelationship between thesecomponents enables the computer to perform.

Interdependence• Interdependence means that parts of the organization or

computer system depend on one another .One subsystemdepends on the input of another subsystem

• Each of the top inner circles represents major subsystems of aproduction firm.

• The personnel subsystem consists of subsystems such asbenefits, health and safety and employment.

Major Subsystem of a production firm (Higher-Level Subsystem)

• No subsystem can function in isolation because it is dependenton the data (inputs) it receives from other subsystem to performits required tasks.

22

• Interdependence is illustrated by the activities and support ofsystem analyst, programmers, and the operations staff in acomputer center.

• A decision to computerize an application is initiated by theuser, analyzed and designed by the analyst, programmed andtested by the programmer, and run by the computer operator.

Task interdependence in a computer basedsubsystem

UserArea System Analysis Programming Operations

IntegrationØ Integration refers to the holism of systems.Ø Integration is concerned with how a system is tied together.Ø It means that parts of the system work together within the

system even though each part performs a unique function.

Central objectiveThe last characteristics of a system are its central objective. Objectivemay be real or stated. The stated objective may be a real objective.

ExampleTo illustrate these system characteristics, Figure above named MajorSubsystem of a production firm( Higher-Level Subsystem)• Shows three levels of subsystems. Each of the top inner circles

represents a major subsystem of a production firm.• The personnel subsystem, in turn, may be viewed as a system

that consists of subsystems such as benefits, health and safety,and employment. Health and safety as a key personnelsubsystem consists of lower-level elements that are consideredvital in personnel operation.

• Each element may he represented by a computer-based packageor is part of a human resource database that providesinformation on unemployment, insurance benefits, and thelike.

Integrated Information system

• The above figure is an integrated information system designedto serve the needs of authorized users (department heads,managers, etc.) for quick access and retrieval via remote terminals.The interdependence between the personnel subsystem andthe organization’s users is obvious.

• In summary, no subsystem can function in isolation because itis dependent on the data (inputs) it receives from othersubsystems to perform its required tasks. Interdependence isfurther illustrated by the activities and support of systemsanalysts, programmers, and the operations staff in a computercenter.

• A decision to computerize an application is initiated by theuser, analyzed and designed by the analyst, programmed andtested by the programmer, and run by the computer operator.

As shown in Figure below, none of these persons can performproperly without the required input from others in the computercenter subsystem.

23

Review Questions1. From your understanding of this lesson, do you need a

computer to do systems analysis? Discuss.123452. Take an organization with which you are familiar and examine

the following:a. Primary subsystems.b. Characteristics.c. Elements.d. Purpose.123451. List the parts and functions of the following systems:a. Microcomputer.b. Stapler.c. Your business school or department.123454. Consider an automobile and a hospital as two systems. Identify

the following as an input and/or output for each system:a. Batteries.b. Cured patients.c. Doctors.d. Driver’s performance.e. Drugs.f. Gasoline.g. Information.h. Motion.i. A patient who died.j. Tires.k. X-ray machine

Questions1. What is system, give some definitions of system?2. How do you distinguish natural systems and man-made

systems?3. Please list some automated systems and the rules to build

them up.

4. Who participate in system development? Please tell the role ofeach of them.

5. What is system development life cycle? What are itscomponents? Which part in the life cycle does each of theparticipating system developers handles?

6. From what perspectives are the system requirements viewed?7. What are the purposes of system survey? Please tell several

popular system survey methods.8. Why is survey report necessary? What is an adequate and detail

survey report like?


Computer systems design and architecture Delhi : Pearson Education Asia, 1997





Sarkar, A.K.Systems analysis, data processing andquantitative techniques New Delhi : Galgotia Publications, 1997


Refer to Website addreshttp://www.sce.carleton.cahttp://www.wiwd.uscourts.govhttp://www.umsl.edu

24

LESSON 06:INTRODUCTION TYPES OF SYSTEM

Topics Covered• Types of System• Introduction,• Automated system• General principles of a system• Physical or Abstract system

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the various types of system• Differentiate between nature system and man made system• Explain about automated system• Explain about physical system and abstract system.

Types of SystemBefore reading this lesson Recollect what is a system? And who isa system analyst?Now let us see about the types of system• There are many different types of systems, but indeed, virtually

everything that we come into contact with during our day-to-day life is either a system or a component of a system (both).

It is useful to organize different kinds of systems into usefulcategories.• Because our ultimate focus is on computer systems, we will

divide all systems into two categories: natural systems andman-made systems.

Natural systems

• There are a lot of systems that are not made by people: theyexist in nature and, by and large, serve their own purpose.

• It is convenient to divide natural systems into two basicsubcategories:

• Physical systems• Living systems.

Physical systems include such diverse example as:Stellar systems: galaxies, solar systems, and so on.Geological systems: rivers, mountain ranges, and so on.Molecular systems: complex organizations of atoms.• Physical systems are interesting to study because we sometimes

want to modify them. We also develop a variety of man-madesystems, including computer systems, which must interactharmoniously with physical systems; so it is often importantto be able to model those systems to ensure that we understandthem as fully as possible.

• Living systems encompass all of the myriad animals and plantsaround us, as well as our own human race. The properties and

characteristics of familiar living systems can be used to helpillustrate and better understand man-made systems.The living systems, whether at the level of the cell, the organ,the organism, the group, the organization, the society, or thesupranational system, all contain the 19 subsystems:

1. The reproducer, which is capable of giving rise to other systemssimilar to the one, it is in.

2. The boundary, which holds together the components thatmake up the system, protects them from environmentalstresses, and excludes or permits entry to various sorts ofmatter-energy and information.

3. The ingestor, which brings matter-energy across the systemboundary from its environment.

4. The distributor, which carries inputs from outside the systemor outputs from its subsystems around the system to eachcomponent.

5. The converter, which changes certain inputs to the system intoforms more useful for the special processes of that particularsystem.

6. The producer, which forms stable associations that endure forsignificant periods among matter-energy inputs to the systemor outputs from its converter, the materials synthesized beingor growth, damage repair, or replacement of components ofthe system, or for providing energy for moving or constitutingthe system’s outputs of products or information markets toits suprasystem.

7. The matter-energy storage subsystem, which retains in thesystem, for different periods of time, deposits of various sortsof matter-energy.

8. The extruder, which transmits matter-energy out of the systemin the form of products or wastes.

9. The motor, which moves the system or parts of it in relationto part or all of its environment or moves components of itsenvironment in relation to each other.

10. The supporter, which maintains the proper spatial relationshipsamong components of the systems, so that they can interactwithout weighing each other down or crowding each other.

11.The input transducer, which brings markers bearinginformation into system, changing them to other matter-energyforms suitable for transmission within it.

12. The internal transducer, which receives, from other subsystemsor components within the system,.

13. The channel and net, which are composed of a single route inphysical space, or multiple interconnected routes, by whichmarkers bearing information are transmitted to all parts of thesystem.

25

14. The decoder, who alters the code of information input to itthrough the input transducer or internal transducer into a privatecode that can be used internally by the system.

15. The associator, which carries out the first stage of the learningprocess, forming enduring associations among items ofinformation in the system.

16. The memory, which carries out the second stage of the learningprocess, storing various sorts of information in the system fordifferent periods of time.

17. The decider, which receives information inputs from all othersubsystems and transmits to them information outputs thatcontrol the entire system.

18. The encoder, who alters the code of information input to itfrom other information processing subsystems, from a privatecode used internally by the system into a public code that can beinterpreted by other systems in its environment.

19. The output transducer, which puts out markers bearinginformation from the system, changing markers within thesystem into other matter-energy forms that can be transmittedover channels in the system’s environment.

Keep in mind that many man-made systems (and automatedsystems) interact with living systems. In some cases, automatedsystems are being designed to replace living systems. And in othercases, researchers are considering living systems as components ofautomated systems.

Man-made systemsMan-made systems include such things as:1. Social systems: organizations of laws, doctrines, customs, and

so on.2. An organized, disciplined collection of ideas.3. Transportation systems: networks of highways, canals, airlines

and so on.4 Communication systems: telephone, telex, and so on.5. Manufacturing systems: factories, assembly lines, and so on.6. Financial systems: accounting, inventory, general ledger and so

on.• Most of these systems include computers today.• As a systems analyst, you will naturally assume that every system

that you come in contact with should be computerized. Andthe customer or user, with whom you interact will generallyassume that you have such a bias.

• A systems analyst will analyze, or study, the system to determineits essence: and understand the system’s required behavior,independent of the technology used to implement the system.

• In most case, we will be in a position to determine whether itmakes sense to use a computer to carry out the functions ofthe system only after modeling its essential behavior.

• Some information processing systems may not be automatedbecause of these common reasons: Cost; Convenience; Security;Maintainability; Politics.

Automated systemsAutomated systems are the man-made systems that interact with

or are controlled by one or more computers.

We can distinguish many different kinds of automated systems,but they all tend to have common components:

1. Computer hardware (CPUs, disks, terminals, and so on).2. Computer software: system programs such as operating systems,

database systems, and so on.3. People: those who operate the system, those who provide its

inputs and consume its outputs, and those who providemanual processing activities in a system.

4. Data: the information that the system remembers over a periodof time.

5. Procedures: formal policies and instructions for operating thesystem.

One way of categorizing automated systems is by application.However, this turn out not to be terribly useful, for the techniquesthat we will discuss for analyzing, modeling, designing, andimplementing automated systems are generally the same regardlessof the application.A more useful categorization of automated systems is as follows:1. Batch system: A batch system is one which in it, the information

is usually retrieved on a sequential basis, which means that thecomputer system read through all the records in its database,processing and updating those records for which there is someactivity.

2. On-line systems: An on-line system is one, which acceptsinput directly from the area where it is created. It is also asystem in which the outputs, or results of computation, arereturned directly to where they are required.

3. Real-time systems: A real-time system may be defined as onewhich controls an environment by receiving data, processingthem, and returning the results sufficiently quickly to affect theenvironment at that time.

4. Decision-support systems: These computer systems do notmake decisions on their own, but instead help managers andother professional “knowledge workers” in an organizationmake intelligent, informed decisions about various aspects ofthe operation. Typically, the decision-support systems arepassive in the sense that they do not operate on a regular basis:instead, they are used on an ad hoc basis, whenever needed.

5. Knowledge-based systems: The goal of computer scientistsworking in the field of artificial intelligence is to produceprograms that imitate human performance in a wide variety of“intelligent” tasks. For some expert systems, that goal is closeto being attained. For others, although we do not yet knowhow to construct programs that perform well on their own, wecan begin to build programs that significantly assist people intheir performance of a task.

General systems principlesThere are a few general principles that are of particular interest topeople building automated information systems. They includethe following:1. The more specialized a system is, the less able it is to adapt to

different circumstances.2. The more general-purpose a system is, the less optimized it is

for any particular situation. But the more the system is

26

optimized for a particular situation, the less adaptable it will beto new circumstances.

3. The larger a system is, the more of its resources that mustbe devoted to its everyday maintenance.

4. Systems are always part of larger systems, and they canalways be partitioned into smaller systems.

5. Systems grow. This principle could not be true for all systems,but many of the systems with which we are familiar do grow,because we often fail to take it into account when we begindeveloping the system.

Physical or Abstract system

Types of system

Systems have been classified in different ways. Commonclassifications are

• Physical or Abstract System• Open or closed system• Man made system

Physical System

• Physical systems are tangible entities that may be static ordynamic in operation.

• For example, the physical parts of the computer center are theoffices, desks, and chairs that facilitate operation of thecomputer.

• They can be seen and counted; they are static.• But a programmed computer is a dynamic system.• Data, programs, output, and applications change as the user’s

demands or the priority of the information requested changes.

Abstract System

• Abstract systems are conceptual or nonphysical entities.• They may be as formulas of relationships among sets of

variables or models.• A model is a representation of a real or a planned system.• The use of models makes it easier for the analyst to visualize

relationships in the system.

Review

Various types of systems

Natural System§ There are a lot of systems that are not made by people: they

exist in nature and, by and large, serve their own purpose.§ Physical systems§ Living systems.Man-made SystemMan-made systems include such things as:1. Social systems2. An organized, disciplined collection of ideas. 3. Transportation systems.4 Communication systems5 Manufacturing systems6. Financial systems

Automated system General principles of a system Physical system Abstract System

QuestionsDifferentiate between the natural system and man made system.12345Discuss about the automated system. State whether it is a naturalsystem or man made system.12345Give some real world examples for physical or abstract system.12345







Sarkar, A.K.Systems analysis, data processing and quantitativetechniques New Delhi : Galgotia Publications, 1997


Refer to Website addresshttp://www.sce.carleton.cahttp://www.wiwd.uscourts.govhttp://www.umsl.edu

27

LESSON 07:TYPES OF MODELS

Topics Covered

System Models

• Schematic model• Flow system models• Dynamic system models• Static system models

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss about the Schematic model• Discuss the various categories of System model.

Types of models

What do you mean by a model?

• Iconic - physical models that are images of the real world;dimensions are usually scaled up or down; for example, modelsof cars might be constructed and tested in a wind tunnel

• Analog - model that substitutes one set of properties foranother; may be iconic or mathematical; electric resistance oftenused as an analog of the friction of a fluid flowing in a pipe;this approach is not as widely used as at one time - digitalcomputers have allowed the development of other modelingtechniques that have replaced analog models

• Stochastic - probabilistic model that uses randomness toaccount for immeasurable factors (e.g., weather)

• Deterministic - model that does not use randomness butuses explicit expressions for relationships that may or may notinvolve time rates of change

• Discrete - model where state variables change in steps asopposed to continuously with time (e.g., number of cattle ina barn); may be deterministic or stochastic

• Continuous - model whose state variables change continuouslywith time (e.g., biomass in a field); usually sets of differentialequations used; initial conditions required (can be difficult toobtain for some systems!)

• Combined - model where some state variables changecontinuously and others change in steps at event times; forexample, a field of hay might be modeled using a combinedapproach with the biomass modeled continuously duringgrowth and then as a discrete event when harvested

• Mathematical - abstract model usually written in equationform

• Object-oriented - use objects that are abstractions of real worldobjects and develop relationships and actions between objects;comes from field of artificial intelligence

• Heuristic - heuristics (rules) are used to model the system;comes from field of artificial intelligence.

Reasons for Modeling• Highlight problems of interest.• Economical experimentation.• Precision of thought.• Solving operational problems.• Impossible to analyze some systems mentally since some

systems are counterintuitive; mental models are usually inexact.• Quantifies relationships and identifies gaps in our knowledge

(can be used to guide research)• Range of variables that can be examined in actual system is

often quite small in time and space scale• Dynamics of actual system may preclude data collection and

observation.

Systems Models• The analyst begins by creating a model of the reality (facts,

relationships, procedures, etc.) with which the system isconcerned.

• Every computer system deals with the real world, a problemarea, or a reality outside itself. For example, a telephone switchingsystem is made up of subscribers, telephone handsets, dialing,conference calls, and the like.

• The analyst begins by modeling this reality before consideringthe functions that the system is to perform.

• Various business system models are used to show the benefitsof abstracting complex systems to model form.

The major models discussed here are schematic, flow, static, anddynamic system models.

Schematic ModelsA schematic model is a two-dimensional chart depicting system

elements and their linkages. Figure in the next page shows themajor elements of a personnel information system togetherwith material and formation flow.

• One of the initial steps in a modeling exercise is to organize theelements of the system being studied in some fashion.

• Schematic models provide a means of visualizing systemstructure and operation without immediately trying tomathematically represent the system. Such schematic modelscan reveal redundancies and system weaknesses that can becorrected without extensive formal analysis.

• Understanding a system well enough to construct a schematicmodel of its operation may be the most important benefit ofan operations engineering study. There are many types ofschematic models that might be used by operations engineer.

28

• The schematic models attempt to organize knowledge in alogical fashion such that time, space and structural relationshipscan be easily understood

Flow System Models.• A flow system model shows the flow of the material, energy,

and information that hold the system together. There is anorderly flow of logic in such models.

• A widely known example is PERT (Program Evaluation andReview Technique). It is used to abstract a real-world system inmodel form, manipulate specific values to determine the criticalpath, interpret the relationships, and relay them back as a control.

The probability of completion within a time period is consideredin connection with time, resources, and performance specifications

Performance ModelsA performance model describes the program’s resource usage

during computing.• Total performance• A function from input to measures• Typically structured• Contributing factors

Several kinds of performance models• Execution structure• Typically control flow• Resource usage• Typically time

Flow Graph

A simple model of performance; a timed flow graph

29

Problems

• Choices, repetitions• Parallelism• Locks

Petri Nets

A Petri net consists of• Nodes• Places P• Transitions T• Directed edges P-T or T-P

System state

• Depicted with tokens• Changed by a firing event• Triggering an event

Usage• Describing parallelism• Describing locking

Example

Several kinds of Petri nets• Amount of edges• Amount of tokens

Usage of a critical resource

Describing performance via Petri nets• Timed events• Stochastic events• Static valuesQueuing networksQueuing networks consist of• Nodes

• Queuing servers• Queueless servers

• Directed graphs

System state

• Jobs• Queuing discipline (FCFS, LCFS-PR, RR, PS, SJF, SRT, etc.)

Usage

• Servers as system components• Jobs moving from one component to another

ExampleBelow a simple system:• Servers with queues are system’s shared resources• No competition for resources in queueless servers• Infinite servers, delay servers

Performance• Service times• Branching probabilities• Static values• Several job typesThe queuing discipline is essential for solvability of the model.Extended Queuing NetworksSeveral locking and competition situations can’t be described byusing an ordinary queueing network.• Extensions neccessary• New types of nodes• More difficult to solve

30

Above: a queued resource (REQ-REL)

• Dynamic service time• More difficult to solveand a changing node (CHG)• may change job type• may change job count

Other ModelsThere are many methods to model performance. Their basis isusually• A partial order (network)• Queuing networks

• Petri nets

• Task graphs

• State machine• SDL (CCITT)

• State diagrams

• Flow diagrams

• Process algebra• CCS

• CCP

• LOTOS

Network-based models are usually represented in a graphical form;several other models have a source-code-like representation.

Software ModellingSoftware complexity presents a problem• Immense number of operations• Mostly insignificant• Important operations (perhaps implicitly)• Locking• Queuing• I/O

Important locations hidden under other structure

• Abstractions• Modularity• ParallelismHow to reveal the significant parts and clear away the rest?

Example Execution NetworksOne way to deal with the problem are heterogenous and hierarchicalmodels• Execution model (below: execution network)• System model (below: queueing network)• Connection between the two (transformation analysis)

Input ModelsBesides execution, input must be modelled• Performance figures are always for some input• Execution models are often related to a certain input class

Input model characteristics depend on usage

• Declarative• Procedural

Several inputs to execute on a model

• Real• Syntethic• Artificial

Often the same program has several input classes• Clustering the input classes• Classing and search algorithms• Minimal spanning tree• AQ, ID3, CART, PAC• Neural nets• Genetical algorithms

Statistical Input Models

• Analytical models• Simulation models

Statistical models describe the input sample space

• Possible inputs• Probability of each

31

The model may be used in several ways in asimulation

• Continuous• One-shot inputs

Example G (n, p)G(n, p) is a commonly used input model in the analysis of networkalgorithms• Statistical• Efficiently executable• One-shot

G (n, p) chooses a single net from the set of allgraphs

• N nodes in the graph• Probability of each edge is p• Expected value of edges p*n^2 (directed)

Properties

• Suitable for local algorithms• Unsuitable for structural inspection• A giant component in the graph

Model InterpretationThe measurement of performance as a function of inputparameters is what should be solved from a performance model• Performance goal• Differnet views on the same model

For instance, a demand on response time may limit throughput.

Analytical SolutionAnalytical solution of net models is often based on statisticalanalysis.• Static analyysi• Model states• State transformationsMarkov state graph

A probability for each state (steady-state analysis).

• Solve the equations related to the state graph• Difficult to solve

In practice more efficient methods are used

• Also approximate methods

� ��

In simulation, the model is executed• Dynamical analysis• Simulation program• Can be solved well, but requires computation

Simulation can be

• Continuous (steady-state)• Repetition of experiments with parameter variations

Tools needed for• Statistical processing• Input generation• System warm-up

Result consistent with reality?

• Verification• Validation

Simulation Example I

Job-based simulation

A sample from a program

• Queuing network model• Steady-statejob(char *name) {create(name);while (completions < warm_up + measure) {reserve(cpu);hold(10.0);release(cpu);if (prob() < 0.5) {reserve(disk1);hold(20.0);

32

release(disk1);} else {reserve(disk2);hold(30.0);release(disk2);}completion_count++;if (completions == warm_up)reset();}if (completions == warm_up + measure)set(done);}

Simulation Example IIServer-basedThe above in a different formcpu() {int job;int ndisk;create(“CPU”);while(job_count) {job = wait_any(enter_cpu);use(fcpu, 10.0);set(cpu_free);ndisk = prob() < 0.5 ? 0 : 1;if (num_busy(fdisk[ndisk]))queue(disk_free[ndisk]);if (ndisk)set(enter_disk1[job]);elseset(enter_disk0[job]);}}

Computation with variablesTypical variables• Time T• Throughput X• Completion count C• Service demand D• Job time W• Job count L• Utilization U• Rresponse time R• Arrival rate lambda• Service rate mu

ReviewReasons for modelingTypes of system modelSchematic modelsFlow system modelStatic system modelDynamic system model

QuestionsWhat are system models?12345Differentiate between static and dynamic systems.What are system models?12345

ReferencesHeuring, Vincent P

Computer systems design and architecture Delhi : Pearson Education Asia, 1997





Sarkar, A.K.Systems analysis, data processing and quantitativetechniques New Delhi : Galgotia Publications, 1997


33

LESSON 08:OVERVIEW OF SDLC

Topics covered• Overview of SDLC• Feasibility study,• Purpose of stage of the SDLC

ObjectivesUpon completion of this Lesson, you should be able to:• Explain about Feasibility study• Explain the purpose of the stages of SDLC

Software development Lifecycle

Overview

System development Life-cycleThe six phases in the system development life cycle can be identified

by different names. Also, there are no definite rules regardingwhat must be included in each of the six phases.

What is Feasibility?

Feasibility Study

• This phase determines the objectives of the feasibility studyand who this task belongs to — analysts or the project team?

• It lists out the steps required to complete a feasibility study,identifies the scope of the current system, problems andunexploited opportunities in the current system, which maybe either manual or automated.

• It then discusses the major objectives for the new system, andthe various methods to gather data and determine how to usethe methods.

• It also helps to estimate the costs of each possible solution,and develops estimates of the benefits and shortcomings ofeach solution.

It presents users and the management views on the above issuesand their decision of whether to commit to the analysis part ofthe project.This phase may be included with some related sub phases:Current physical model:

The description of the system as it is now, including themechanisms used to accomplish tasks (e.g., people, devices).Current logical model: The system description in term offunctions, processes, and data with the mechanisms removed.New Logical Model : The Current Logical Model with newfeatures added.New Physical Model: The Current Logical Model with the variousprocesses allocated to automation, manual procedures, othermechanisms.Purpose of Stages of the SDLC

System Life Cycle

Development Process

Software development projects are often very large projects.

RequirementsAnalysis

What is the problem? Functions to be developed

Possible future extensionsAmount and kind of documentationPerformance characteristics for functions

Feasibility StudyTechnicalSocialEconomicPolitical

Design What is the solution? A system model, which solves the problem for the user.

Implementation How is the solution constructed? A transformation of the design into an executable form.

Testing Is the problem solved? Determining if the solution as constructed meets the

requirements.

Delivery Can the customer use the solution?

Maintenance Are enhancements/changes needed? Corrective - repair errors

Adaptive - modify software to adapt to changes in environmentPerfective - providing new functionality for new requirementsPreventive - improving the system's maintainability

• A number of people work on such a project for a very longtime and therefore the whole process needs to be controlled:progress needs to be monitored, people and resources need tobe allocated at the right point in time, etc.

• To understand system development, we need to recognize thata candidate system has a life cycle, just like a living cycle, just likea living system or a new product.

• System analysis and design are keyed to the system life cycle.The stages are shown below

• The analyst must progress from one stage to anothermethodically, answering key questions and achieving results ineach stage.

• A word of caution regarding life cycle activities: we isolate andsequence these activities for learning purposes, but in real lifethey overlap and are highly interrelated.

• For example, when the analyst is evaluating an existingoperation, he/she is probably thinking about an alternativeway that would improve the system or wondering whether agiven piece of hardware would be a critical cost item to considerfor a candidate system.

Therefore, there can easily be overlap during any phase of the cycle.In fact, it may act as a basis for modifying earlier steps taken. Wenow describe each of these steps.

Recognition of Need – What Is the Problem?One must know what the problem is before it can be solved. Thebasis for a candidate system is recognition of a need for improvinginformation system or a procedure.

34

System Development Life Cycle

Stage Key Question Result

1

Recognitionof need

Preliminary survey/initial

initial investigation

What is the problem opportunity Statesmen of scope and

objectives performance criteria.

2 Feasibility study

Evaluation of existing

System and procedures

Analysis of alternative

Candidate systems

Cost estimates

What are the user’s

Demonstrable needs?

Is the problem worth

Solving?

How can the problem

Be redefined?

Technical/behavioral

Feasibility

Cost/benefit analysis

System scope and objective

Statement of new scope and

Objective.

3 Analysis

Detailed evaluation of

present system

Data collection

What must be done

To solve the problem?

What are the facts?

Logical model of system

E.g. data dictionary, data

Flow diagram

Pertinent data

4 Design

General design

specifications

Detailed design

Specification

Output

Input

Files

Procedures

Program construction

Testing

Unit testing

Combined module

Testing

User acceptance Testing.

In general, how must

The problem be solved?

Specifically, how must

The problem be solved?

What is the system

Processing flow?

Does the user approve

System?

How well do individual

programs/modules test out?

How ready are programs for

acceptance test?

Designing of alternative

solutions

Final cost/benefit analysis

Hardware specification

Cost estimates]

Implementation schedule

Approval of systems by use

Programs

Test plans

Security, audit, and operating

procedures

Actual hardware use Formal

system test

5 Implementation

User training

File/system conversion

What is the actual operation?

Are user manuals ready?

Are there delays in leading files?

Training program

User-friendly documentation

6 Post-implementation and

Maintenance

Evaluation

Maintenance

Enhancements

Is the key system running?

Should the system be modified?

User requirements met user

standards met satisfied user

• For example, a supervisor may want to investigate the systemflow in purchasing, or a bank president has been gettingcomplaints about the ling line in the drive –in.

• This need lead to a preliminary survey or an initial investigationto determine whether an alternative system can solve theproblem.

• It entail looking into the duplication effort, bottleneck,inefficient existing procedures, or whether parts of the existingsystem would be candidates for computerization.

• If the problem is serous enough, management may want tohave an analyst look at it. Such an assignment implies acommitment, especially if the analyst is hired from the outside.

• In larger environments, where format procedures are the norm,the analyst procedures are the norm; the analyst’s first task is toprepare a statement specifying the scope and objective of theproblem.

• He/she then reviews it with the user for accuracy. At this stage,only a rough “ball park” estimate of the development cost ofthe project may be reached. However, accurate costs of he nextpage - the feasibility study – can be produces.

Impetus for System Change• The idea for change originates in the environment or from

with in the firm. Environment-based idea originates formcustomers, vendors, government sources and the like.

• For example, new unemployment compensation regulationsmay make it necessary to change the reporting procedure, format,and content of various reports, as well as file structures.

• Customer complains about the delivery of orders may promptan investigation of the delivery schedule, the experience oftruck drivers, or the volume of orders to be delivered.

• When investigated, each of this idea may lead to a problemdefinition as a first step in that system life cycle process.

• Ideas for change may also come from within the organization-top management, the user, the analyst).

• As an organization changes its operations or faces advances incomputer technology, someone within the organization mayfell the need to update existing application or improveprocedures. Here are some examples

• An organization acquires another organization.• A local bank branches into the suburbs.• A department spends 80 percent of its budget in one month.• A department is doing essentially the same work, and each

department head insists the other department should beeliminated.

• A request for a new form discloses the use of bootleg(unauthorized) forms.Serious problem in operations, a high rate of labor turnover,labor intensive activities, and high reject rats of finished goods,also prompt top management to initiate an investigation. Otherexamples are:

• A report reaches a senior vice president and she suspect thefigures.

• The company comptroller read an IRS audit report and startsthinking.

• An executive read about decision support systems for salesforecasting and it gives him an idea.

• Many of these ideas lead to further studies by managementrequest, often funneled downward and carried out by lowermanagement.

35

• User-originated ideas also prompt initial investigations.• For example, a bank’s need teller has been noticing long

customer line in the lobby.• She wants to know whether they are due to the computer’s

slow responses to inquiries, the new tellers limited training, orjust a sudden increase in bank business.

• To what extent and how quickly a user-originated idea isconverted to a feasibility study depend on several factors:

• The risks and potential returns.• Management’s bias toward the user.• Financial costs and the funds available for system work.• Priorities of other projects in the firm.• The persuasive ability of the user.• All these factors are crucial for a prompt response to a user

request for change.• A system analyst is in a unique position to detect and even

recommend change.• Experience and previous involvement in the user area of

operations make him/her a convenient resource for idea.• The role and status of the analyst as a professional add credibility

to the suggestions made.

Feasibility Study• Depending on the results of the initial investigation, the survey

is expanded to a more detailed feasibility study.• A feasibility study is a test of system proposal according to it

workability, feasibility study is a test of a system proposalaccording to it workability, impact on the organization, abilityto meet user needs, and effective use of resources.

• It focuses on three major questions:1. What are the user’s demonstrable needs and how does a

candidate system meet them?2. What resources are available for give candidate system? Is the

problem worth solving.?3. What is the likely impact of the candidate system on the

organization?How well done it fit within the organization’s master MISplane?

• Each of these questions must be answered carefully. Theyrevolve around investigation and evaluation of he problemidentification and description of candidates system, specificationof performance and the cost of each system, and final selectionof the best system.

• The objective of a feasibility study is not to solve the problembut to acquire a sense of its scope. During the study theproblem definition is crystallized and aspects of the problemto be included in he system are determined.

• Consequently, costs and benefits are estimated with grateraccuracy at this stage. The result of the feasibility study is aformal proposal. This is implying a report-a formal documentdetailing the nature and scope of the proposed solution. Theproposal summarizes what is known what is going to be done.

Ø It consists of the following:

1. Statement of the problem- a carefully worded statement ofthe problem that led to analysis.

2. Summary of finding and recommendation-a list of the majorfinding and recommendations of the study. It is ideal for theuser who requires quick access to the results of he analysis ofthe system under study. Conclusions are stated, followed by alist of the recommendations and a justification for them.

3. Details of findings- an outline of he methods and proceduresundertaken by the existing system, followed by coverage of heobjective and procedures of he candidates system. Included arealso discussion of output report, file structures, and costs andbenefits of the candidate system.

4. Recommendations and conclusions- Specific recommendationsregarding the candidate system, including personnelassignments, costs, project schedules, and target dates.

• After management reviews the proposal, it becomes a formagreement that paves the way for actual design andimplementation.

• This is a crucial decision point in the life cycle. Many project diehere, whereas the more promising ones continue throughimplementation.

• Changes in the proposal are made in writing, depending onthe complexity, size, and cost of the project. It is simplycommon sense to verify change before committing the projectto design.

ReviewSoftware Development Life Cycle(SDLC)Feasibility StudySub PhasesCurrent Physical modelCurrent Logical modelNew Physical modelNew Logical model

36

Software Development Life Cycle(SDLC)

Feasibility Study

Sub Phases

Current Physical model

Current Logical model

New Physical model

New Logical model

Purpose of SDLC

Requirements Analysis What is the problem? Feasibility StudyTechnicalSocialEconomicPolitical

Design What is the solution?

Implementation How is the solution constructed? .

Testing Is the problem solved? .

Delivery Can the customer use the solution?

Maintenance Are enhancements/changes needed? Corrective

AdaptivePerfectivePreventive

QuestionsWhat are strategies used in industry to model the softwaredevelopment process?12345What are the similarities and differences between these universalmodels?12345What processes or tasks span phases of the lifecycles?12345

What factors guide the choice of one process model over another?12345Describe the phases of System Development Life Cycle.What qualities you look for in a good Systems Analyst.Why is life cycle needed for the development of informationsystems?What is the difference between analysis and design? Can one beginto design without analysis? Why?







Sarkar, A.K.Systems analysis, data processing andquantitative techniquesNew Delhi : Galgotia Publications, 1997


S. Pfleeger (1991) Software Engineering. New York: Macmillan.Pressman (1997) Software Engineering: A Practitioners Approach.New York:McGraw-Hill.Van Vliet, Hans (1993) Software Engineering: Principles andPractice. Chichester: John Wiley & Sons.

37

LESSON 09 :STAGES OF SDLC

Topics coveredStages of SDLC,·Waterfall model·Characteristics Waterfall model

ObjectivesUpon completion of this Lesson, you should be able to:

Explain the stages of SDLCExplain the Simple,Elaborated and Alternate Waterfall model.

Stages of the SDLCIntroduction to System Development Lifecycle

• Software development has hit something of a crisis - we fail todeliver software that meets user expectation.

• However by employing disciplined techniques throughout thedevelopment of software and by employing a philosophy ofco-ordination, control and management through out thedevelopment lifecycle of a software project enhanced standardsmay be achieved.

• The aim is to provide discipline to the development of software- a structured framework against which development takes placeis advocated.

• A model of the process of systems development is used byorganizations to describe their approach to producing computersystems.

• Traditionally this has been a staged (or phased) approach,known as the System Life Cycle or System DevelopmentLife Cycle (SDLC).

An example of a SDLC is given below

STAGE TASK OUTCOMES

Problem Definition Establish what the problem is Statement of requirements

Feasibility Study

Establish scope & objectives;

determine whether project is

viable

Feasibility study report

AnalysisDefine what constitutes a solution

to the problem

Logical model of the

solution

Outline DesignDetermine ways of solving the

problem and choose one

Costing and high level

design of the system

Detailed DesignSpecify how the system will be

implementedSystem specifications

ImplementationWrite the program & procedures;

Install & test system

Working system &

documentation

Maintenance Provide support & enhancements Working system

Classical Waterfall1 Waterfall Model

2 Elaborated Waterfall

Alternate Waterfall Model

38

The lifecycle approach is derived from the waterfall model of systemdevelopment described by Royce in 1970, a simplified version ofwhich is given below

Classic System Development Lifecycle -Version 1There are now many variations on the theme of the waterfallmodel, an alternative is presented below:

Classic System Development Lifecycle -Version 2

Feasibility• Is the project technically, operationally, financially and legally

feasible ?• The feasibility study is used to determine if the project should

get the go-ahead.• If the project is to proceed the feasibility study will produce a

project plan and budget estimates for the future stages ofdevelopment.

Analysis

• Gather the requirements for the system.• This stage includes a detailed study of the business needs of

the organization.• Options for changing the business process may be considered.

Design

• This focuses on high level design (what programs are we goingto need and how are they going to interact), low level design(how the individual programs are going to work), interfacedesign (what are the interfaces going to look like) and datadesign (what data are we going to need).

Implementation• The designs are translated into code.• Computer programs may be written using a conventional

programming language to a fourth generation language (4GL)or an application generator.

Test

• The system is tested. Normally programs are written as a seriesof individual modules - these should be subject to separateand detailed test.

• The system is then tested as a whole - the separate modules arebrought together and tested as a complete system.

• The system needs to be tested to ensure that interfaces betweenmodules work (integration testing), the system works on theintended platform and with the expected volume of data(volume testing) and that the system does what the user requires(acceptance/beta testing).

39

Maintain• Inevitably the system will need maintenance - hopefully we

haven’t got anything wrong but people will want extra thingsadded or existing things changed over time.

• This paradigm is the oldest and most widely used approach tosystem development, it was developed by Royce in 1970.

Waterfall Approach Characteristics• Although there are many variations on the theme of the lifecycle,

each approach has its own characteristics:• Specific activities, techniques and outcomes are associated with

each stage;• Progression between stages is orderly and proceeds in a linear

fashion;• Viewed to be a process driven by technicians;• Monitoring and control takes place at the end of each stage;• Involvement of end users is typically passive and principally in

the analysis stage.• The lifecycle model assumes that systems will be constructed

from scratch by a team of IS professionals either in-house ofwithin a software house.

• Other approaches exist, namely:• Those based on alternative lifecycles e.g. prototyping,

evolutionary development, spiral model;• Those which have a different philosophical basis e.g. soft

systems and sociotechnical approaches;• The use of package software to address application areas;• The development of applications by end users.• A number of these alternative approaches will be examined

later in the course. However, our initial focus will be on theWaterfall Model of system development.

Problems with the Waterfall Approach• Real projects rarely follow the sequential process illustrated -

iteration through the cycles is required.• It is often difficult for the customer to state all requirements

explicitly at the start of the development lifecycle.With this approach, the customer must be patient - a workingversion is not usually available until late in the development lifecycle.

ReviewStages of SDLCExample of SDLCWaterfall modelCharacteristics of waterfall modelProblems of waterfall model

QuestionsWhat is the system development life cycle? How does it relate tosystem analysis?12345How would an analysis determine the user’s needs for a system?Explain.12345Where do the ideas for a proposed system originate? To whatextend does the analyst assist in this regard?12345Distinguish between initial investigation and feasibility study. Inwhat way are they related?12345Why is a system proposal so crucial for system design? Explain.12345List the drawbacks of the evolutionary software life cycle in termsof small software projects.What is a code? List nd describe each of the common codingschemes.

40







Sarkar, A.K.Systems analysis, data processing andquantitative techniquesNew Delhi : Galgotia Publications, 1997


S. Pfleeger (1991) Software Engineering. New York: Macmillan.Pressman (1997) Software Engineering: A Practitioners Approach.New York:McGraw-Hill.Van Vliet, Hans (1993) Software Engineering: Principles andPractice. Chichester: John Wiley & Sons.

Notes

41

LESSON 10 : SYSTEM APPROACHES

Topics covered• System approaches• System Requirements• Cost Benefit Analysis

ObjectivesUpon completion of this Lesson, you should be able to:Explain about System approachesExplain about System RequirementsExplain about Cost Benefit Analysis

System approach• Approaches to systems development, in professional

organizations, usually follow one of two basic models: thewaterfall model or the spiral model.

• The Waterfall model is the basis of most of the structureddevelopment methods that came into use from the 1970sonwards. It provides a framework for planning top – downsystems development.

• The development flows down a number of successive stagesare typically:

• Systems analysis;• Systems design;• Systems build and test;• Systems introduction and transition;• Maintenance of production status systems.• The Spiral model of systems development proposed by Barry

Boehm, has become popular is basis for iterative systemsdevelopment.

• The spiral model follows the same breakdown into stages, buttakes an incremental approach to systems development.

• Typically, a system is divided into smaller sub-sets fordevelopment and delivery.

This provides functionality to end-users at regular intervals, ratherthan at the end of a waterfall development.• It is also common in iterative development for highly skilled

developers to model systems with stakeholders, the designand implement them, rather than assign the stages to differentdepartments or groups.

• Effective use of the spiral approach to system developmentcan deliver systems quickly and ensure user involvement,especially when prototypes are part of the developmentapproach.

System requirements• The system is developed base on the requirements of the

system itself (to help manage an organization) and technicalrequirements.

• There are different view points of what information systemautomatization is like, however, we can classify them into 3main groups:

• View point of the system that will be developed,• Information expert’s view point and• User’s one.• These points of view often conflict with one another, at the

same time we are required to build up a successful system inwhich the system, information experts and end users share thesame view point.

• Information system is a system that collects information,manages them and creates information products for its users.

• The following part will discuss requirements of system,information experts and users.

The system’s requirements• Suitable with the general strategies: Small changes in the

organization’s development may result in bigger impacts onthe information system’s requirements. Therefore, during thesystem development process, these requirements should beregularly checked for its suitability with the general strategies.

• Supporting decision maker: Together with hands-on experience,knowledge and anticipating ability, information system playsan important role in supporting decision making process;

• Competition edge: The more competitive the environment,the more demand for better systems.

• Return on Investment: A new information system needs toshow financial benefits it can bring, because decisions oninvestment, development costs and operation costs are basedon financial analysis;

42

More advanced evaluation techniques can be applied. Thesetechniques take into consideration issues such as customersupport, organizational effectiveness, risk, etc.

• Overhead control: human resource change will influence staffnumber, staff skills and workload. In many cases, while humanresource structure is unchanged, workload and requirement forstaff skills are yet much higher;

• Supporting operational management: This is clear in preparingdetail information, making reports quickly, which contributeto a more flexible and efficient way of management;

• Improving information communication: Optimizing the flowof information, preparing necessary updated information andproviding users with the information;

• Impact of information products: Information products arefinal outcomes of the IT system. We need to pay specialattention to requirements for information products so as tothorough analysis. These requirements shall be frequently incomparison with general strategies while developing the system;

• Ability to implement more quickly and better.

Users requirements• Users are those who use the information system to manage

their organizations rather than simply those who work withcomputers.

• They are the ones who master the current information system(from information sources, management requirements to thesystem’s shortcomings) and are future owners of the system.

• Thus their requirements should be respected while developingany information system. Attention should be paid in thefollowing issues:

Easy accessThe system must be able to timely access data and manipulationsupports.

The systemThe system must be solid and stable, being able to meet staff’srequirements and provide accurate information, easy to maintainand restructure, quick in identifying and correcting mistakes;

InterfaceSuitable with working style of users, stable, easy to control data,independent and flexible, enabling users to approach in differentways.

Technical requirementsTechnological requirements should be taken into account whendesigning information systems. The important points are asfollows:• Information volume: Information technology equipment must

be suitable with the volume of information that is to beprocessed;

• Period: Everyday information which arises regularly is repetitiveinformation that requires special care;

• Accuracy: Especially high accuracy is required now and then.Accuracy is important but difficult to meet;

• However, due to its complexity, the current system fails toresolved the issues that need to be resolved by the new system.

Besides the issues of the three viewpoint groups, we would alsolike to remind you of the following popular issues:• Incompatibility: Applications developed in different

environments are often incompatible. Computers of differentkinds are difficult to be connected together, making officesisolated from information processing system;

• Shortcomings: Lack of typical information, unfriendly interfacewith users, bad storage of information.

• Low reliability: Data is conflicted, inadequate and unamendable,information is not updated regularly;

• Poor resources: Inadequate ability to search for information,lack of exploitation tools for users, low information quality;

• Bad support: Users are not aware of what they have handy,there are no clear development strategies, development pace isslow, support is inadequate, mutual understanding is low.

• It is clear that the IT experts and the users view the systemfrom different perspectives thus having different requirements.

• Analyzer’s capability is shown in his/her ability to collect ideasand evaluate them from a wider perspective, because systemdevelopers are only knowledgeable of their own areas.

Analysis• Analysis is a detailed study of the various operations performed

by a system and their relationship within and outside of hesystem.

• A key question is : What must be done to solve the problem?One aspect of analysis is defining the boundaries of the systemand determining whether or not a candidate system shouldconsider other related systems.

• During analysis, data are collected on the available files, decisionpints, and transactions handled by the present system.

• Some logical system models and tools that are used in analysisare Data flow diagrams, interviews, on-site observations, andquestionnaires. The interview is a commonly used tool inanalysis.

• It requires special skills and sensitivity to the subject beinginterviewed. Bias in data collection and interpretation can be aproblem. Training, experience, and common sense are requiredfor collection of the information needed to do the analysis.

• Once analysis is completed, the analyst has a from understandingof what is to be done?

• The next step is to decide how the problem might be solved.• Thus, in systems design, we move from the logical to the

physical aspects of the life cycle.

Analysis

Phase

43

Production, Implementation, and Operation Phases

• Data gathering is only part of systems analysis, however, thenext steps are to examine the data, assess the situation, look atthe alternatives, and recommend a candidate system. The costsand benefits of each alternative guide the selection of onealternative over the other.

• Each approach has costs and benefits that are compared withthose of other approaches before a final recommendation is

made. The outcome is a system proposal (also called a projectproposal) that summarizes the findings of the analysis andstates the recommendations for design.

Data Analysis• Data analysis is a prerequisite to cost/benefit analysis. System

investigation and data gathering lead to an assessment of currentfindings. Our interest is in determining how efficiently certainsteps are performed, how they contribute to achieving theintended goals, and cost of making improvements.

• The safe deposit department was authorized to double itscapacity from 4,000 to 8,000 boxes in an effort to meet increaseddemand. Consequently, the number of employees changedfrom three to five, with one employee assigned full-time tobilling. Analysis of the data collected made it obvious thatcustomer information or status of vacant boxes was anightmare. Customer lines were long, and service wasjeopardized.

• The representative facts for the safe deposit department areshown in the below FIGURE Representative Facts andCandidate System Design Objectives. The system requirementsare:

1. Better customer service.2. Faster information retrieval3. Quicker notice preparation.4. Better billing accuracy.Figure Representative Facts and Candidate System DesignObjectives

44

Analysis Current System Facts Objectives (System Design

Requirements)

What is done?

(processes)

Open customer account Assign safe

deposit box Issue key

Receive annual rent

Better customer service Faster

information retrieval Quicker

notice preparation.

How is it done?

(processing detail)

Some 40 boxes opened or closed daily

Master card file located too far from

customer inquiry station.

Heaviest activity on Fridays and before

holidays

Too many steps taken with new customers

Delay in billing – all manual some 80

renewal payment notices prepared daily

Cash received given to head teller at end

of each day

Poorly designed application forms

Accounting gets daily summary

Procedure for customer access to boxes is

neither documented nor consistent.

Better billing accuracy

Lower processing and

operating cost Improved staff

efficiency

More consistent billing

procedures to eliminate errors.

Who does it?

(personnel)

One person handles billing (full-time)

One Person handles security

Three persons process customers into and

out of safe deposit area

Except for two persons, rest of staff is

poorly trained

Communication among staff is adequate

Better trained personal

Experience in computer use

for other applications.

Where is it done?

(Physical

location/facility)

Location allows privacy and security

Billing carried out close to customer

counter

Allocate quiet space for

computer provide security

measure for information

access.

Assessment of

processing

Time to prepare a renewal notice is 10

minutes

Time to process a customer is 3.5 minutes

15 percent of billing is erroneous in

amount, box number, or amount of rent

28 percent of vacant boxes cannot be

located on existing books

Frequent notices regarding “ to be

renewed” boxes cost $8,000 for mailing

Employee payroll is as high as junior

officers in operations area

1. Lower processing and operating costs.2. Improved staff efficiency3. Consistent billing procedure to eliminate errors.• To achieve these design objectives, several alternatives must be

evaluated; there is seldom just one alternative. The analyst thenselects those that are feasible economically, technically, andoperationally. The approach may emphasize the introductionof a computerized billing system, replacement of staff,improved billing practices, changes in operating procedures, ora combination of several options.

• As you can imagine, each approach has its benefits and drawbacks.For example, one alternative is to introduce a computer-basedsafe deposit tracking and billing system designed to improvebilling accuracy and notice preparation and lower processingand operating costs. It would also promote staff efficiency byallowing the existing staff to concentrate on customer serviceand provide online information on box availability and thelike. The drawback includes laying off the billing clerk who

recently got married and strong resistance by the majority ofthe staff to a computerized environment.

• Another alternative might be simply to devise a semiautomatic(Ferris-wheel type) system that organizes master cards andcustomer records and improves their access. A word processingsystem might be introduced to speed the preparation of billingnotices. The edit feature of word processors speed thepreparation of billing notices. The edit feature of wordprocessors would improve the accuracy in billing preparation.If these were the only two alternatives available, which alternativeguides the selection process. Therefore, the analyst needs to befamiliar with the cost and benefit categories and the evaluationmethods before a final selection can be made.

COST/BENEFIT ANALYSISCost and Benefit Categories

• In developing cost estimates for a system, we need to considerseveral cost elements. Among them are hardware, personnel,facility, operating and supply costs.

1. Hardware costs relate to the actual purchase or lease of thecomputer and peripherals (for example, printer, disk drive,tape unit). Determining the actual cost of hardware is generallymore difficult when various users than for a dedicated stand-alone system share the system. In some cases, the best way tocontrol for this cost is to great it as an operating cost.

2. Personnel costs include EDP staff salaries and benefits (healthinsurance, vacation time, sick pay, etc.) as well as pay for thoseinvolved in developing the system. Costs incurred during thedevelopment of a system are one-time costs and are labeleddevelopment costs. Once the system is installed, the costs ofoperating and maintaining the system become recurring costs.

3. Facility costs are expense incurred in the preparation of thephysical site where the application or the computer will be inoperating. This includes writing, flooring, acoustics, lightingand air conditioning. These cost are treated as one-time costsand are incorporated into the overall cost estimate of thecandidate system.

4. Operating costs include all costs associated with the day-to-dayoperation of the system; the amount depends on the numberof shifts, the nature of the applications, and the caliber of theoperating staff. There are various ways of covering operatingcosts. One approach is to treat operating costs as overhead.Another approach is to charge each authorized user for theamount of processing they request from the system. Theamount charged is based on computer time, staff time, andvolume of the output produced. In any case, some accountingis necessary to determine how operating costs should behandled.

5. Supply costs are variable costs that increase with increased useof paper, ribbons, disk, and the like. They should be estimatedand included in the overall cost of the system.

• A system is also expected to provide benefits. The first task isto identify each benefit and then assign a monetary value to itfor cost/benefit analysis. Benefits may be tangible andintangible, direct or indirect.

45

• The two major benefits are improving performance andminimizing the cost of processing. The performance categoryemphasizes improvement in the accuracy of or access toinformation and easier access to the system by authorized users.Minimizing costs through an efficient system—error concludedin cost/benefit analysis.

Procedure for Cost/BenefitDetermination• There is a difference between expenditure and investment. We

spend to get what we need, but we invest to realize a return onthe investment. Building a computer-based system is aninvestment. Costs are incurred throughout its life cycle. Benefitsare realize in the form of reduced operating costs, improvedcorporate image, staff efficiency, or revenues. To what extentbenefits outweigh costs is the function of cost/benefit analysis.

• Cost/benefit analysis is a procedure that gives a picture of thevarious costs, benefits, and rules associated with a system. Thedetermination of costs and benefits entails the following steps:

1. Identify the costs and benefits pertaining to a given project.2. Categorize the various costs and benefits for analysis.3. Select a method of evaluation.4. Interpret the results of the analysis.5. Take action.

Cost and Benefits Identification• Certain costs and benefits are more easily identifiable than other.

For example, direct costs, such as the price of a hard disk, areeasily identified example, direct costs, such s the price of a harddisk, are easily identified from company invoice payment orcanceled checks.

• Direct benefits often relate one-to-one to direct costs, especiallysavings form reducing costs in the activity in question. Otherdirect cost and benefits, however, may not be well defined,since they represent estimated costs or benefits that have someuncertainly. An example of such costs is reserve for bad debt.It is a some uncertainty. An example of such costs is reserve forbad debt. It is a discerned real cost, although its exact amountis not so immediate

• A category of costs or benefits that is not easily discernible isopportunity costs and opportunity benefits. These are the costor benefits forgone by selecting one alternative over another.They do not saw in the organization’s accounts and thereforeare not easy to identify.

Classification of Costs and Benefits• The next step in cost and benefit determination is to categorize

costs and benefits. They may be tangible or intangible, direct orindirect, fixed or variable. Let us review each category.

Tangible or Intangible Costs andBenefits.• Tangibility refers to the case with which costs or benefits can be

measured. An outlay of cash for a specific item or activity isreferred to as a tangible cost. They are usually shown asdisbursements on the books. The purchase of hardware or

software, personnel training, and employee salaries are exampleof tangible costs. They are readily identified and measured.

• Cost that are known to exit but whose financial value cannotbe accurately measured are referred to as intangible costs.

• For example, employee morale problems caused by a newsystem or lowered company image is an intangible cost. Insome cases, intangible costs may be easy to identify but difficultto measure.

• For example, the cost to the breakdown of an online systemduring banking hours will cause the bank to lose deposits andwaste human resources. The problem is by how much? Inother cases, intangible costs may be difficult even to identify,such as an improvement in customer satisfaction stemmingfrom a real-time order entry system.

• Benefits are also classified as tangible or intangible. Like costs,they are often difficult to specify accurately. Tangible benefits,such as completing jobs in fewer hours or producing reportswith no errors, are quantifiable. Intangible benefits, such asmore satisfied customers or an improved corporate image, arenot easily quantified. Both tangible and intangible costs andbenefits, however, should be considered in the evaluationprocess.

Direct or Indirect Costs and Benefits• From a cost accounting point of view, costs are handled

differently depending on whether they are direct or indirect.Direct costs are those with which a dollar figure can be directlyassociated in a project. They are applied directly to the operation.

• For example, the purchase of a box of diskettes for $35 is adirect cost because we can associate the diskettes with the dollarsexpended. Direct benefits also can be specifically attributable toa given project. For example, a new system that can handle 25percent more transactions per day is a direct benefit.

• Indirect costs are the result of operations that are not directlyassociated with a given system or activity. They are often referredto as overhead. A system that reduces overhead realizes a savings.If it increase overhead. It incurs an additional cost.

• Insurance, maintenance, protection of the computer center,hat light, and air controlling are all tangible to a specific activitysuch as a report. They are overhead an are allocated amongusers according to formula..

• Indirect benefits are realized as a by-product of another activityor system. For example, our proposed safe deposit billingsystem that provides profiles showing vacant boxes by size,location, and price, will help management decide on how muchadvertising to do for box rental. Information about vacantboxes becomes an indirect benefit of the billing even thoughtis difficult to specify its value. Direct costs and benefits arereadily identified for tangible costs and benefits, respectively.

Fixed or Variable Costs and Benefits.• Some costs and benefits are constant, regardless of how well a

system is used. Fixed costs (after the fact)are sunk costs. Theyare constant and do not change. Once encountered, they willnot recur.

• Examples are straight-line depreciation of hardware, exemptemployee salaries, and insurance. In contrast, variable costs are

46

incurred on a regular (weekly, monthly) basis. They are usuallyproportional to work volume and continue as long as thesystem is in opertion.

• For example, the costs of computer forms vary in proportionto the amount of processing or the length of the reportsrequired.

• Fixed benefits are also constant and do not change. An exampleis a decrease in the number of personnel by 20 percent resultingform the use of a new computer. The benefit of personnelsavings may recur every month. Variable benefits, on the otherhand, are realized on a regular basis,

• For example, consider a safe deposit tracking system that saves20 minutes preparing customer notices compared with themanual system. The amount of time saved varies with thenumber of notices produced.

Savings versus Cost Advantages.• Savings are realized when there is some kind of cost advantage.

As cost advantage reduces or eliminates various cost beingincurred. Figure An Example of Saving That Reduce CurrentCostsis a summary of savings for the use of a new online tellersystem.

• In this installation, $131,870 was saves through a reduction inpersonnel, handling charges, and proof machine rental. Afterdeducting processing charges of $90,990, the net savings fromthe online system was $40,880. This is a savings that providesrelief from current costs. It is realized specifically as a result ofthe additional processing costs incurred in the new system.

Figure An Example of Saving That Reduce Current CostsSummary of Savings

From an Online Teller system

A. Reduction in personnel and payroll

Position N

Average Annual Pay

(includes 25 percent

benefits) Total

Collections teller

Savings teller

Bookkeeper

Proof operator

Subtotal

B. Reduction in handling charges

C. Reduction in proof machine rental:

Previous units (4 @ $4,500)

Present units (3 @ $1,380

Net savings from rentals

Total gross savings

Less processing charges:

Online demand deposit processing

Proof of deposit reporting

Online savings processing

Teller machine rental

Total processing charges

Net savings/year

1

5

3

1

10

$12,400

11,610

9,940

10,900

$18,000

4,140

$33,660

27,000

5,100

25,230

$12,400

58,050

29,820

10,900

$111,170

6,840

13,860

$131,870

90,990

$

40,880

• There are savings, however, that do not directly reduce existingcosts. To illustrate, examine the following case :

• A systems analyst designed an online teller system that requires14 new terminals. No reduction in personnel is immediatelyplanned. Renovation of the bank lobby and the teller cages willbe required. The primary benefits are:

1. Savings in tellers’ time to update accounts and post transactions.2. Faster access and retrieval of customer account balances.3. Availability of additional data for tellers when needed.4. Reduction of transaction processing errors.5. Higher employee morale.6. Capability to absorb 34 percent of additional transactions.• This is a case where no dollars can be realized as a result of the

costs incurred for the new installation. There might be potentialsavings if additional transactions help another departmentreduce its personnel. Similarly, management might set a value(in terms of savings) on the improved accuracy of teller, onquicker customer service, or on the psychological benefits frominstalling an online teller system.

• Given the profit motive, savings (or benefits) would ultimatelybe tied to cost reductions. Management has the final say onhow well the benefits can be cost-justified.

47

ReviewSystem ApproachSystem RequirementsDetailed Analysis Phase

QuestionsWhat are the various approaches of system development?12345Explain the various system requirements.12345What is cost-benefit analysis ? Is it important? Why? Explain.12345


Computer systems design and architecture

Delhi : Pearson Education Asia, 1997Whitten, Jeffrey L.

Systems analysis and design methods

5th ed. New Delhi : Galgotia Publications, 2001Shelly, Gary B.

Systems analysis and design

3rd ed. New Delhi : Galgotia Publications, 1999

Awad, Elias M.Systems analysis and design

New Delhi : Galgotia Publications, 1997Hoffer, Jeffrey A.

Modern systems analysis and design

2nd ed. Delhi : Pearson Education Asia, 2000Sarkar, A.K.

Systems analysis, data processing andquantitative techniques

New Delhi : Galgotia Publications, 1997Hawryszkiewycz, Igor

Introduction to systems analysis & design

4th ed. New Delhi : Prentice Hall of India, 2002S. Pfleeger (1991)

Software Engineering.

New York: Macmillan. Pressman (1997)Software Engineering:

A Practitioners Approach.New York:McGraw-Hill. van Vliet, Hans (1993)

Software Engineering:Principles and Practice.Chichester: John Wiley & Sons.

Notes

48

LESSON 11 : STAGES OF SDLC

Topics covered• Stages of SDLC• Design Phase• Implementation• Post-Implementation• Candidate system,• Benefits of SDLC.

ObjectivesUpon completion of this Lesson, you should be able to:Explain the stages of SDLC.Explain the Candidate systemExpress the benefits of SDLC

Do You Know which is the most creativephase in SDLC?

Design

• The most creative and challenging phase of the system life cycleis system design.

• The term design describes a final system and the process bywhich it is developed.

• It refers to the technical specification (analogous to the engineer’sblueprints) that will be applied in implement in the candidatesystem.

• It also includes the construction of programs and programtesting

The key question here is: how should the problem be solved?• The first steps is to determine how the output is to be produced

and in what format. Samples of the output (and input) arealso presented.

• Second input data and master files (data base) have to bedesigned to meet the requirements of the proposed output.

• The operational (processing) phases are handled thoughprogram construction and testing, including a list of theprogram needed to meet the system’s objectives and completedocumentation.

• Finally details related to justification of the system and anestimate of the impact of the candidate system on the user anthe organization are documented and evaluated bymanagement as a step toward implementation.

• The final report prior to the implementation phase includesprocedural flowcharts, record layout, report layouts, andworkable plan for implementing the candidate system.Information on personnel, money, hardware, facilities, and theirestimated cost must also be available.

• At this point, projected costs must be close to actual costs ofimplementation.

• In some firms, separate groups of programmers do theprogramming whereas other firms employ analyst-programmers who do analysis and design as well as codeprograms.

• For this discussion, we assume that two separate persons carryout analysis and programming. There are certain function,though, that the analyst must perform while programs arebeing written.

• Operating procedures and documentation must complete.Security and auditing procedures must also be developed

Implementation• The implementation phase is less creative than system design.• It is primarily concerned with user training, site preparation,

and file conversion. When the candidate system is linked toterminals or remote sites.

• The telecommunicating network and test of the network alongwith the system are also included under implementation.

• During the final testing, user acceptance is tested, followed byuser training.

• Depending on the nature of the system, extensive user trainingmay be required. Conversion usually takes place at about thesame time the user is being trained or later.

• Programming is itself design work. It is therefore a mistake toexclude programmers from the initial system design.

• System testing checks the readiness and accuracy of the systemto access update and retrieve data from new files.

• Once the programs become available, test data are read into thecomputer and processed against the file(s) provided for testing.

Post-Implementation and Maintenance• After the installation phase is completed and the user staff is

adjusted to the changes created by the candidate system,evaluation and maintenance begin.

• There is an aging process that requires period maintenance ofhardware and software.

• If the new information is inconsistent with the designspecifications, then changes have to be made.

• Hardware requires periodic maintenance.• The importance is to continue to bring new system to

standards.• Project Termination• A system project may be dropped at any time prior to

implementation. Generally projects are dropped if, after a reviewprocess, it is learned that:

49

• Changing objectives or requirements of the user cannot bemet by existing design.

• Benefits realized from the candidate system do not justifycommitment to implementation.

• There is a sudden change in the user’s budget or an increase indesign costs .

• The project greatly exceeds the time and cost schedule.• There are many reasons a new system does not meet user

requirements• User requirements were not clearly defined or understood.• The user was not directly involved in the crucial phases of

system development.• The analyst, programmer, or both were inexperienced.• User training was poor.• Existing hardware proved deficient to handle the new

application.• The new system was not user-friendly.• Users changed their requirements.Considerations for candidate systems

In today business there is more demand for computer servicesthan the resources available to meet the demand. The demandis made-up of the following:

1. Operations of existing systems.2. Maintenance that focuses on patching programs often

represents over 50 percent of maintenance.3. Enhancements that involve major modifications in program

structure or equipment.4. Request for candidate system.• All the demands require resources – human, financial and

technologies.• The computer department has to provide the following:1. Computer operators to run equipment.2. System analysts to define and design specifications.3. Application programmers to convert system specifications to

computer programs.4. Maintenance programmers to repair errors.5. Supervisors project leaders, and managers to coordinate the

jobs with the users.• Thus the basic problem is to match the demands for services

with available resources.• How much one project is favored over another depends on

technical, behavioral, and economic factors.• The technical factor involves the system department’s ability to

handle a project.• The behavioral factor involves• The user’s past experience with existing with an existing system.• The success record of the analyst• The influence the user can exert on upper management to

finance a candidate system.

• The economic factor focuses on the system’s potential returnon investment.

• The main idea behind the system development life cycle is toformalize a means of establishing control over a complexprocess.

• Work units have to be structured at three major levels for effectivecontrol of the project.

• At the lowest level, work assignments are broken down intosmall manageable tasks.

• A task is well-defined, structured work unit that can be carriedout by one individual.

• The task can be easily budgeted and scheduled and its quality ismeasured.

• Benefits of SDLC• Proven framework• Uniformity• Uniform method• Uniform operation (function)• Results (deliverables)• Facilitates information exchange• Defines and focuses roles and responsibilities• Predefined Degree of Precision• A complete solution• A correct solution• A predictable solution• Identified milestones• Enforced Planning and Control

� Problem Definition� Feasibility Study• • � Evaluation

� Economic Feasibility� Organizational Feasibility• • � Application Feasibility

� Interview secretaries� Summarize findings• • � Compare company’s goals to capabilities

50

ReviewDesign PhaseImplementation PhasePost-Implementation PhaseProject TerminationCandidate system, Benefits of SDLC

QuestionsWhy is a system proposal so crucial for system design? Explain.1234

5What is the difference between analysis and design? Can one beginto design without analysis? Why?12345What are the activities that make up system design? How doessystem design simplify implementations?12345A number of activities are carried out under implementation.Elaborate.12345When does an analyst terminate a project? How does it tie in withpost-implementation? Explain.1234

5There are several considerations in deciding on a candidate system.What are they? Why are they important?1234

5

Explain briefly the levels of structuring work units in systemdevelopment.12345

References:Heuring, Vincent P.






3rd ed. New Delhi : Galgotia Publications, 1999Awad, Elias M.





Systems analysis, data processing and

quantitative techniques



4th ed. New Delhi : Prentice Hall of India, 2002S. Pfleeger (1991) Software Engineering. New York: Macmillan.Pressman (1997) Software Engineering: A PractitionersApproach. New York:McGraw-Hill.Van Vliet, Hans (1993) Software Engineering: Principles andPractice. Chichester: John Wiley & Sons.

51

LESSON 12 :VERIFICATION AND VALIDATION PHASE

Topics covered• Verification and Validation Phase• Activities of V&V

ObjectivesUpon completion of this Lesson, you should be able to:Explain difference between verification and validationExplain the activities of V&V

V&V(Verification and Validation)

• Validation - are we building the right product?• Verification - are we building the product right?

Verification and validationOnce one has a ‘working’ simulation, the next step is to check thatthe simulation is actually doing what one expects.

What is Verification?With a complicated computer program, it is all too easy to makeerrors and find that the output is the result of a mistake, ratherthan a surprising consequence of the model. The process ofchecking that a program does what it was planned to do is knownas “Verification”.In the case of simulation, the difficulties of verification arecompounded by the fact that many simulations include randomnumber generators, which mean that every run is different andthat it is only the distribution of results, which can be anticipatedby the theory. It is therefore essential to ‘debug’ the simulationcarefully, preferably using a set of test cases, perhaps of extremesituations where the outcomes are easily predictable.

Abstract• Computing systems may be employed in the health care

environment in efforts to increase reliability of care and reducecosts.

• Software verification and validation (V&V) is an aid indetermining that the software requirements are implementedcorrectly and completely and are traceable to systemrequirements.

• It helps to ensure that those system functions controlled bysoftware are secure, reliable, and maintainable.

• Software V&V is conducted throughout the planning,development and maintenance of software systems, includingknowledge-based systems, and may assist in assuringappropriate reuse of software.

Keywords• Health care; independent verification and validation; knowledge-

based systems; software reuse; software development; softwarediagnostic tools; software verification and validation.

Executive Summary

• Like many other industries in the United States, the health careindustry is turning to computing systems to reduceadministrative overhead, control escalating costs, and improveaccuracy of stored information.

• New technology is affecting the form and usage of patientinformation, diagnostic tools, and the tools, which providetreatment.

• In particular, the application of information technology is apromising enabler for transferring gains in medical scienceresearch to patient benefit, for ensuring appropriate availabilityof patient information, and for managing the billing processes.

• Computing systems may be employed in the health careenvironment in efforts to increase reliability of care and reducecosts.

• Software verification and validation (V&V) is an aid indetermining that the software requirements are implementedcorrectly and completely and are traceable to systemrequirements.

• (Software V&V does not verify the correctness of the systemrequirements, only that the software requirements can be tracedto the system requirements.)

• It helps to ensure that those system functions controlled bysoftware are secure, reliable, and maintainable.

• It uses a structured approach to analyze and test the software.It evaluates software against its requirements for qualityattributes such as performance.

• Software V&V is conducted throughout the planning,development, and maintenance of software systems.

• The major objective of the software V&V process is todetermine that the software performs its intended functionscorrectly, ensure that it performs no unintended functions, andprovide information about its quality and reliability.

• Software V&V evaluates how well the software is meeting itstechnical requirements and its safety, security and reliabilityobjectives relative to the system. It also helps to ensure thatsoftware requirements are not in conflict with any standards orrequirements applicable to other system components.

• Software V&V tasks analyze, review, demonstrate or test allsoftware development outputs.

• The software V&V process is tightly integrated with the softwaredevelopment process.

• For each activity in software development there is acorresponding software V&V activity to verify or validate theproducts of those activities.

• This report explains these relationships, the software V&Vtasks supporting each activity, and the types of techniques thatmay be used to accomplish specific software V&V tasks.

52

• Software V&V has long been employed on new developmentprojects. Today, more and more systems are built usingcommercial off-the-shelf (COTS) software products, softwarecomponents from sources external to the developer, andsoftware from a previous version of a similar product built bythe same organization.

• Some of the issues concerning software V&V for systemsreusing any of these software types are addressed in thisdocument.

• The health care industry has been interested in, and made useof, artificial intelligence (AI) techniques by developing KBSs tounderstand the complex medical and patient data used fordiagnosis.

• This interest has grown as the scale of the problem of managingdata and knowledge has grown in the health care industry.

• While there are techniques available for V&V of the KBS, whichemploy AI techniques, the V&V and AI communities stillneed to do more research especially in the areas of makingknowledge maintenance easier and more reliable.

• These guidelines provide an overview of the issues in usingV&V and KBS techniques.

AcronymsAI Artificial IntelligenceATP Advanced Technology ProgramCASE Computer-Aided Software EngineeringCBR Case-Based ReasoningCOTS Commercial Off-The-ShelfFSM Finite State MachinesIA Intelligent AgentsIV&V Independent Verification and ValidationKBS Knowledge-Based SystemKADS KBS Analysis and Design SupportLOC Lines Of CodeNIST National Institute of Standards and TechnologySfmeca Software Failure Mode, Effects, and Criticality AnalysisSPC Statistical Process ControlSQA Software Quality AssuranceSVVP Software Verification and Validation PlanSVVR Software Verification and Validation ReportV&V Verification and Validation

1 Introduction• Like many other industries in the United States, the health care

industry is turning to computing systems to control escalatingcosts and improve the quality of service.

• New technology is affecting the form and usage of patientinformation, diagnostic tools, and the tools which providetreatment.

• In particular, the application of information technology is apromising enabler for transferring gains in medical scienceresearch to patient benefit, for ensuring appropriate availabilityof patient information, and for managing the billing processes.

• In response to the increasing dependence of the health careindustry on information technology, the Advanced TechnologyProgram (ATP) at the National Institute of Standards andTechnology (NIST) issued Solicitation 94-04, InformationInfrastructure for Health Care.

• The recognition by the ATP that the computer-based systemsused in health care must be of high integrity (1) resulted in oneelement of that solicitation being technology for verificationand validation (V&V).

• This report is the result of an effort funded by the ATP toproduce guidance for the software V&V of computer-basedhealth care systems.

• Software V&V helps to ensure and assess the quality ofsoftware-based systems.

• Computing systems may be employed in the health careenvironment in efforts to increase reliability of care and reducecosts.

• To achieve these benefits, those functions controlled by softwarein health care systems must be secure, reliable, and maintainable.Software V&V will help to provide all these assurances.

• Software verification and validation (V&V) is an aid indetermining that the software requirements are implementedcorrectly and completely and are traceable to systemrequirements. (Software V&V does not verify the correctnessof the system requirements, only that the software requirementscan be traced to the system requirements.)

• It uses a structured approach to analyze and test the software.It measures software against its requirements for qualityattributes such as performance, safety (2), and computer security.Software V&V includes activities (3) to determine that thesoftware system performs its intended functions correctly, toensure that it performs no unintended functions, and toprovide information about its quality and reliability.

• Software V&V has long been employed on new developmentprojects. Today, more and more systems are built usingcommercial off-the-shelf (COTS) software products, softwarecomponents from sources external to the developer, andsoftware from a previous version of a similar product built bythe same organization.

• Some of the issues concerning software V&V for systemsreusing any of these software types are addressed in thisdocument. This particular aspect of software V&V for reusedsoftware requires additional research from the reuse and V&Vcommunities.

• The health care industry has been interested in and made useof artificial intelligence (AI) techniques by developing KBSs tounderstand the complex medical and patient data used fordiagnosis.

• This interest has grown as the scale of the problem of managingdata and knowledge has grown in the health care industry.While there are techniques available for V&V of the KBS whichemploy AI techniques, the V&V and AI communities stillneed to do more research especially in the areas of makingknowledge maintenance easier and more reliable.

53

• These guidelines provide an overview of the issues in usingKBS techniques on systems requiring high reliability and onsome of the techniques for V&V of KBS especially KBS whichemploy expert systems.

2 Software Verification And Validation(V&V)• Software verification and validation (V&V) is an aid in

determining that the software requirements are implementedcorrectly and completely and are traceable to systemrequirements.

• (Software V&V does not verify the correctness of the systemrequirements, only that the software requirements can be tracedto the system requirements.)

• The major objective of the software V&V process is tocomprehensively analyze and test the software duringdevelopment to determine that the software performs itsintended functions correctly, ensure that it performs nounintended functions, and provide information about itsquality and reliability .

• Software V&V evaluates how well the software is meeting itstechnical requirements and its safety, security, and reliabilityobjectives relative to the system.

• It also ensures that software requirements are not in conflictwith any standards or requirements applicable to other systemcomponents. Software V&V tasks analyze, review, demonstrateor test all software development outputs.

• Software verification examines the products of eachdevelopment activity (or increment of the activity) to determineif the software development outputs meet the requirementsestablished at the beginning of the activity.

• The scope of each software development activity is defined bysoftware program management.

• A software design may consist of many small increments foreach iteration of the total system. Hence, V&V tasks can beperformed on small outputs.

• Validation that the software is a correct implementation of thesystem requirements for which the software is responsible isconducted concurrently with, and at the end of, all softwaredevelopment activities.

• The software V&V process produces a software verificationand validation plan (SVVP), individual plans and reports fortasks, summary reports, anomaly reports, and a final softwareverification and validation report (SVVR).

• Software V&V planning is conducted against systemrequirements at the highest level of planning, and then on thesoftware requirements, which should be traceable to the systemrequirements.

• Many software V&V tasks, such as planning for software systemtest, are actually performed in early development activities. Thesoftware system test plan is developed concurrently with thesoftware requirements activity.

• The plan is updated with additions or changes in details as theproject progresses.

• While different management and technical staff may beresponsible for different types of test, staff who performverification of the software requirements may be staff whoprepare preliminary plans for software system tests.

• The development of the test plans and designs may lead todiscovery of software requirements errors because of theanalysis needed to plan tests.

• One issue that often arises in planning a project and its softwareV&V effort is how to ensure the objectivity of the staffperforming software V&V tasks.

• Independent V&V (IV&V) for software grew out of thisconcern. Software IV&V is the performance of software V&Vtasks by a team that is separate from the software developmentgroup.

• The software V&V technical activities each have several tasks.Each task is accomplished by applying one or more techniques.

• A specific technique, such as control flow analysis, focuses onfinding a specific type of problem, for example, a logic error.

• An aggregate of techniques is usually necessary to achieve theobjectives of a task.

54

Major Software V&V Activities

ACTIVITY

TASKS

Software V&V

Management

- Planning

- Monitoring

- Evaluating results, impact of change

- Reporting

Software Requirements

V&V

- Review of concept documentation (if not

performed prior to software requirements

development)

- Traceability analysis

- Software Requirements Evalutaion

- Interface Analysis

- Initial Planning for Software System Test

- Reporting

Software Design V&V

- Traceability Analysis

- Software Design Evaluation


- Initial Planning for Unit Test

- Initial Planning for Software Integration

Test

- Report

Code V&V

- Traceability Analysis

- Code Evaluation


- Completion of Unit Test Preparation

- Reporting

Unit Test- Unit Test Execution

- Reporting

Software Integration Test

- Completion of Software Integration Test

Preparation

- Execution of Software Integration Tests

- Reporting

Software System Test (4)

- Completion of Software System Test

Preparation

- Execution of Software System Tests

- Reporting

Software Installation Test- Installation Configuration Audit

- Reporting

Software Operation and

maintenance V&V

- Impact-of-Change Analysis

- Repeat Management V&V

- Repeat Technical V&V Activities

• This document treats acceptance test as a function of the acquirerof the software system, while acknowledging that the acquirermay sometimes work with V&V staff from the softwarerequirements V&V through software installation test to developacceptance test.

• Tasks for acceptance test parallel those for software system test.Differences may exist in the specific objectives, which mayinfluence test requirements.

ReviewSoftware V&V ManagementSoftware Requirements V&VSoftware Design V&VCode V&VUnit TestSoftware Integration TestSoftware System Test (4)

Software Installation TestSoftware Operation and maintenance V&V

QuestionsExplain about Software Design V&V12345Differentiate between Unit and Integration testing.12345Differentiate between verification and validation1234

5

List the various types of testing.12345







55









4th ed. New Delhi : Prentice Hall of India, 2002

Notes

56

LESSON 13:VERIFICATION AND VALIDATION

Topics covered• Independent Verification and Validation Phase• Software V&V Management,Software V&V activities.

ObjectivesUpon completion of this Lesson, you should be able to:Explain about Independent verification and validationExplain the activities of software V&V

What is meant by Independent V&V ?• Some software V&V activities may be performed by two

different groups. The use of a different organization (otherthan the software development group) for software V&V iscalled independent verification and validation (IV&V).

• Technical independence requires that members of the IV&Vteam (organization or group) may not be personnel involvedin the development of the software.

• This team must have some knowledge about the system designor have related experience and engineering background enablingthem to understand the system.

• The IV&V team must not be influenced by the developmentteam when the IV&V team is learning about the systemrequirements, proposed solutions for building the system, andproblems encountered.

• Technical independence is crucial in the team’s ability to detectthe subtle software requirements, software design, and codingerrors that escape detection by development testing and SQAreviews.

• The technical IV&V team may need to share tools from thecomputer support environment (e.g., compilers, assemblers,utilities) but should execute qualification tests on these toolsto ensure that the common tools themselves do not maskerrors in the software being analyzed and tested.

• The IV&V team uses or develops its own set of test andanalysis tools separate from the developer’s tools wheneverpossible.

• Managerial independence means the responsibility for IV&Vbelongs to an organization outside the contractor and programorganizations that develop the software.

• While assurance objectives may be decided by regulations andproject requirements, the IV&V team independently decidesthe areas of the software/system to analyze and test, techniquesto conduct the IV&V, schedule of tasks (within the frameworkof the system schedules), and technical issues to act upon.

• The IV&V team provides its findings in a timely fashionsimultaneously to both the development team and the systems

management who acts upon the reported discrepancy andfindings.

• Financial independence means that control of the IV&V budgetis retained in an organization outside the contractor and programorganization that develop the software.

• This independence protects against diversion of funds oradverse financial pressures or influences that may cause delay orstopping of IV&V analysis and test tasks and timely reportingof results.

• The extent that each of these parameters is vested in the IV&Vteam’s responsibilities defines the degree of independenceachieved.

• Based on the definitions of IV&V and how much IV&V aspecific project requires, some software V&V activities may beconducted by both the developer and another organization.

• For example, unit test by one organization may focus ondemonstrating that specific objectives (e.g., safety objectivesrelative to the system), which may differ from the objectives ofthe developer (e.g., logic structure, test coverage),.

Software V&V Management• The process of software V&V needs to be managed and

performed comprehensively over the entire softwaredevelopment process.

• Management tasks, spanning all of the software developmentactivities, are to:

• Plan and maintain the software V&V process.• Coordinate and interpret performance and quality of the

software V&V effort.• Report discrepancies promptly to the user or development

group.• Identify early problem trends and focus software V&V tasks

on them.• Provide a technical evaluation of the software performance and

quality attributes at each major software program review (so adetermination can be made of whether the software producthas satisfied its set of software requirements well enough toproceed to the next activity).

• Assess the full impact of proposed software changes.• An SVVP contains the information necessary to manage and

perform software V&V. Major steps in developing an SVVPare to:

• Define (or confirm, if already provided) the quality andperformance objectives (e.g., verify conformance tospecifications, verify compliance with safety and computersecurity objectives relative to the system, assess efficiency andquality of software, and assess performance across the fulloperating environment).

57

• Characterize the types of problems anticipated in the systemand define how they would be manifested in the software.

• Select the software V&V analysis and testing techniques toeffectively detect the system and software problems.

• Select the metrics and techniques applied to V&V results tomeasure and predict the quality of the software.

• The SVVP may include details for acquiring tools and fortraining personnel. The SVVP is revised as knowledgeaccumulates about the characteristics of the system, the software,and the problem areas in the software and in software V&Vactivities.

• The software V&V process could be tailored to specificapplications; however, the risk of the software failing and thesubsequent consequences must be considered when selectingsoftware V&V activities.

• One software V&V management task is to monitor thesoftware V&V technical progress and quality of results.

• During each software V&V activity, planned software V&Vtasks are reviewed and new ones are added to focus on thecritical performance/quality functions of the software and itssystem.

• The monitoring task includes formal reviews of software V&Vdiscrepancy reports and technical evaluations to provide a checkof their correctness and accuracy.

• Internal monitoring of the quality and accuracy of softwareV&V results is essential because the development group mustmake the necessary software changes as indicated by the softwareV&V results.

• If the software V&V results are erroneous, or of poor quality,the development group wastes its time and resources inattempting the changes, and more importantly, loses confidencein the effectiveness and helpfulness of the software V&Vresults.

• Software V&V “focus on identifying and eliminating the specifichigh-risk problems to be encountered by a software project.”This does not mean that software V&V should examine only20% of the software.

• Rather, software V&V needs to examine all the software.• This includes: identifying potential hazards or threats to the

safety and security of the system, prioritizing the softwarefunctions by criticality, and allocating software V&V analysisresources to those areas of the software which contain critical (5)

functions and high-risk problems (i.e., more error-prone).Identifying and focusing on critical and high-risk areas of thesoftware can be addressed by these software V&V methods:

• Examination of early program deliveries to software V&V staff;• Use of software hazard (or threat) analysis; and• Conduct of a “criticality analysis” to identify the most critical

functions of the software.• Various approaches in development can provide early product

information to software V&V.• These include: prototypes, incremental software development,

and handing over each unit or sub function followingdevelopment unit testing. Incremental software development

is an effective method of providing early product informationto software V&V.

• The early deliveries reinforce the systematic analysis and testapproach used by software V&V to examine the software insmaller pieces while progressively evaluating larger softwarepieces as each new piece is integrated.

• High-risk software areas are easier to identify by using theincremental approach because the software V&V can:

• Provide an early lead time to evaluate each engineering solutionand allow time to suggest alternative solutions which can beincorporated in subsequent incremental deliveries withoutadversely impacting the schedule.

• Isolate each new set of requirements and evaluate their impacton the system performance.

• Provide early indications of system performance so thatadjustments can be made to refine the desired performance.

• Develop trend information about software anomalies and riskissues to allow time to adjust the development and softwareV&V resources and planning to accommodate evolvingsoftware risk issues.

• In incremental development, a software build (or early product)represents a basic program skeleton including draftdocumentation containing portions of the full softwarecapabilities.

• Each successive build integrates additional functions into theskeleton. Based on discrepancy or progress reports fromsoftware V&V, software program management can make thetechnical and management decisions to refocus the softwareV&V and development team onto the program’s specificproblem areas of the software.

• Two related analyses, criticality and hazard, can help focus theV&V effort on those parts of the program whose consequenceof failure are most severe. A hazard is an (unsafe) “conditionthat may lead to an unintended event that causes an undesirableoutcome”.

• For example, a driver of a car ignores warning lights at a railroadcrossing and drives the car onto the tracks. The hazard is thepresence of the car and train on the track at the same time.

• The unintended event (mishap) is the train colliding with thecar. The undesirable outcome is the probable loss of life anddamage to the car and train.

• The term hazard generally is used to refer to safety problems;the term threat generally is used to refer to security problems.

• In this lesson, the methods and issues related to hazard analysisare also applicable to security issues; the terms threat and securitycould be used in place of hazard and safety respectively.

• Criticality analysis locates and reduces high-risk problems andis performed at the beginning of a project.

• It identifies the functions and units which are required toimplement critical program functions or quality requirements(e.g., safety, computer security). The steps of the analysis are:

• — Develop a block diagram or control-flow diagram of thesystem and its software. Each block or control-flow boxrepresents a system or software function (unit).

58

• — Trace each critical function or quality requirement throughthe block or control flow diagram.

• — Classify all traced software functions (units) as critical toeither the proper execution of critical software functions or thequality requirements.

• — Focus additional analysis on these traced software functions(units).

• — Repeat criticality analysis for each activity to observe whetherthe implementation details shift the criticality emphasis to otheror additional functions (units).

• System hazard analysis is used to identify potential events andcircumstances that might lead to problems of varying degreesof severity, from critical failures resulting in loss of life ornational security problems, to less serious malfunctions in thesystem.

• Software hazard (or threat) analysis focuses on the role ofsoftware relative to the hazards, or threats.

• Specific techniques that can be used for hazard analysis areincluded in section 6 with the V&V techniques; these includeevent tree analysis, software fault tree analysis,

• When identification of high risk areas from early deliveries,criticality analysis, and hazard (or threat) analysis are usedtogether, the software V&V approach can focus on the mostcritical areas of the early software products.

• Software V&V results, obtained early enough in the softwaredevelopment process, can have significant impact on the qualityand performance of the system under development.

Software V&V Activities• Software V&V should begin when the project begins. Usually

the first software V&V tasks are conducted during the softwarerequirements V&V activity.

• One V&V task is to examine the early project documentation,often called concept documents, to verify that the system to bebuilt is not only feasible but will use the rules, conventions,algorithms, and practices appropriate to the application domainof the system.

• Software requirements V&V is performed to ensure that thespecified software requirements are correct, complete, consistent,accurate, readable, and testable, and will satisfy the systemrequirements.

• Poorly specified software requirements (e.g., incorrect,incomplete, ambiguous, or not testable) contribute to softwarecost overruns and problems with reliability.

• Even when software fully meets its requirements upon delivery,there may be problems in the maintenance activity becausegeneral requirements (e.g., maintainability, quality, andreusability) were not accounted for during the originaldevelopment.

• Identifying software requirements is difficult because thecomplexity of the problems being solved causes uncertainty indeveloping the intended system performance requirements.

• The occurrence of changes in requirements (e.g., to incorporatenew technologies, new missions, new knowledge, newinterfacing systems, new people coming on the scene)

throughout the software development process addssignificantly more chance for error.

• Software requirements V&V is intended to prevent theseproblems from occurring.

• Design errors can be introduced by misrepresentation of thefunctional requirements and by implementation constraintsrelating to timing, data structures, memory space, and accuracy.

• Software design V&V provides assurance that softwarerequirements are not misrepresented or incompletelyimplemented; that extraneous software requirements are notdesigned into the solution by oversight; that softwarerequirements are not left out of the software design; and thatother constraints are managed correctly.

• Clerical and syntactical errors have been greatly reduced throughuse of structured programming, reuse of code, adoption ofprogramming standards and style guides, availability of morerobust computer languages, better compiler diagnostics andautomated support, and, finally, more knowledgeableprogrammers.

• Nevertheless, problems still occur in translating design intocode and code V&V continues to be an important softwareV&V activity.

• Test management is an important part of the software V&Vactivity in which all testing needed for the software system isconsidered and planned.

• Software V&V test planning begins with software requirementsand spans almost the full range of activities.

• Test planning tasks encompass different types of testing—unit test, software integration test, and software system test.The planning activities result in documentation for each testtype consisting of test plan, test design, test case, and testprocedure documents.

• Unit test verifies the design and implementation of softwareunits. Software integration test verifies functional requirementsas the software units are integrated together.

• Special attention is focused on software, hardware, and operatorinterfaces. Software system test validates the entire softwareprogram against system requirements and software performanceobjectives.

• Software system tests validate that the software executes correctlywithin its stated operating environment. The software’s abilityto deal properly with anomalies and stress conditions isemphasized.

• Software V&V tests are not intended to duplicate or replace theuser and development group’s test responsibilities, but insteadtest behavior not normally checked by the user or developmentgroup.

• Software installation test validates that the software operatescorrectly with the operational hardware system and with othersoftware, as specified in the interface specifications.

• It verifies that the installation procedures are correct andadequate, that the software is the same as the executable codedelivered for installation, and that all supporting softwareproducts are the proper versions.

59

• Software installation test verifies that the software has beenaccurately tailored for site-dependent parameters and that theconfiguration of the delivered product is correct.

• In software operation and maintenance V&V, when a softwarechange is made, all software V&V activities are considered andpossibly repeated to ensure that nothing is overlooked.

• Software V&V activities include examining the impact of thechange throughout the system to understand what softwareV&V activities are needed. Software V&V activities are addedor deleted to address the type of software change made.

• In many cases, an examination of the proposed software changeshows that software V&V needs to repeat its activities on onlya small portion of the software.

• Also, some software V&V activities, such as verifying the originalconcepts, require little or no effort to verify a small change.

• Small changes can have subtle but significant side-effects in asoftware program; for this reason, change analysis (a softwareoperation and maintenance V&V task) is significant inpreventing unintended functions and problems from makingtheir way into new versions of the system.

ReviewIndependent V&VTechnical independenceManagerial independenceFinancial independenceSoftware V&V management, activities

QuestionsExplain about Independent V&V12345Differentiate between various IV&V.12345Explain about the software V&V activities.12345



Whitten, Jeffrey L.


5th ed. New Delhi : Galgotia Publications, 2001Shelly, Gary B











Notes

60

LESSON 14 :VERIFICATION AND VALIDATION

Topics covered• Software Requirements V&V• Software Design V&V, Code Verification• Unit• Integration• Software System Test

ObjectivesUpon completion of this Lesson, you should be able to:Explain Software Requirements V&VExplain Software Design V&V

Software Requirements V&V• The software requirements V&V activity checks that the

allocation of system requirements to software is appropriateand correct, and how well the software requirements have beenspecified (e.g., correct, complete, nonambiguous, testable).

• It should be structured to ensure that the software objectiveshave been met. Verification of the software requirements shouldinclude an examination of documentation produced earlier insystem development (e.g., initial feasibility studies, conceptson which the system has been designed) if this examinationhas not already been performed.

• If the assumptions, algorithms, and physical rules imposedon the software requirements previously have not been verifiedto be appropriate for this project, then software V&V shouldperform those checks.

• Inputs to the software requirements V&V activity may bedocuments written in natural or formal mathematical languagesand may include graphics and charts.

• When formal mathematical languages are used, other forms ofrepresentations may be provided to different users of thespecifications.

• Concurrently with software requirements V&V, software systemtest planning in initiated.

Software V&V examines all the proposed testing for the systemto ensure that comprehensive testing and appropriate resourcesare planned.

Software Design V&VØ The software design V&V activity occurs after the software

requirements have undergone the software V&V process andthe software design, or an increment of the software design,has been completed.

Ø The software V&V tasks of trace ability, evaluation, and interfaceanalysis provide assurance that software requirements are notmisrepresented, incompletely implemented, or incorrectlyimplemented.

• By verifying that the software design meets its softwarerequirements, the software design V&V activity also supportsvalidation that the software design meets system requirements.

• When the software system is designed, decisions may be madeto incorporate existing software.

The tasks and techniques are the same as for the software beingdeveloped, but the objectives and issues are specific for reuse.

General• Conduct a software design traceability analysis - Trace software

design to software requirements, and vice versa. Check therelationships for accuracy, completeness, consistency, andcorrectness.

• Conduct a software design evaluation.• Evaluate the software design for accuracy, completeness,

consistency, correctness, and testability.• Evaluate software design for compliance with software design

standards; language standards if appropriate; and softwareengineering practices.

• Assess software design against assigned quality attributes.• Conduct a software design interface analysis - Evaluate software

design for accuracy, completeness, consistency, and correctnessof hardware, operator and software interface requirements.

• Verify that the software requirements for assertions, responsesto assertions and other required system algorithm and integritychecks or fault tolerance protections have been designed intothe software. Check that the software design is complete andaccurate and will not adversely affect system performance.

• Coordinate with software integration test planning.

Reuse -Specific• Conduct an evaluation of the original software design

documentation for compliance to software design requirementsof the new system. Verify interface requirements.

• Generate any needed software design information or justifythe use of the software without the required information. Thisdetermination should be based on recognized risk (safety, costof modifications, impact of various degrees of uncertainty onthe project) and coordinated with the user.

• If any modifications are needed, evaluate whether or not thesoftware and documentation are adequate to support themodification (e.g., for change analysis, testability). If not, theneeded information should be obtained or developed. If thisis not prudent, modifications should not be made when theycannot be supported by adequate software design information.

KBS -Specific• — Verify that the domain model:• - Is complete and consistent; and,• - Represents the domain knowledge.

61

• — Verify that the domain model addresses, at the requiredlevel of accuracy and completeness, the range of expectedproblems.

• — Verify that the domain model operates in the specified scope.

Code Verification• The code verification activity verifies correct implementation of

software design into code.• Often this activity requires tedious checking of details within

the code; automation provides protection against human errorin gathering the code information for analysis and also canspeed the process.

• Code verification is the last opportunity to find and removeerrors that could cause unnecessary costs and delays fromadvancing poor code into any of the test activities.

• At this point in the software development process, the reuseissues should have been examined and the decision made toreuse or not to reuse the software.

• In the case that changes are to be made to the code, or if thereis a possibility changes will be needed in a future version of thesoftware system under development, some software V&V tasksmay be needed.

• The knowledge base should be internally consistent and reflectthe domain model. In its simplest form, maintainingknowledge base consistency (or integrity) means not allowing afact and its negation to both be part of the knowledge base.More extensive consistency checks can disallow rules that would,potentially, infer both a fact and its negation. Knowledgeconsistency is a key issue.

• A consistent domain model and a consistent representationof that model is critical. This is especially true for domainsrepresenting physical structures or controlled equipment.

• The model of the equipment and the physics controlling thebehavior of the equipment must be consistent for computercontrollers to function properly. In other domains, expertdisagreement over the interpretation of a set of facts may benormal and expected.

• For example, legal disputes frequently involve the interpretationof the facts themselves. Probabilities can be one way to handleconflicting knowledge.

General• Conduct a source code traceability analysis - Trace source code

to software design, and vice versa. Check the relationships foraccuracy, completeness, consistency, and correctness.

• Conduct a source code evaluation.• Evaluate the source code for accuracy, completeness, consistency,

correctness, and testability.• Evaluate source code for compliance with code standards,

language standards if appropriate, and software engineeringpractices.

• Assess source code against assigned quality attributes.• Conduct a source code interface analysis - Evaluate the source

code for accuracy, completeness, consistency, and correctnesswith respect to the hardware, operator, and software interfaces.

• Evaluate draft code-related documents (e.g., user manual,commentary within the code) with source code for completeness,consistency, and correctness.

• Coordinate with unit test (8).

Reuse-Specific• If the source code is available, compare it to known design

specifications. Evaluate for correctness, consistency,completeness, and accuracy. Assess the interfaces for consistencywith the system in which the reused code will be placed. Assesssource code quality. (This task may be needed in instances wherethe history of the code is not well-known.)

• Evaluate source code for testability. Evaluate code-relateddocumentation received from the source for suitability for anyfuture modifications.

KBS-Specific• Conduct a logical verification of the structure of the knowledge

and rules in the knowledge base for consistency, completeness,etc.

• Verify that the knowledge base implements the domain modelaccurately.

Unit Test• Unit test is the test of the software elements at the lowest level

of development. Units may be aggregates of software elements.• Planning for unit test should occur concurrently with the

software design activity. Reused software will probably notundergo unit test; unless changes were made to the units.

• Then, appropriate testing is performed as in regression testing.

General• Test planning - Establish the objectives of the unit test, the

strategies to be employed, the coverage requirements, reportingand analysis, and close-out of anomalies.

• Generate, monitor, and update the unit test plan to accomplishobjectives.

• Trace test design, cases, procedures, and execution results tothe unit designs.

• Confirm that anomalies during test are software anomalies,and not problems detected for other reasons.

• Generate test cases and procedures - Develop test cases andprocedures for unit test and continue tracing as required bysoftware test plans.

• Perform unit test - Check individual software units fortypographical, syntactic, and logic errors to ensure that eachcorrectly implements the software design and satisfies thesoftware requirements; execute the test cases; analyze results toverify anomalies; recommend changes to software design orcode; and conduct re-testing as necessary.

• Document test activities and results.

Reuse-Specific• Evaluate existing test cases and reports for suitability for

intended use.

62

• Prepare test cases and test procedures if any modifications aremade to the reused software.

• Follow the criteria for unit test.

KBS-Specific• Evaluate the knowledge and rules in the knowledge base against

the domain knowledge.• Establish objective for testing portions of domain knowledge.• Plan tests for accuracy and completeness of domain model.• Define test procedures to test for expected performance level

of the system.

Software Integration Test• Software integration tests check the interaction with other

software (e.g., libraries) and hardware.• The software integration test schedule depends upon the

development and integration schedules for software units,hardware, and other components.

• For large systems, software integration test planning may requireclose coordination among all system personnel to ensure thatthe overall test objectives are achieved by the selected teststrategy.

• When all system components have been integrated and havesuccessfully undergone software integration tests, then thesystem moves into software system test.

• During software integration test, reused software units areintegrated into the system. I

• t is critical to test that the interfaces are correct, and that theresulting software meets operating requirements.

General• Test planning - Establish the objectives of the software

integration test, the strategies to be employed, the coveragerequirements, reporting and analysis, and close-out ofanomalies. Ensure that interface testing of reused software toother system software is planned.

• Generate, monitor, and update a software integration test planto accomplish identified objectives.

• Trace test design, cases, procedures, and execution results tosoftware requirements.

• Generate test cases and procedures - Develop test cases andprocedures for unit test and continue tracing as required bysoftware test plans.

• Perform software integration test.• Check the inter-unit communication links and test aggregate

functions formed by groups of units.• Confirm that anomalies during test are software anomalies,

and not problems detected for other reasons.• Ensure any changes to software requirements, software design,

or code are made. Conduct retesting as necessary.• Conduct functional, structural, performance, statistical, and

coverage testing of successfully integrated units after eachiteration of software integration and successful testing ofinterfaces and interactions.


Reuse-Specific• Perform software integration test in accordance with test

procedures.• Analyze results to determine if the software implements the

intended use requirements and known design and that thesoftware units function correctly together.

• Conduct interface tests of reused units with other systemcomponents.

• Conduct tests of reused units with other system componentsto validate performance requirements.

• Evaluate existing test cases and reports for suitability forintended use.

• Prepare test cases and test procedures if any modifications aremade to the reused software.

• Follow the criteria for software integration test.

KBS-Specific

• Evaluate knowledge base for completeness and consistency.• Verify that the knowledge base represents the full scope of the

domain model.

Software System TestSoftware system test, in the context of software V&V, involvesthe conduct of tests to execute the completely integrated system.Software system test is the validation that the software meets itsrequirements. Validation of the complete system may involvemany tests involving all system components.The software system tests exercise those system functions thatinvoke software to determine whether the software behaves asintended relative to complete system performance.These tests must be conducted in such a manner as to stress thesystem based on software responses to system inputs (e.g., fromsensors, operators, databases).While software system tests are conducted after the system hasbeen built, it is imperative that planning for these tests is conductedconcurrently with the software requirements activity because:• Analyzing the software requirements for test requirements may

result in finding software requirements errors and/or discoveryof untestable requirements.

• Establishing test facilities (e.g., model of operationalenvironment) and Computer-Aided Software Engineering(CASE) tools (e.g., test case generators, test data base) mayrequire as much time as development of the system.

• For reused software, software system test is performed to assurethat the software is correct, consistent with prior documentation,complete for use and/or modification, and accurate.

• At the system level, reused software should be considered partof the system. Tests are in accordance with test procedures.

• Results are documented and traced as required by the softwaresystem test plan.

General

63

• Test planning - Establish the objectives of the software systemtest, the strategies to be employed, the coverage requirements,reporting and analysis, and close-out of anomalies.

• Generate, monitor, and update a software system test plan toaccomplish objectives.

• Trace system and software requirements to test software design,cases, procedures, and execution results.

• Generate test cases and procedures - Develop test cases andprocedures for unit test and continue tracing as required bysoftware system test plans.

• Test the operation of the software as an entity (sometimes asimulated environment may be used); confirm that anomaliesduring test are software anomalies, not problems detected forother reasons; ensure any changes to software (softwarerequirements, software design, code, or test cases) have beenmade; and conduct retesting as necessary.


Reuse-Specific

• Evaluate existing test cases and reports for suitability forintended use.

• Prepare test cases and test procedures if any modifications havebeen made to the reused software.

• Follow the criteria for software system test within the boundariesof the known and documented software design.

KBS-Specific

• Define procedures for testing the system according to theexpected knowledge of the end user.

QuestionsExplain about Software Requirements V& V12345Explain about code verification.12345








Awad, Elias M.Systems analysis and design








Notes

64


Topics covered• Software Installation technique• Software operation & Maintenance Verification and Validation

Phase• Strategies for checking techniques.

ObjectivesUpon completion of this Lesson, you should be able to:Explain about software installation techniqueExplain the software operation & maintenance V&VExplain about different strategies for checking techniques.

Software Installation Test• The software installation test activity is the final step before

launching full customer acceptance testing.• The purpose of installation test is to demonstrate that the

correct software has been delivered and that the softwareinterfaces are correct relative to any interfaces at the installationsite.

• Acceptance testing, which involves the user/customer, isoutside the scope of this document.

General• — Conduct an installation configuration audit.• Determine that all software outputs needed to operate the

system are present.• Check that the software installed in the system is the software

that underwent software V&V.• — Develop and execute tests that will examine and stress site-

unique parameters (e.g., printer interface, operating systeminterface, monitor interfaces).

• — Generate applicable documentation.• — Generate an SVVR (or generate it at the end of the software

V&V process).

Reuse-Specific• — Conduct an installation configuration audit to verify that

any reused software that has not been modified is the currentversion.

KBS-Specific• — Ensure that data and updates to the knowledge base which

are supplied from external sources are in an acceptable form.

Software Operation and MaintenanceV&VØ The software operation V&V activity requires periodic checks

that the integrity of the system has been maintained, that anychanges to the system which affect its operation have been

documented, and operators have received training in new orchanged procedures.

• The software maintenance V&V activity requires planning forsoftware V&V based on the extent of the maintenance (e.g.,adaptive, corrective, perfective ,and hence a revisit of all thesoftware development activities to identify to what extent eachsoftware V&V activity must be performed.

• If software V&V has not been performed during softwaredevelopment, then the V&V during software operations andmaintenance must consider performing a selected set of tasksfrom the software V&V activities related to earlier developmentactivities.

• Some activities may include generating software requirementsor software design information from source code, an activityknown as reverse engineering. While costly and timeconsuming, it is necessary when the need exists for rigoroussoftware V&V effort.

General• — Conduct an anomaly evaluation - Evaluate the severity of

anomalies during software operation and their effect on thesystem.

• — Conduct a proposed change assessment - Assess proposedchanges to the software and their effect on the system todetermine software V&V activities from earlier developmentto be repeated. Conduct them.

• — Develop an SVVP.

KBS-Specific• — Plan for update of knowledge base including domain model.• — Determine mechanisms used for updating knowledge base.

Software V&V Techniques

• The conduct of software V&V tasks to fulfill the requirementsof the V&V activities generally involves techniques selectedfrom three major classes: static, dynamic, and formal analysis.

• Static analysis techniques are those which directly analyze theform and structure of a product without executing the product

• Reviews, inspections, audits and data flow analysis are examplesof static analysis techniques.

Static Analysis Techniques• Are traditionally applied to software requirements, software

design and source code.• They may also be applied to test documentation, especially test

cases, to verify their traceability to the software requirements,their adequacy to fulfill test requirements, and their accuracy.

Dynamic analysis techniques

65

• Involve execution, or simulation, of a development activityproduct to detect errors by analyzing the response of a productto sets of input data .

• For these techniques, the output values, or ranges of values,must be known.

• Testing is the most frequent dynamic analysis technique.Prototyping, especially during the software requirements V&Vactivity, can be considered a dynamic analysis technique; in thiscase the exact output is not always known but enoughknowledge exists to determine if the system response to theinput stimuli meets system requirements.

• Formal analysis is the use of rigorous mathematical techniquesto analyze the algorithms of a solution .

• Sometimes the software requirements may be written in aformal specification language (e.g., VDM, Z) which can beverified using a formal analysis technique like proof-of-correctness.

• The term formal often is used to mean a formalized process,that is, a process that is planned, managed, documented, and isrepeatable. In this sense, all software V&V techniques are formal,but do not necessarily meet the definition of the mathematicaltechniques involving special notations and languages.

Strategies for Choosing Techniques• Some software V&V techniques used during software

requirements V&V tasks are control flow analysis, data flowanalysis, algorithm analysis, and simulation.

• Control and data flow analysis are most applicable for real timeand data driven systems.

• These flow analyses transform logic and data requirements textinto graphic flows which are easier to analyze than the text.PERT, state transition, and transaction diagrams are examplesof control flow diagrams.

• Algorithm analysis involves re-derivation of equations orevaluation of the suitability of specific numerical techniques.

• Simulation is used to evaluate the interactions of large, complexsystems with many hardware, user, and other interfacingsoftware units.

• Some software V&V techniques used during software designV&V tasks include algorithm analysis, database analysis, sizingand timing analysis, and simulation.

• Algorithm analysis examines the correctness of the equationsor numerical techniques as in the software requirements activity,but also examines truncation and round-off effects, numericalprecision of word storage and variables (e.g., single- vs.extended-precision arithmetic), and data typing influences.

• Database analysis is particularly useful for programs that storeprogram logic in data parameters.

• A logic analysis of these data values is required to determinethe effect these parameters have on program control. Sizingand timing analysis is useful for real-time programs havingresponse time requirements and constrained memory executionspace requirements.

• Some software V&V techniques used during code V&V tasksare control flow analysis, database analysis, regression analysis,and sizing and timing analysis.

• For large code developments, control flow diagrams showingthe hierarchy of main routines and their sub functions areuseful in understanding the flow of program control.

• Database analysis is performed on programs with significantdata storage to ensure common data and variable regions areused consistently between all call routines.

• Data integrity is enforced and no data or variable can be accidentallyoverwritten by overflowing data tables. Data typing and use areconsistent throughout all program elements.

• Regression analysis is used to reevaluate software requirementsand software design issues whenever any significant code changeis made.

• This technique ensures project awareness of the original systemrequirements.

• Sizing and timing analysis is done during incremental codedevelopment and compared against predicted values. Significantdeviations between actual and predicted values is a possibleindication of problems or the need for additional examination.

• Another area of concern to software V&V is the ability ofcompilers to generate object code that is functionally equivalentto the source code, that is, reliance on the correctness of thelanguage compiler to make data dependent decisions aboutabstract programmer coded information.

• For critical applications, this problem is solved by validatingthe compiler or by validating that the object code produced bythe compiler is functionally equivalent to the source.

• Code reading is another technique that may be used for sourcecode verification. An expert reads through anotherprogrammer’s code to detect errors. In an experiment conductedat the National Aeronautics and Space Administration GoddardSpace Flight Center, code reading was found to be more effectivethan either functional testing or structural testing.

• The reason was attributed to the expertise of the readers who,as they read the code, were simulating its execution and wereable to detect many kinds of errors.

• Other techniques commonly used are walkthroughs,inspections and reviews.

• These tasks occur in interactive meetings attended by a teamwhich usually includes at least one member from thedevelopment group. Other members may belong to thedevelopment group or to other groups involved in softwaredevelopment.

• The duration of these meetings is usually no more than a fewhours in which code is examined on a line-by-line basis. Inthese dynamic sessions, it may be difficult to examine the codethoroughly for control logic, data flow, database errors, sizing,timing and other features which may require considerablemanual or automated effort. Advance preparation for theseactivities may be necessary and includes code analysis techniques.

• The results of these techniques provide appropriate engineeringinformation for discussion at meetings where code is evaluated.

66

• Regardless of who conducts or participates in walkthroughsand inspections, software V&V analyses may be used tosupport these meetings.

• A comprehensive test management approach to testingrecognizes the differences in strategies and in objectives forunit, software integration, and software system test.

• Unit test verifies the design and implementation of softwareunits. Software integration test verifies functional requirementsas the software units are integrated.

• Special attention is focused on software, hardware, and operatorinterfaces. Software system test validates the entire softwareprogram against system requirements and software performanceobjectives. Software system tests validate that the softwareexecutes correctly within its stated operating environment.

• The software’s ability to deal properly with anomalies and stressconditions is emphasized.

• These tests are not intended to duplicate or replace the user anddevelopment group’s test responsibilities, but insteadsupplement the development testing to test behavior notnormally tested by the user or development group.

• Effective testing requires a comprehensive understanding ofthe system. Such understanding develops from systematicallyanalyzing the software’s concept, requirements, design, andcode.

• By knowing internal software details, software V&V testing iseffective at probing for errors and weaknesses that reveal hiddenfaults.

• This is considered structural, or white-box, testing. It oftenfinds errors for which some functional, or black-box, test casescan produce the correct output despite internal errors.

• Functional test cases execute part or all of the system to validatethat the user requirement is satisfied; these test cases cannotalways detect internal errors that will occur under specialcircumstances.

• Another software V&V test technique is to develop test casesthat violate software requirements.

• This approach is effective at uncovering basic design assumptionerrors and unusual operational use errors.

• The process of planning functional test cases requires athorough examination of the functional requirements.

• An analyst who carefully develops those test cases is likely todetect errors and omissions in the software requirements.

• In this sense test planning can be effective in detecting errorsand can contribute to uncovering some errors before testexecution.

• The planning process for testing must take into account thespecific objectives of the software V&V for the software andthe impact of different test strategies in satisfying theseobjectives.

• Frequently, the most effective strategy may be to combine twoor more strategies.

• Criticality analysis may be used to identify software V&Vtechniques to address high-risk concerns.

• The selection of V&V techniques for use on each critical area ofthe program is a method of tailoring the intensity of thesoftware V&V against the type of risk present in each area ofthe software.

• For example, software V&V would apply algorithm analysis tocritical numerical software functions, and techniques such assizing and timing analysis, data and control flow analysis andinterface analysis to real-time executive functions.

Descriptions of Techniques The following are summarydescriptions of techniques taken from [BAHILL], [BEN],[EWICS3], [KIRANI], [NBS93], [NGUYEN], [NIST209],[NIST5589], [NUREG6316], [OKEEFE], [OLEARY],[TURING], [VOAS91,92,95], [WALLACE94], and [WILEY].Algorithm analysis examines the logic and accuracy of the softwarerequirements by translating algorithms into some language orstructured format. The analysis involves rederiving equations orevaluating the suitability of specific numerical techniques. It checksthat algorithms are correct, appropriate, stable, and meet all accuracy,timing, and sizing requirements. Algorithm analysis examinesthe correctness of the equations and numerical techniques,truncation and rounding effects, numerical precision of wordstorage and variables (single vs. extended-precision arithmetic),and data typing influences. Issues: accuracy; algorithm efficiency;correctness; consistency in computation; error propagation;numerical roundoff; numerical stability; space utilizationevaluation; system performance prediction; timing.Analytic modeling provides performance evaluation and capacityplanning information on software design. It represents theprogram logic and processing of some kind of model and analyzesit for sufficiency. Issues: accuracy; algorithm efficiency; bottlenecks;error propagation; feasibility; modeling; numerical roundoff;numerical stability; processing efficiency; system performanceprediction.Back-to-back testing detects test failures by comparing the outputof two or more programs implemented to the same specification.The same input data is applied to two or more program versionsand their outputs are compared to detect anomalies. Any test dataselection strategy can be used for this type of testing, althoughrandom testing is well suited to this approach. Also known ascomparison testing. Issues: anomalies or discrepancies betweenversions.Boundary value analysis detects and removes errors occurring atparameter limits or boundaries. The input domain of the programis divided into a number of input classes. The tests should coverthe boundaries and extremes of the classes. The tests check thatthe boundaries of the input domain of the specification coincidewith those in the program. The value zero, whether used directlyor indirectly, should be used with special attention (e.g., divisionby zero, null matrix, zero table entry). Usually, boundary values ofthe input produce boundary values for the output. Test casesshould also be designed to force the output to its extreme values.If possible, a test case which causes output to exceed the specificationboundary values should be specified. If output is a sequence ofdata, special attention should be given to the first and last elementsand to lists containing zero, one, and two elements. Issues:algorithm analysis; array size; inconsistencies between limits;specification error.

67

Code reading involves an expert reading through anotherprogrammer’s code to detect errors. The individual is likely toperform a pseudo-execution (mentally) of the code to pick uperrors before compilation. Issues: correctness; misuse of variables;omitted functions; parameter checking; poor programmingpractices; redundancy.Control flow analysis transforms text describing softwarerequirements into graphic flows where they can be examined forcorrectness. It checks that the proposed control flow is free ofproblems (e.g., unreachable or incorrect software design). Controlflow analysis is used to show the hierarchy of main routines andtheir subfunctions and checks that the proposed control flow isfree of problems (e.g., unreachable or incorrect code elements). Itdetects poor and potentially incorrect program structures. Issues:assertion testing/violations; bottlenecks; boundary test cases;branch and path identification; branch testing; cell structure ofunits; correctness; software design evaluation; error propagation;expected vs. actual results; file sequence error; formal specificationevaluation; global information flow and consistency; hierarchicalinterrelationship of units; inaccessible code; software integrationtests; inter-unit structure; loop invariants; path testing; processingefficiency; retest after change; system performance prediction; testcase preparation; unit tests.Coverage analysis measures how much of the structure of a unitor system has been exercised by a given set of tests. System levelcoverage measures how many of the unit parts of the systemhave been called by a test set. Code coverage measures thepercentage of statements, branches, or lines of code (LOC) exercisedby a test set. Issues: unit tests, software integration tests, softwaresystem tests.Critical timing/flow analysis checks that the process and controltiming requirements are satisfied by modeling those aspects ofthe software design. Issues: modeling; synchronization; timing.Database analysis ensures that the database structure and accessmethods are compatible with the logical design. It is performedon programs with significant data storage to ensure that commondata and variable regions are used consistently between all callingroutines; that data integrity is enforced and no data or variable canbe accidentally overwritten by overflowing data tables; and thatdata typing and use are consistent throughout the program. Issues:access protection; data characteristics and types; software designevaluation; file sequence error; global information flow; processingefficiency; space utilization evaluation; unit tests.Data flow analysis is important for designing the high level(process) architecture of applications. It can check for variablesthat are read before they are written, written more than oncewithout being read, and written but never read. Issues: assertiontesting/violations; bottlenecks; boundary test cases; branch andpath identification; branch testing; cell structure of units; datacharacteristics; environment interaction; error propagation;evaluation of program paths; expected vs actual results; file sequenceerror; global information flow and consistency; hierarchicalinterrelationship of units; inter-unit structure; loop invariants;processing efficiency; retest after changes; software designevaluation; software integration tests; system performanceprediction; test case preparation; uninitialized variables; unusedvariables; variable references.

Decision (truth) tables provide a clear and coherent analysis ofcomplex logical combinations and relationships. This methoduses two-dimensional tables to concisely describe logicalrelationships between boolean program variables. Issues: logicerrors.Desk checking involves the examination of the software design orcode by an individual, usually an expert other than the author, forobvious errors. It can include looking over the code for obviousdefects, checking for correct procedure interfaces, reading thecomments to develop a sense of what the code does and thencomparing it to its external specifications, comparing commentsto software design documentation, stepping through with inputconditions contrived to “exercise” all paths including those notdirectly related to the external specifications, and checking forcompliance with programming standards and conventions. Issues:anachronistic data; calls to subprograms that do not exist; datafields unconstrained by data boundaries; failure to implement thedesign; failure to save or restore registers; improper nesting ofloops and branches; improper program linkages; impropersequencing of processes; incomplete predicates; incorrect access ofarray components; inefficient data transport; infinite loops;initialization faults; input-output faults; instruction modification;inverted predicates; mismatched parameter lists; missing labels orcode; missing validity tests; misuse of variables; prodigalprogramming; unauthorized recursion; undeclared variables;unreachable code; unreferenced labels.

ReviewSoftware Installation techniqueSoftware operation & Maintenance Verification andValidation PhaseStrategies for checking techniques.]Various Techniques

QuestionsExplain about Software Installation technique12345Explain about operation and maintenance V&V.12345Explain about software V&V techniques.12345

68

Discuss the various types of techniques used in V&V.12345
















Notes

69


Topics coveredSoftware V&V Techniques

ObjectivesUpon completion of this Lesson, you should be able to:

Explain about Various techniques used in V& V also relate withthe various phases in SDLC.

Software V&V TechniquesError seeding determines whether a set of test cases is adequateby inserting ( seeding ) known error types into the program andexecuting it with the test cases. If only some of the seeded errorsare found, the test case set is not adequate. The ratio of foundseeded errors to the total number of seeded errors is an estimationof the ratio of found real errors to total number of errors, orNumber Seeded Errors Found Number Real Errors Found

—————————— = ——————————Total Number Seeded Errors Total Number Real ErrorsOne can solve for the total number of real errors, since the valuesof the other three are known. Then, one can estimate the numberof errors remaining by subtracting the number of real errors foundfrom the total number of real errors. The remaining test effort canthen be estimated. If all the seeded errors are found, this indicatesthat either the test case set is adequate, or that the seeded errorswere too easy to find. Issues: test case adequacy.Event tree analysis uses a bottom-up approach to model theeffects of an event that may have serious repercussions. Theinitiating event is the root of the event tree. Two lines are drawnfrom the root, depicting the positive and negative consequencesof the event. This is done for each subsequent consequence untilall consequences are considered. Issues: hazard analysis; safety;threat analysis; timing.Finite state machines (FSM) check for incomplete andinconsistent software requirements by modeling the software interms of its states, inputs and actions. For example, a system is instate S1, receives an input I, then carries out action A, and movesto state S2. FSMs can check that there is an action and new state forevery input in every state, and that only one state change is definedfor each state and input pair. Issues: incomplete softwarerequirements specification; inconsistent software requirements;modeling.Functional testing executes part or all of the system to validatethat the user requirement is satisfied. Issues: boundary test cases;branch and path identification; branch testing; file sequence error;path testing; program execution characteristics; retest after change;statement coverage testing; system performance prediction;software system tests; test case preparation; test thoroughness;unit test; uninitialized variables; unused variables; variablereferences; variable snapshots/tracing.

Inspections are evaluation techniques whereby the softwarerequirements, software design, or code are examined by a personor group other than the author to detect faults, violations ofdevelopment standards, and other problems. An inspectionbegins with the distribution of the item to be inspected (e.g., aspecification). Each participant is required to analyze the item onhis own. During the inspection, which is a monitored meeting ofall the participants, the item is jointly analyzed to find as manyerrors as possible. All errors found are recorded, but no attempt ismade to correct the errors at that time. However, at some point inthe future, it must be verified that the errors found have actuallybeen corrected. Issues: accuracy; checklists (software requirements,software design, code); effective forerunners to testing; formalspecification evaluation; go-no-go decisions; information flowconsistency; logic errors; loop invariants; manual simulation; retestafter change; space utilization evaluation; technical reviews; statusreviews; syntax errors; uninitialized variables; unused variables .Interface analysis is a static analysis technique. It is used todemonstrate that the interfaces of subprograms do not containany errors that lead to failures in a particular application of thesoftware. Interface analysis is especially important if interfaces donot contain assertions that detect incorrect parameter values. It isalso important after new configurations of pre-existingsubprograms have been generated. The types of interfaces that areanalyzed include external, internal, hardware/hardware, software/software, software/hardware, and software/database. Issues:actual and formal parameters mismatch; inconsistencies betweensubroutine usage list and called subroutine; inconsistency ofattributes of global variables; inconsistency between COTSparameter usage relative to other system parameters; incorrectassumptions about static and dynamic storage of values; incorrectfunctions used or incorrect subroutine called; input-outputdescription errors.Interface testing is a dynamic analysis technique. Similar tointerface analysis, except test cases are built with data that tests allinterfaces. Interface testing may include the following: testing allinterface variables at their extreme positions; testing interfacevariables individually at their extreme values with other interfacevariables at normal values; testing all values of the domain ofeach interface variable with other interface variables at normal values;testing all values of all variables in combination (may be feasibleonly for small interfaces). Issues: actual and formal parametersmismatch; inconsistencies between subroutine usage list and calledsubroutine; inconsistency of attributes of global variables;inconsistency between COTS parameter usage relative to othersystem parameters; inconsistent interface parameters; incorrectassumptions about static and dynamic storage of values; functionsused or incorrect subroutine called; input-output description errors.Mutation analysis determines the thoroughness with which aprogram has been tested, and in the process, detects errors. Thisprocedure involves producing a large set of versions or

70

“mutations” of the original program, each derived by altering asingle element of the program (e.g., changing an operator, variable,or constant). Each mutant is then tested with a given collection oftest data sets. Since each mutant is essentially different from theoriginal, the testing should demonstrate that each is in factdifferent. If each of the outputs produced by the mutants differfrom the output produced by the original program and from eachother, then the program is considered adequately tested and correct.Issues: boundary test cases; branch and path identification; branchtesting; retest after change; test case preparation.Performance testing measures how well the software systemexecutes according to its required response times, CPU usage, andother quantified features in operation. measurements may besimple to make (e.g., measuring process time relative to volumesof input data) or more complicated (e.g., instrumenting the codeto measure time per function execution). Issues: memoryallocation; synchronization; timing.Petri-nets model systems to assure software design adequacy forcatastrophic-failure and other safety problems. The system(including software systems) is modeled using conditions andevents represented by state transition diagrams. Petri-nets consistof places (conditions—represented by circles), transitions(events—represented by bars), inputs (pre-conditions—represented by arrows originating from places and terminating attransitions), outputs (post-conditions—represented by arrowsoriginating from transitions and terminating at places), and tokens(indication of true condition—represented by dots). Petri-netscan be “executed” to see how the software design will actuallywork under certain conditions. Specifically, Petri-nets can be usedto determine all the states (including hazardous states) the systemcan reach, given an initial condition. Issues: hazard analysis;modeling; safety; threat analysis; timing.Proof of correctness (formal verification) involves the use oftheoretical and mathematical models to prove the correctness of aprogram without executing it. Using this method, the program isrepresented by a theorem and is proved with first-order predicatecalculus. Issues: correctness; proof of critical sections.Prototyping helps to examine the probable results ofimplementing software requirements. Examination of a prototypemay help to identify incomplete or incorrect software requirementsand may also reveal if any software requirements will not result indesired system behavior. It can be used as an aid in examining thesoftware design architecture in general or a specific set of functions.For large complicated systems prototyping can preventinappropriate software designs from resulting in costly, wastedimplementations. Issues: behavior; omitted functions (fromsoftware requirements); incomplete software requirementsspecification; user interface.Regression analysis and testing is used to reevaluate softwarerequirements and software design issues whenever any significantcode change is made. It involves retesting to verify that the modifiedsoftware still meets its specified requirements. This analysis ensuresawareness of the original system requirements. It is performedwhen any changes to the product are made during installation toverify that the basic software requirements and software designassumptions affecting other areas of the program have not been

violated. Issues: software integration tests; retest after change;software system tests; unit tests.Requirements parsing involves examination to ensure that eachsoftware requirement is defined unambiguously by a complete setof attributes (e.g., initiator of an action, source of the action, theaction, the object of the action, constraints). Issues: accuracy;assertion testing/violations; checklists; completeness; consistency;environment interaction; feasibility; formal specification evaluation;hierarchical interrelationship of units; information flow consistency;software integration tests; inter-unit structure; path testing; proofof correctness; software requirements evaluation; softwarerequirements indexing; software requirements to design correlation;retest after change; standards check; statement coverage testing;software system tests; unit tests.Reviews are meetings at which the software requirements, softwaredesign, code, or other products are presented to the user, sponsor,or other interested parties for comment and approval, often as aprerequisite for concluding a given activity of the softwaredevelopment process. Reviews check the adequacy of the softwarerequirements and software design according to a set of criteria andprocedures. Issues: effective forerunners to testing; logic errors;syntax errors.Sensitivity analysis is a prediction of the probability that asoftware testing scheme will make programmer faults observableduring testing. It allows different testing strategies to be ranked,compared, and evaluated. Sensitivity analysis is useful for assessingwhich regions of code are most likely to be affected during softwaremaintenance (code modifications). It can be twisted into anassessment of how fault-tolerant a program is to softwareprogrammer faults (logic errors). Issues: correctness; logic errors;reliability; test case adequacy.Simulation is used to evaluate the interactions of large, complexsystems with many hardware, user, and other interfacing softwareunits. Simulation uses an executable model to examine the behaviorof the software. Simulation is used to test operator proceduresand to isolate installation problems. Issues: assertion testing/violations; behavior; boundary test cases; branch and pathidentification; branch testing; environment interaction; executionmonitoring, sampling, support; feasibility; file sequence error; inter-unit structure; path testing; program execution characteristics; retestafter change; statement coverage testing; system performanceprediction; software system tests; uninitialized variables; unusedvariables; variable references; variable snapshot/tracing.Sizing and timing analysis is useful for determining thatallocations for hardware and software are made appropriately forthe software design architecture. It is performed duringincremental code development by obtaining program sizing andexecution timing values to determine if the program will satisfyprocessor size and performance requirements allocated to thesoftware. Significant deviations between actual and predicted valuesis a possible indication of problems or the need for additionalexamination. Issues: algorithm efficiency; bottlenecks; boundarytest cases; branch and path identification; branch testing; softwareintegration tests; processing efficiency; program executioncharacteristics; retest after change; space utilization evaluation;software system tests; timing; unit tests.

71

Slicing is a program decomposition technique used to trace anoutput variable back through the code to identify all codestatements relevant to a computation in the program. Thistechnique may be useful to demonstrate functional diversity.Issues: allocation of V&V resources; common code; informationflow consistency; program decomposition; variable references .Software failure mode, effects and criticality analysis revealsweak or missing software requirements by using inductivereasoning to determine the effect on the system of a unit (includessoftware instructions) failing in a particular failure mode. A matrixis developed for each unit depicting the effect on the system ofeach unit’s failure in each failure mode. Items in the matrix mayinclude the failure mode and causes, effect on system, criticality,change/action required, and prevention and control safeguards.The criticality factor, that is, the seriousness of the effect of thefailure, can be used in determining where to apply other analysesand testing resources. Issues: hazard analysis; safety; incompletesoftware requirements specification; threat analysis.Software fault tree analysis identifies and analyzes software safetyrequirements. It is used to determine possible causes of knownhazards. Its purpose is to demonstrate that the software will notcause a system to reach an unsafe state, and to discover whatenvironmental conditions would allow the system to reach anunsafe state. The analyst assumes that an already identified hazardhas occurred and then works backward to discover the possiblecauses of the hazard. This is done by creating a fault tree, whoseroot is the hazard. The system fault tree is expanded until it containsat its lowest level basic events which cannot be further analyzed.Issues: hazard analysis; safety; threat analysis.Stress testing tests the response of the system to extremeconditions to identify vulnerable points within the software, andto show that the system can withstand normal workloads. Issues:design errors; planning for defaults when system over-stressed.Structural testing examines the logic of the units and may beused to support software requirements for test coverage, i.e., howmuch of the program has been executed. Issues: bottlenecks;error propagation; evaluation of program paths; parameterchecking; program execution characteristics; retest after change.Symbolic execution shows the agreement between the sourcecode and the software requirements specification. This is anevaluation technique in which program execution is simulatedusing symbols rather than actual values for input data, andprogram output is expressed as logical or mathematical expressionsinvolving these symbols. Issues: assertion testing/violations;program execution characteristics; proof of correctness; retest afterchange.Test certification ensures that reported test results are the actualfinding of the tests. Test related tools, media, and documentationare certified to ensure maintainability and repeatability of tests.This technique is also used to show that the delivered softwareproduct is identical to the software product that was subjected toV&V. It is used, particularly in critical software systems, to verifythat the required tests have been executed and that the deliveredsoftware product is identical to the product subjected to softwareV&V. Issues: incorrect product version shipped; incorrect testresults; reports on test cases that were omitted.

Walkthroughs are similar to reviews, but less formal and muchmore detailed. A walkthrough is an evaluation technique inwhich a designer or programmer leads one or more othermembers of the development team through a segment ofsoftware design or code, while the other members ask questionsand make comments about technique, style, and identifypossible errors, violations of development standards, and otherproblems. Issues: checklists; error propagation; effectiveforerunners to testing; formal specification evaluation; go-no-go decisions; logic errors; manual simulation; parameterchecking; retest after change; small, but difficult, or error-pronesections of design or code; status reviews; syntax errors; softwaresystem tests; technical reviews.

Reuse-SpecificMost V&V techniques are applicable to reused software. Guidancein section 3 provides suggestions on issues to be considered fordeciding to reuse the software; these issues may require applicationof V&V techniques. The two techniques identified in this sectionare crucial.• — Consistency analysis compares the requirements of any

existing software with the new software requirements to ensureconsistency.Issues: consistency.

• — Interface analysis (see interface analysis and interface testingabove) is especially important to exercise interfaces of reusedsoftware to other parts of the system as part of the planningfor the reused software, to ensure correct adaption of the reusedcode to possible differences in the software architecture,operating environment, and application domain from itsoriginal usage.

KBS-Specific Techniques• — Alternative model compares the domain model

implemented in the KBS to an alternate domain model forcompleteness and accuracy.

• — Control groups can be used during testing to compareperformance on executing a given task with or without theKBS available.

• — Credibility analysis compares the results of the system toknown expert s answers and reasoning to the same cases andjudges the credibility of the system.

• — Field testing is used only for low risk applications. It placesthe KBS in actual use and records the results of that use.

• — Illegal attribute testing checks rules against constraintsfor illegal attribute values. This as an effective method foreliminating bugs during the implementation process of KBSdevelopment.

• — Logical verification is the verification of the expert sknowledge for completeness, consistency, etc., as the domainmodel for the knowledge base system is being built.

• — Meta models compare the knowledge and rules to domainmeta models.

• — Partition testing selects test cases using partitions of theinput and output space as criteria and checks if the specificationaddresses those cases. This as an effective method foreliminating bugs during the requirements, design, andimplementation processes of KBS development.

72

• — Rule verification checks for completeness, subsumed/redundant rules, inconsistent rules, dead end rules, circularrules, unreachable conclusions, etc.

• — Statistical validation examines how frequently a KBS usesrules or clusters of rules int he knowledge base. If there areexpectations about the frequency of use expected for somerules then statics on rules use can be useful.

• — Turing tests compare performance of the system againstthat of an expert in blind trials.

• — Weight analysis compares the statistical informationassociated with a rule to statics known about the domain.

Software V&V Techniques

TECHNIQUE REQ DESIGN CODE UNIT INTEGR SYSTEM INSTALL OPER MAINT

Algorithm

Analysis

Analytic

Modeling

Back-to-Back

Testing

Boundary Value

Analysis

Code Reading

Control Flow

Analysis

Coverage

Analysis

Critical

Timing/Flow

Analysis

Database

Analysis

Data Flow

Analysis

Decision

(Truth) Tables

Desk Checking

Error Seeding

Event Tree

Analysis

Finite State

Machines

Functional

Testing

Inspections

Interface

Analysis

Interface

Testing

Mutation

Analysis

73

Table 3-1. Software V&V Techniques (continued)

TECHNIQ

UE

RE

Q

DESIG

N

COD

E

UNI

T

INTEG

R

SYSTE

M

INSTAL

L

OPE

R

MAIN

T

Regression

Analysis and

Testing

Requirments

Parsing

Reviews

Sensitivity

Ana lysis

Simulation

Sizing and

Timing

Analysis

slicing

Software

Fault Tree

Analysis

Stress Testing

Structural

Testing

Symbolic

Execution

Test

Certification

Walkthroughs

Review

TechniqueAlgorithm AnalysisAnalytic ModelingBack-to-Back TestingBoundary Value AnalysisCode ReadingControl Flow AnalysisCoverage AnalysisCritical Timing/Flow AnalysisDatabase AnalysisData Flow AnalysisDecision (Truth) TablesDesk CheckingError SeedingEvent Tree AnalysisFinite State MachinesFunctional TestingInspectionsInterface AnalysisInterface TestingMutation AnalysisPerformance TestingPetri-NetsProof of CorrectnessPrototyping

QuestionsExplain about various techniques used in V& V

12345Relate the phases of SDLC with the techniques12345
















74

LESSON 17 :EVALUATION OF MODELS

Topics coveredEvaluation of models

ObjectivesUpon completion of this Lesson, you should be

able to:

• Evaluate various alternatives when planning systemsdevelopment and acquisition

• Explain the advantages and disadvantages of in-housedevelopment versus purchasing a software package

• List the steps in purchasing and evaluating a software package• Explain the differences between a request for proposal (RFP)

and a request for quotation (RFQ)• Describe the contents of the system requirements document

and explain its purpose• Explain the prototyping process and describe a typical

situation where prototyping is used• Describe computer-aided software engineering (CASE) tools

and explain how they are used during the systemsdevelopment life cycle

• Explain how systems flowcharts and state-transition diagramsare used

Comparison of a chosen modelEvaluating Software Alternatives (Checking)

• Make or buy decision• In-house software• Developed by the company’s IS department• Software package• Purchased or leased from software publishers or vendors• Horizontal application• Vertical application• Developing software in-house• Reasons for in-house development• Satisfy unique requirements• Minimize changes in business procedures and policies• Meet constraints of existing systems• Meet constraints of existing technology• Develop internal resources and capabilities• Buying a software package• Reasons for buying a software package• Lower costs• Requires less time to implement• Proven reliability and performance benchmarks• Implemented by other companies

• Requires less technical development staff• Future upgrades provided by the vendor• Customizing software packages• Purchase a basic package that can be customized to suit your

needs• Negotiate with software vendor to make enhancements to suit

your needs• Purchase the package and make your own modifications• Other software alternatives• Outsourcing• End-user systems• Enterprise computing• Outsourcing• Using outside companies to handle part of the workload, on

short-term or long-term basis• Contract personnel firms• Systems management or facilities management firms• End-user systems• Major factor in systems planning and development• Applications can be managed by end-users• End-user systems• Major factor in systems planning and development• Applications can be managed by end-users• Software suites offer integrated applications• Interactive Help features include wizards• Security concerns might require read-only files• Information centers (IC) can support end-user systems• Enterprise computing• Overall information management strategy• Key is effective integration of information resources• Many systems involve client/server architecture

Selecting a software alternative• Decision will affect remaining SDLC phases• Systems analyst’s involvement depends on which alternative is

selected

Five step process

1. Evaluate the information system requirements2. Identify potential software vendors3. Evaluate software package alternatives4. Make the purchase5. Install the software package.

75

Steps in Evaluating and PurchasingSoftware Packages

Step 1: evaluate the information systemrequirements

• Identify the key features of the system• Estimate volume and future growth• Specify any hardware constraints• Prepare a request for proposal or quotation

Step 2: identify potential software vendors

• Next step is to contact potential vendors• An RFP will help vendors to identify solutions• Various sources of information on suppliers• Retailers• Computer manufacturers• Industry trade journals• Systems consultants

Step 3: evaluate software package alternatives• Object is to compare software packages and select the best

alternative• Obtain information from many sources• Vendor presentations and literature• Object is to compare software packages and select the best

alternative• Obtain information from many sources• Vendor presentations and literature• Product documentation• Trade publications• Companies that perform software testing/evaluation• Object is to compare software packages and select the best

alternative• Obtain information from many sources• Vendor presentations and literature• Product documentation• Trade publications• Companies that perform software testing/evaluation• Contact users of the package• Benchmark test

Step 4: make the purchase

• Software licenses• Lease agreements• Maintenance agreements

Step 5: install the software package

• Installation time depends on size and complexity• Before using the package, complete all implementation steps• Loading, configuring, and testing the software• Training users• Converting data files to new format

• Hardware Alternatives• Hardware decisions use the same five-step approach as software

decisions• Evaluate system requirements• Identify potential hardware vendors• Evaluate hardware alternatives• Make the purchase• Install the hardware• Other issues to consider• Turnkey systems• Site preparation• New workstations• Network cabling• Raised floors• Conditioned electrical lines• Fire extinguishing equipment• Uninterruptible power supplies (UPSs)• How do you select the best alternative?• Most companies combine• In-house developed software• Software packages• Outsourcing• End-user systems• Object is to develop a list of viable alternatives• All viable alternatives must be evaluated• Feedback from users is essential• How do you select the best alternative?

Prototyping

Prototyping Model

• Rapid prototyping assumes that ‘real’ requirements exist andby iterating through the tasks they can be determined.

• Evolutionary prototyping assumes that the projectrequirements will be subject to continuous change.

76

• Evolutionary prototyping a series of fully functioning completesystems with each successive system the new requirements areincorporated.

Findings on PrototypingPrototyping seems appropriate for

1. Data-oriented applications2. Applications with emphasis on the user interface3. Applications which are highly interactive• Boehm (1984), as reported in Vliet (p. 37), had seven groups

develop a system.• Three groups took the traditional approach (waterfall) in which

the requirements were written prior to subsequent activity.• Four groups used an evolutionary prototyping strategy. The

findings were:1 Prototyping took 40% less time and resulted in 45% less code2 The traditional approach resulted in a more robust product

which was expected to be easier to maintain.• Alavi (1984), as reported in Vliet (p. 38), reports that users were

more positive about the systems developed using theprototyping approach. The positive attitude concerns both theprocess and the product.

• Users felt more involved and had fewer conflicts with thedesigners. Designers had some difficulty with changingrequirements and controlling the development process.

Rad Model

• The RAD (Rapid Application Development) model is a highspeed version of the waterfall model.

• The emphasis is on short development cycle. Shortdevelopment cycle is achieved by using component-basedconstruction.

• Typical use for RAD development is for information systems.• Business Modeling• Data Modeling• Process Modeling• Application Generation• Testing and Turnover

Evolutionary Models

Incremental Model

SpiralModel

The spiral model attempts to encompass the best features ofboth the prototyping and phased lifecycle models. The spiral modeladds a new element, risk analysis.1. Planning - determination of objectives, alternatives, and

constraints.2. Risk Analysis - analysis of alternatives and identification/

resolution of risks

77

Review throughIterative process

3. Engineering - Development of the “next-level” product4. Customer Evaluation - assessment of the results of engineering5. Risk Identification

Project Risksdifficulties associated with budget, schedule, personnel (staffingand organization), resources, customer

Technical RisksThese are those problems that arise because the problem is harderthan we thought.Technical uncertainty, technical obsolescenceDifficulties in interfacing, maintenance, design and implementation

Business Risks

1. Market risk (the product no one wants)2. Product line skew (product does not match product line)3. Can’t sell it because sales doesn’t understand it4. Management risk (change in physical management or focus)5. Budget risk (resource commitment)

Prototyping

• Prototyping is an engineering technique used to develop partial,but functional versions of a system or applications. Whenextended to system design and construction, a prototype canevolve into the final, implemented system.

• Two ‘flavors’ of prototyping are applicable to systems analysis:• Feasibility prototyping is used to test the feasibility of a specific

technology that might be applied to the business problem.• Discovery prototyping (sometimes called requirements

prototyping) is used to ‘discover’ the users’ businessrequirements by having them react to a ‘quick-and-dirty’implementation of those requirements.

As can be deducted from the discussion on system development,there are two major problems with building information systems:(1)The system development life cycle takes too long and(2)The right system is rarely developed the first time.• Lengthy development frustrates the user. Analysts seem to get

bogged down with tedious methodologies for developmentsystems. T

• The reason they often come up with the wrong system is thatthey expect users to define their information requirements.

• It usually turns out that what users ask for is not what theywant, and what they want is not what they need.

• An alternative to this “paralysis by analysis” is an advancedtechnique called prototyping.

• Prototyping recognizes problems of cognitive style and usesadvanced computer technology . It advocates building a simplesystem though trial and error and refining it through anditerative process.

• Neumann and Jenkins have conducted the most extensiveresearch on prototyping.

The basic steps are

1. Identify the user’s information and operating requirements.

Identify user requirements

AnalyzeprototypeInput, processing

Implementprototype

Finalconversion

Post -implementation

Maintenance

1. Develop a working prototype that focuses on only the mostimportant functions, using a basic database.

2. Allow the user to use the prototype, discuss requested changes,and implement the most important changes.

3. Repeat the next version of the prototype with further changesincorporated until the system fully meets user requirements.

• Prototyping and advanced system development techniques havebeen successful in a wide variety of applications.

• The benefits include shorter development time, more accurateuser requirements, and greater user participation and support.

ReviewEvaluating the alternative &StrategiesSelecting a software alternativePrototypingRADEvolutionary model, spiral model, Risk analysis

QuestionsExplain about prototyping.12345Discuss the RAD model.12345Differentiate between various models12345Explain about risk management123

78

4

5

Tangible Investments Corporation needs a new customer billingsystem. As project leader, you decided to create a prototype thatusers can evaluate before the final design is implemented. Youplan to use a traditional structured analysis methodology. Toprepare for your meeting with top management tomorrow youneed to review the following topics:(i) Explain the main purpose of prototyping(ii) Explain why prototypes might or might not evolve into the

final version of the system.(iii) list at least three advantages and disadvantages of prototyping.State the difference between System design and Detailed design.




Systems analysis and design methods5th ed. New Delhi : Galgotia Publications, 2001

Shelly, Gary B.Systems analysis and design




Modern systems analysis and design2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.Systems analysis, data processing andquantitative techniques




Notes

79

LESSON 18 :OBJECT BASED METHODS

Topics covered

Object oriented system Development

• Scope• Objects• Development Paradigms• Development Phases• Purpose• Models• Object in analysis• Classes• Attributes• Summary

ObjectivesUpon completion of this Lesson, you should be able to:Explain about object.Explain about the development phase with object based methods.Explain the purpose of object oriented system developmentExplain about classes and attributes

Scope

• The development of a software system is usually just a part offinding a solution to a larger problem.

• The larger problem may entail the development of an overallsystem involving software, hardware, procedures, andorganizations.

• I do not address associated issues such as constructing theproper hardware platform and reorganizing institutionalprocedures that use the software to improve overall operations.

• I further limit us to the “middle” phases of OO systemdevelopment. I discuss the initial collection of systemrequirements and scheduling of efforts only to the extent towhich they impact analysis. Similarly, I discuss situation-dependent implementation matters such as programming inparticular languages, porting to different systems, andperforming release management only with respect to generaldesign issues. Also, while I devote considerable attention tothe process of OO development, I do not often address themanagement of this or any software development process.

• The context of any system is simply that part of the “world”with which it directly interacts. In order to describe the behaviorof a target system, I have to describe relevant parts of theimmediate context forming the boundary of the system.

Running Example

• Ø Many examples in this course pack describe parts of thefollowing system of automated teller machines (ATMs):

• I assume that the American Bank (AB) has partly decentralizedaccount management. Every branch office has equipment tomaintain the accounts of its clients. All equipment is networkedtogether.

• Each ATM is associated and connected with the equipment ofa particular branch office. Clients can have checking, savings andline of credit accounts, all conveniently interconnected.

• Clients can obtain cash out of any of their accounts. A clientwith a personal identification number (PIN) can use an ATMto transfer funds among attached accounts. I will expand onthese requirements as necessary. For presentation reasons, Ioften revise descriptions from chapter to chapter. Our examplesrepresent only small fragments of any actual system.

Objects• Ø A frame represents a concept in multiple ways. There is a

descriptive as Ill as a behavioral component. A frame of arestaurant would have as a descriptive component itsprototypical features — being a business, having a location,employing waiters, and maintaining seating arrangements.

• Ø The behavioral component would have scripts. Forexample, a customer script outlines stereotypical events thatinvolve visiting a restaurant.

• Ø Objects and frames share the property that they bringdescriptive and behavioral features closely together. This sharedfeature, phrased from the programming angle, means that thestorage structures and the procedural components that operateon them are tightly coupled. The responsibilities of frames gobeyond those of objects. Frames are supposed to supportcomplex cognitive operations including reasoning, planning,natural language understanding and generation. In contrast,objects for software development are most often used forrealizing better understood operations.

• On the programming side, the Simula programming languageis another, even older, historical root of objects. Unsurprisingly,Simula was aimed at supporting simulation activities.Procedures could be attached to a type (a class in Simula’sterminology) to represent the behavior of an instance. Simulasupported parallelism , in the approximation of coroutines ,allowing for many interacting entities in a simulation.

• Simula objects share the close coupling of data and procedures.• The concurrency in Simula was lost in Smalltalk , Eiffel ,

Objective-C , C++ , and other popular OO programminglanguages. HoIver, parallelism has reentered the OO paradigmvia OO analysis methods and distributed designs. Modelingreality with “active” objects requires giving them a large degreeof autonomy.

• The notion of whether objects have a parallel connotation ornot is currently a major difference betIen OO analysis and OOprogramming. Since I expect OO programming languages to

80

evolve to support the implementation of distributed, parallelsystems, I expect this difference to decrease.

DefinitionsLike “system”, “software”, “analysis”, and “design”, the term

“object” evades simplistic definition. A typical dictionary definitionreads:• Object: a visible or tangible thing of relative stable form; a thing

that may be apprehended intellectually; a thing to which thoughtor action is directed ].

Samplings from the OO literature include:

• An object has identity, state and behavior (Booch]).• An object is a unit of structural and behavioral modularity that

has properties (Buhr )

Our own working definition will be refined throughoutthis Lesson. I define an object as a conceptual entitythat:

• Is identifiable;• Has features that span a local state space;• Has operations that can change the status of the system locally,

while also inducing operations in peer objects.

Development Paradigms

• The structured analysis (SA) paradigm is rooted in thirdgeneration programming languages including Algol , Fortran ,and COBOL .

• The procedure and function constructs in these languagesprovide for a poIrful abstraction mechanism. Complex behaviorcan be composed out of or decomposed into simpler units.

• The block structure of Algol-like languages provides syntacticsupport for arbitrary many layers. Applied to the developmentof systems, this abstraction mechanism gives prominence tobehavioral characterization. Behavior is repeatedly decomposedinto subcomponents until plausibly implementable behavioralunits are obtained.

• The starting point for process modeling resides in the requiredbehavior of the desired system.

• This makes SA a predominantly top-down method. Highlevel process descriptions are consequently target system specific,and thus unlikely to be reusable for even similar systems.

• As a result, a description (and a subsequent design andimplementation) is obtained that is by and large custom fit forthe task at hand.

• OO software development addresses the disadvantage ofcustom fitting a solution to a problem.

• At all levels of the development process, solution componentscan be formulated that generalize beyond the local needs and assuch become candidates for reuse (provided I are able to managethese components).

• Other aspects of OO development are available to control thecomplexity of a large system.

• An object maintains its own state. A history-dependentfunction or procedure can be realized much more cleanly andmore independently of its run-time environment than in

procedural languages. In addition, inheritance provides for anabstraction mechanism that permits factoring out redundancies.

Applicability

• Are the applicability ranges of the object-oriented paradigmand the structured paradigm different?

• If so, how are they related?• Is one contained in the other?• Can I describe their ranges?• As yet there is not enough evidence to claim that the applicability

ranges are different, although OO may have an edge fordistributed systems. Structured analysis thrives on processdecomposition and data flows.

• Can I identify a task domain where process decomposition isnot the right thing to do, but where objects can be easilyrecognized? Conversely, can I identify a task where I do notrecognize objects, but where process decomposition is natural?Both cases seem unlikely.

• Processes and objects go hand in hand when I see them asemphasizing the dynamic versus the static view of an underlying“behaving” substratum.

• The two paradigms differ in the sequence in which attention isgiven to the dynamic and static dimensions.

• Dynamics are emphasized in the structured paradigm and staticsare emphasized in the OO paradigm. As a corollary, top-downdecomposition is a strength for the SA approach, while thegrouping of declarative commonalities via inheritance is astrength for the OO approach.

Mixing ParadigmsThe software development community has a large investment instructured analysis and structured design (SD).The question has been raised repeatedly whether one can mix andmatch components from the structured development process withcomponents of the OO development process.For instance, whether the combination of SA + SD + OOP or SA+ OOD + OOP is a viable route.

Development MethodsWithin a given paradigm, one may follow a particular method. Amethod consists of:1. A notation with associated semantics.2. A procedure/pseudo-algorithm/recipe for applying the

notation.3. A criterion for measuring progress and deciding to terminate.

Footnote :I use the word method, not methodology. The primary meaning ofmethodology is “the study of methods” which is the business ofphilosophers. The secondary meaning of methodology is method.Since that is a shorter word I refrain from joining the methodologycrowd. (Similarly, I prefer using technique over technology.)• This Lesson does not introduce yet another new method for

OO development.• I instead attempt to integrate methods representative of the

OO paradigm. Our OO analysis notation is just borroId from

81

multiple sources. Still I have given it a name, OAN (OurAnalysis Notation), for easy referencing.

• When necessary to distinguish our views from those of others,I will refer to these simply as “our method” ( OM).

Development Phases• No author in the area of software development has resisted

denouncing the waterfall model . Everyone agrees that insightsobtained downstream may change decisions made upstreamand thus violate a simple sequential development algorithm.

• The notion of a development process in which one can backtrackat each point to any previous point has led to the fountainmetaphor (with, I assume, the requirements at the bottomand the target system at the top).

• Whether the development process has few feedback loops (thewaterfall model) or many (the fountain model) depends onseveral factors.

• The clarity of the initial requirements is an obvious factor. Theless I know initially about the desired target system, the moreI have to learn along the way and the more I will change ourminds, leading to backtracking.

• Another factor might be the integration level of tools thatsupport the development process.

• A highly integrated development environment encourages“wild” explorations, leading to more backtracking. On the otherhand without tool support, I may be forced to think moredeeply at each stage before moving on because backtrackingmay become too costly.

• It has been said that the object-oriented paradigm is changingthe classic distinctions betIen analysis, design andimplementation. In particular, it is suggested that the differencesbetIen these phases is decreasing, that the phases blur into eachother.

• People claim that the OO paradigm turns every programmerinto a designer, and every designer into an analyst. I are willingto go only part way with this view.

• There is empirical evidence from projects in which objectsidentified in the requirements phase carried all the way throughinto the implementation . On the other hand, intrinsicdifferences among phases cannot be forgotten.

• Analysis aims at clarifying what the task is all about and doesnot go into any problem solving activity. In contrast, designand implementation take the task specification as a given andthen work out the details of the solution.

• The analyst talks to the customer and subsequently (modulofountain iterations) delivers the result to the designer.

• The designer “talks”, via the implementor, with hardware thatwill ultimately execute the design. In a similar vein I do notwant to blur the difference betIen design and implementation.

• Contemporary OO programming languages have limitationsand idiosyncrasies that do not make them optimal thinkingmedia for many design tasks.

• It is, in our opinion, misleading to suggest that phasedifferences disappear in the OO paradigm. Objects in the

analysis realm differ significantly from objects in theimplementation phase.

• An analysis object is independent and autonomous.• HoIver, an object in an OO programming language usually

shares a single thread of control with many or all other objects.• Hence, the design phase plays a crucial role in bridging these

different computational object models.

Prototyping

• Prototyping and exploratory programming are common partsof OO analysis, design and implementation activities.

• Prototyping can play a role when aspects of a target systemcannot be described due to lack of insight. Often enough,people can easily decide what they do not want, but they cannotdescribe beyond some vague indications what is to be produced.

FootnoteI avoid the trendy phrase rapid prototyping since no one has yetadvocated slow prototyping.• Graphical user interfaces are an example. What makes a particular

layout on a screen acceptable?• Must a system keep control during human interaction by

offering menu choices or should control be relinquished sothat a user can provide unstructured input?

• These kinds of question are sometimes hard or impossible toanswer. Prototyping experimental layouts can help. The situationresembles that of an architect making a few sketches so that acustomer can formulate preferences.

• As long as the unknown part of the requirements is only afragment of a system, OO analysis cooperates with prototyping.Exploratory programming is called for when most of therequirements are not Ill understood. Research projects fall intothis category. Programming in artificial intelligence is an example.

• Problem solving by analogy is particularly murky behavior.Exploratory programming can be a vehicle for validating theoriesand/or for obtaining better conjectures.

• I feel that purely exploratory programming applies to anessentially different set of tasks than the more tractable(although possibly very large) tasks to which the methodsdescribed in this Lesson apply. Formulated negatively, themethods in this Lesson may not apply when the developmenttask is too simple or when the task is too hard.

• Elucidating functionality is just one of the motivations forprototyping. I have so far used “prototyping” primarily in thesense of “throwaway prototyping” — aimed at gatheringinsights — in contrast to “evolutionary prototyping” — aimedat implementing a system in stages. A prototyping activity mayhave both aims but they need not coincide ., I shall describe aframework for design prototyping that is explicitly evolutionaryin nature. Similarly, performance constraints may requireempirical evaluation via implementation-level prototyping.

Development Tools

82

• Acceptance of the fountain metaphor as the process model forsoftware development has profound ramifications. Beyondtoy tasks, tool support and integration of different tools isessential in enabling backtracking. Of course these tools alsoneed to support versioning, allow for traceability , and cater toteam development. These are quite stringent requirements,which are currently not yet satisfied. Various groups are workingon the standards to achieve tool control and data integration.Manipulating objects in all phases of the development processshould make it easier to construct an integrated developmentenvironment

Purpose of object oriented system development The analysis phase of object-oriented software development isan activity aimed at clarifying the requirements of an intendedsoftware system, with:

InputA fuzzy, minimal, possibly inconsistent target specification, userpolicy and project charter.

OutputUnderstanding, a complete, consistent description of essentialcharacteristics and behavior.

TechniquesStudy, brainstorming, interviewing, documenting.

Models Most attention in the analysis phase is given to an elaboration offunctional requirements. This is performed via the constructionof models describing objects, classes, relations, interactions, etc.

Declarative Modeling I quote from Alan DavisA Software Requirements Specification is a document containinga complete description of what the software will do withoutdescribing how it will do it.• Subsequently, he argues that this what/how distinction is less

obvious than it seems.• He suggests that in analogy to the saying “One person’s floor

is another person’s ceiling” I have “One person’s how is anotherperson’s what”. He gives examples of multiple what/howlayers that connect all the way from user needs to the code.

• I will follow a few steps of his reasoning using the singlerequirement from our ATM example that clients can obtaincash from any of their accounts.

1. Investigating the desired functionality from the user’s perspectivemay be seen as a definition of what the system will do.

The ability of clients to obtain cash is an example of functionalityspecified by the user.2. “The next step might be to define all possible systems ... that

could satisfy these needs. This step clearly defines how theseneeds might be satisfied. ...”

The requirements already exclude a human intermediary. Thus, Ican consider different techniques for human-machine interaction,for example screen and keyboard interaction, touch screeninteraction, audio and voice recognition. I can also consider differentauthentication techniques such as PIN, iris analysis, handlineanalysis. These considerations address the how dimension.

3.“On the other hand, I can define the set of all systems thatcould possibly satisfy user needs as a statement of what I wantour system to do without describing how the particular system... will behave.”

The suggestion to construct this set of all systems (and applybehavior abstraction?) strikes us as artificial for the presentdiscussion, although an enumeration of techniques may beimportant to facilitate a physical design decision.4. “The next step might be to define the exact behavior of the

actual software system to be built ... This step ... defines how thesystem behaves ...”

This is debatable and depends on the intended meaning of “exactbehavior”. If this refers to the mechanism of the intended systemthen I subscribe to the quotation. HoIver, it could also encompassthe removal of ambiguity by elaborating on the description ofthe customer-ATM interaction. If so, I still reside in what country.For example, I may want to exemplify that customer authenticationprecedes all transactions, that account selection is to be done forthose customers who own multiple accounts, etc.5. “On the other hand, I can define the external behavior of the

actual product ... as a statement of what the system will dowithout defining how it works internally.”

I may indeed be more specific by elaborating an interaction sequencewith: “A client can obtain cash from an ATM by doing thefollowing things: Obtaining proper access to the ATM, selectingone of his or her accounts when more than one owned, selectingthe cash dispense option, indicating the desired amount, andobtaining the delivered cash.” I can go further in our example bydetailing what it means to obtain proper access to an ATM, bystipulating that a bank card has to be inserted, and that a PIN hasto be entered after the system has asked for it.6. “The next step might be to define the constituent architectural

components of the software system. This step ... defines howthe system works internally ...”

Davis continues by arguing that one can define what thesecomponents do without describing how they work internally.• In spite of such attempts to blur how versus what, I feel that

these labels still provide a good initial demarcation of theanalysis versus the design phase.

• On the other hand, analysis methods (and not only OO analysismethods) do have a how flavor. This is a general consequence ofany modeling technique. Making a model of an intended systemis a constructive affair.

• A model of the dynamic dimension of the intended systemdescribes how that system behaves..

• The object-oriented paradigm puts another twist on thisdiscussion. OO analysis models are grounded in object modelsthat often retain their general form from analysis (via design)into an implementation. As a result, there is an illusion thatwhat and how get blurred (or even should be blurred). I disagreewith this fuzzification.

Ø I should also note that the use of models of any form isdebatable. A model often contains spurious elements that arenot strictly demanded to represent the requirements.

Objects in Analysis

83

OO analysis models center on objects. The definition of objectsgiven in. The bird’s eye view definition is that an object is aconceptual entity that:• Is identifiable;• Has features that span a local state space;• Has operations that can change the status of the system locally,

while also inducing operations in peer objects.Since I are staying away from solution construction in the analysisphase, the objects alloId in this stage are constrained. The outputof the analysis should make sense to the customer of the systemdevelopment activity. Thus I should insist that the objectscorrespond with customers’ notions, and add:• an object refers to a thing which is identifiable by the users of

the target system — either a tangible thing or a mental construct.Another ramification of avoiding solution construction pertainsto the object’s operator descriptions. I will stay away from proceduralcharacterizations in favor of declarative ones.

Active Objects

• Some OO analysis methods have made the distinction betIenactive and passive objects. For instance Colbert defines an objectas active if it “displays independent motive poIr”, while a passiveobject “acts only under the motivation of an active object”.

• I do not ascribe to these distinctions, at least at the analysislevel. Our definition of objects makes them all active, as far asI can tell. This active versus passive distinction seems to bemore relevant for the design phase

• This notion of objects being active is motivated by the need tofaithfully represent the autonomy of the entities in the “world”,the domain of interest.

• For example, people, cars, accounts, banks, transactions, etc.,are all behaving in a parallel, semi-independent fashion. Byproviding OO analysts with objects that have at least one threadof control, they have the means to stay close to a naturalrepresentation of the world. This should facilitate explanationsof the analysis output to a customer. HoIver, a price must bepaid for this.

• Objects in the programming realm deviate from thiscomputational model. They may share a single thread of controlin a module. Consequently, bridging this gap is a majorresponsibility of the design phase.

Four-Component View

• A representation of a system is based on a core vocabulary. Thefoundation of this vocabulary includes both static and dynamicdimensions.

• Each of these dimensions complements the other. Somethingbecomes significant as a result of how it behaves in interactionwith other things, while it is distinguished from those otherthings by more or less static features.

• This distinction between static and dynamic dimensions is oneof the axes that I use to distinguish the models used in analysis.

Our other main distinction refers to whether a model concentrateson a single object or whether interobject connections are addressed.The composition of these two axes give us the following matrix:

inside object betIen objects

staticattribute

constraint

relationship

acquaintanceship

dynamicstate net and/or

interface

interaction and/or

causal connection

• The static row includes a disguised version of entity-relationship (ER) modeling . ER modeling was initiallydeveloped for database design. Entities correspond to objects,and relations occur betIen objects.1 Entities are described usingattributes . Constraints capture limitations among attributevalue combinations.

• Acquaintanceships represent the static connections amonginteracting objects.

1Footnote:The terms “relation” and “relationship” are generallyinterchangeable. “Relationship” emphasizes the notion as a nounphrase.• The dynamic row indicates that some form of state machinery

is employed to describe the behavior of a prototypical elementof a class . Multiple versions of causal connections capture the“social” behavior of objects.

• Inheritance impacts all four cells by specifying relationshipsamong classes. Inheritance allows the construction of compactdescriptions by factoring out commonalities.

Other Model ComponentsThe four models form a core. Additional models are commonlyadded to give summary views and/or to highlight a particularperspective. The core models are usually represented in graphicnotations• For instance, a summary model in the static realm may remove

all attributes and relationship interconnections in a class graphto highlight inheritance structures. Alternatively, I may want toshow everything associated with a certain class C, for example,its attributes, relationships in which C plays a role, andinheritance links in which C plays a role.

Process

• Several factors prevent analysis from being performed accordingto a fixed regime. The input to the analysis phase varies notonly in completeness but also in precision.

• After factoring out these sources of variation, I may still wonderwhether there is an underlying “algorithm” for the analysisprocess. Investigation of current OO analysis methods revealsthat:

• The creators of a method usually express only a Iak preferencesfor the sequence in which models are developed.

• There is as yet no consensus about the process.• There appear to be two clusters of approaches: (1) Early

characterization of the static dimension by developing a

84

vocabulary in terms of classes, relations, etc. (2) Earlycharacterization of the behavioral dimension, the system-context interactions.

Classes

• Sometimes I need to talk about a particular instance in oursystem model. For example, a bank may maintain some key“system” accounts. I may want to describe a few specialemployees, e.g., the executive officers. Usually, hoIver, collectionsof objects, so-called classes 1 are described.

Footnote 1:The notions of “type” and “class” are sometimes distinguishedin the implementation realm. A type is the abstract characterizationof a particular “family” of objects, while a class is then the actualrealization in a particular programming language of that type. Iwill uniformly use the term “class”..• A class stands for a family of objects that have something in

common. A class is not to be equated with a set of objects,although at any moment I can consider the set of instancesthat belong to the class. A class may be seen as what all thesesets have in common. In technical terminology, a class standsfor the intension of a particular characterization of entities,while the set of objects that conform to such a characterizationin a certain period is known as the extension

• Notationally, a rectangle surrounds the name of a class. Forexample, the class Account is depicted as:

• An object is an instance of at least one and at most one class.Certain methods allow an object to change, during its lifetime,the class of which it is an instance. This freedom increases theexpressive poIr of the analysis method. But since most OOsoftware development methods and languages do not supportthis feature, and since the effects of change may be described byother means, I refrain from this practice.

• Individual objects are primarily characterized by an indicationof which class they belong. For example:

• The arrow between the instance and its class is called the ISArelationship. This instance characterization is insufficient. Atthis stage, I do not have available the means, beyond naming,to distinguish multiple instances of the class Account.

• In general, I avoid using names to describe individual objects,because usually objects do not have natural names. Just considerthe examples given earlier — a bank transaction, a newspaperstory, a phone call, a rental car contract, a utility bill, and anairline reservation. Instead, descriptions are used that somehowdenote unique entities. Attributes of objects will do thedescriptive job.

Attributes

• Real-life entities are often described with words that indicatestable features. Most physical objects have features such as shape,Light, color, and type of material. People have features includingdate of birth, parents, name, and eye color. A feature may beseen as a binary relation between a class and a certain domain.Eye color for example, may be seen as a binary relation betweenthe class of Eyes and an enumerated domain {brown, blue,yellow, green, red}. A domain can be a class as Ill, for example,in the case of the features parents, spouse, accountOwnedBy,etc.

• The applicability of certain features (i.e., the features themselves,not just their values) may change over time. For example, frogsand butterflies go through some drastic changes in their lifetime.I avoid this kind of flexibility. Thus, a class is characterized byits set of defining features, or attributes. This collection offeatures does not change. (I later present tricks for getting aroundthis limitation.)

• The notion of a (binary) relation crept into the previousdiscussion. The reader may wonder how I can discuss themhere since I have relegated them to another model in our four-component view. I make a distinction between attribute (binary)relationships that represent intrinsic, definitional properties ofan object versus relationships that describe contingent,incidental connections between objects. Because I, as analysts,are in control, I can prescribe for an object what is definitionaland what is incidental. For example, in a particular system Imay agree that for the class Person a social-security-number is adefining attribute while a parent feature is seen as an incidentalrelationship. In another system, the reverse choices could bemade.

I illustrate the notation for attributes with a class Account that has:• Attribute accountNumber of value domain AccountNumber

and• Attribute currency of value domain Currency.A graphical notation for these attribute names and attribute valuesis:

This representation indicates that AccountNumber is a “data value”domain and that Currency is a class. It is debatable whether Ishould make such a distinction betIen values and objects. Forinstance, one can take the stance that integers, strings, and 32-bitreals are all objects as Ill.. I use the convention that unboxed valuedomains do not represent classes. Consequently, if I change ourmind and represent the currency attribute as a data value, I wouldunbox it.

Attributes of Instances

85

• Attributes can be employed to describe an instance of a classby indicating how it “scores” with respect to the attributes. Inthe following example, I depict a particular instance of theclass Account:

Note that attribute names have been repeated in the instance. Analternative approach would use graphic notation to link up theattributes of the instance with the attributes in the class, as in:

Summary• Software systems are often components of general systems.

This Lesson discusses only object-oriented approaches todeveloping software systems. The roots of the OO paradigminclude AI frames and programming languages includingSimula.

• The structured paradigm focuses on decomposing behaviors.The OO paradigm focuses on objects, classes, and inheritance.The two paradigms do not mix Ill. While the OO paradigmtightly integrates the development phases of analysis, designand implementation, intrinsic differences betIen these phasesshould not be blurred. OO methods are compatible withprototyping efforts, especially those constructed in order toelucidate otherwise unknown requirement fragments.

• Purpose of object oriented system development• Models• Object in analysis• Classes• Attributes

Further Reading

• Standard non-OO texts include Ward and Mellor’s StructuredDevelopment for Real-Time Systems and Jackson’s Systems

Development]. OO texts that cover the full life cycle includeBooch’s Object Oriented Design with Applications andRumbaugh et al’s Object Oriented Modeling and Design .

• Yearly proceedings are available from the principal OOconferences, OOPSLA (held in the Istern hemisphere) andECOOP (Europe). Both originally focused on programmingand programming languages but have more recently broadenedtheir attention to the full life cycle.

QuestionsAnalysis aims at giving an unambiguous description of what atarget system is supposed to do. Enumerate the differences, ifany, of an analysis method for characterizing software systemsversus an analysis method for characterizing hospital systems, orany other nonsoftware system with which you are familiar.12345In general, prototyping may be seen as “disciplined” hacking thatexplores a narrow Ill defined problem. Would the throwawayconnotation of a produced artifact in this characterization changeas the result of an overall OO approach?1234

Discuss whether analysis, should be performed for the followingtasks:1. The planning for your next vacation.2. The repair of faulty software.3. The acquisition of your next car.4. The remodeling of your kitchen.5. The decision to get married.6. The reimplementation of an airline reservation systemto exploit five supercomputers.7. A comparative study of OO analysis methods.

12345Analysis is a popular notion. Mathematics, philosophy, psychiatry,and chemistry all have a claim on this concept. Is there any

86

commonality between these notions and the notion of analysisdeveloped in this lesson?12345Do you expect the following items to be addressed during OOanalysis?8. Maintainability.9. Quality.10. The development costs of the target system.11. The execution costs of the target system.12. The programming language(s) to be used.13. The reusability of existing system components.14. The architecture of the implementation.15. The relevance of existing frameworks.123456

References1 G. Booch. Object Oriented Design with Applications.

Benjamin/Cummings, 1990.2 R. Buhr. Machine charts for visual prototyping in system

design. Technical Report 88-2, Carlton University, August 1988.3 O. Dahl and K. Nygaard. Simula: An algol-based simulation

language. Communications of the ACM, 9, 1966.4 A.M. Davis. Software Requirements, Analysis and Specification.

Prentice-Hall, 1990.5 D. de Champeaux, A. Anderson, M. Dalla Gasperina, E.

Feldhousen, F. Fulton, M. Glei, C. Groh, D. Houston, D.Lerman, C. Monroe, R. Raj, and D. Shultheis. Case study ofobject-oriented software development. In OOPSLA ‘92. ACM,1992.

6 D. de Champeaux and P. Faure. A comparative study of object-oriented analysis methods. Journal of Object-OrientedProgramming, March/April 1992.

7 Random House. The Random House College Dictionary.Random House, 1975.

8 W.S. Humphrey. Managing the Software Process. Addison-Isley, 1990.

9 M. Jackson. Systems Development. Prentice Hall, 1982.10 M. Minsky. A framework for representing knowledge. In P.

Winston, editor, The Psychology of Computer Vision.McGraw-Hill, 1975.

11 NIST. Reference Model for Frameworks of SoftwareEngineering Environments. National Institute of Standardsand Technology, December 1991.

12 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W.Lorensen. Object-Oriented Modeling and Design. Prentice Hall,1991.

13 P.T. Ward. How to integrate object orientation with structuredanalysis and design. IEEE Software, March 1989.

14 P.T. Ward and S. Mellor. Structured Development for Real-Time Systems. Prentice Hall, 1985.

15 E. Yourdon. Modern Structured Analysis. Yourdon Press,1989.

Notes

87

LESSON 19 :OBJECT BASED METHODS

Topics covered

Object oriented system Development

• Attribute features• Optional attributes• Static and Dynamic

Object Relationships

• Relationships• Collections• Identifying Relationships

Class Relationships

• Property Inheritance• Subclasses• Multiple Inheritance• Inheritance of Relations

ObjectivesUpon completion of this Lesson, you should be able to:Explain about the attributes.With a live example about various attribute featuresExplain the various notation used for identifying objectrelationshipsExplain the various notation used for identifying classrelationships

Attribute Features We have attached attributes to objects. The next step is to give, ina sense, attributes to attributes. We will call them features to avoidtoo much confusion.Two features of attributes have been encountered already, theattribute’s relation name, which is sometimes called the role name,and the value domain . Here we expand the features that can beassociated with an attribute. We should stress that using thesefeatures is optional and can be ignored in first rounds or even alltogether.

DefaultsSometimes it is useful to indicate a default initial value for anattribute. A generous bank may, for example, give a surprisednew customer an account with an initial balance of $10. Sincesheep are usually white, their color attribute can be given thisdefault value.A revised Account class includes a notation for indicating a defaultvalue of an attribute:

ProbabilityWe may want to associate with an attribute our knowledge aboutthe distribution of the values in the value domain. (A defaultvalue need not correspond with the value that has the highestprobability.) As an example, consider the class Human with theattribute age. The probability distribution corresponds here with ademographic profile. A designer may want to exploit thisinformation.We avoid introducing special notation. One option is to list (value,probability) pairs. For numerical domains, a probabilitydistribution function may be specified. Any other mathematicalnotation may be invoked as needed.

MultiplicityA multiplicity feature associates more than one value to an attribute.We use the notation [N:M], where 0 <= N <= M. N indicates theminimum number of values and M indicates the maximumnumber. A few conventions simplify the notation:• We usually abbreviate [N:N] as [N] to represent a multiplicity

of exactly N.• We usually omit a multiplicity indicator when the multiplicity

is [1].For example, the class Hand might contain the attribute finger witha value domain of class Finger and a multiplicity constraint of[0:6]. This requires an explanation indeed. A hand remains a handeven when all the fingers have been amputated. That explains theminimum 0. The 6 has been chosen because Anne Boleyn had ahand with six fingers.This multiplicity notation is sometimes not expressive enough.Consider a family of vehicles where the number of wheels pervehicle is 3, 4, 6 or 10. In general, a multiplicity indicator can be anyarbitrarily complex description of a set of natural numbers. Giventhis state of affairs, we omit additional notation beyond observingthat predicate calculus provides formal precision and unboundedexpressiveness.

Optional Attributes Using a zero lower bound in the multiplicity feature of an attributeindicates that possession of the attribute is “optional”. This allowsinstances that effectively do not have that attribute. This is a way

88

around the limitation of freezing a collection of attributes for aclass.For example, a bank has branches, each having departments. Weassume that departments consist of a department head andsubdepartments. This creates a recursive structure that bottomsout by making subdepartments optional. Thus, a nonmanagerialemployee is a department head that does not supervisesubdepartments. For illustration, we restrict the branching ratioof departments to six:

Multiplicity default and probability.Multiplicity indications may be dressed up with more knowledgeif this information is beneficial for a design and/orimplementation. For example, a reasonable default multiplicityfor the number of wheels of a car is four. A probability distributionfor the multiplicity feature denoting the number of children perparent might be obtained through an empirical sampling.

QualifiersThe range of an attribute value can be restricted in any of severalsenses. We always fix an attribute to a particular domain. Thevalues of an attribute of an object must remain within the indicateddomain throughout the lifetime of the object. The domain for anattribute listed in a class may be narrowed down to only onepossible value. For example, the class Albino has for its colorattribute the value white.

Several other senses of restriction are common enough to groupunder broad categories, allowing simpler qualification:• We may require that an attribute value for each instance of the

class to be fix• ed (immutable) when the object is created andinitialized. This value may differ across different instances, butit may not vary across time for any instance. Fixed attributesdifferentiate instances from peer objects that are members ofthe same class.

• We may require that the value of an attribute be common to allinstances of a class, even without knowing what that valueshould be. The common value may also change across time.For example, all instances of class Account might need to recordtransactions using a common LogFile. The exact file may changeover time.

• The category of unique attributes is the extreme opposite ofcommon. A unique attribute is one whose value differs foreach instance of a class. For example, the value of attributeaccntId should be unique to each instance of class Account.

Qualifiers including fixed, common, and unique may be annotatedin any convenient fashion. For example, the following class Clienthas a social security number attribute that is both unique for eachinstance and remains fixed over its lifetime:

Statics and Dynamics• Static considerations may be insufficient to differentiate classes.

We can still have variations based on behavioral differences.• For example, one kind of calculator may support only addition

and subtraction, while another one with the same attributestructure (at an appropriate abstraction level) also supportsmultiplication and division. However, we are emphasizing fornow class identification, and especially characterization, via thestatic features of the objects that constitute a class.

• This may sound counterintuitive. Some entities are easier todescribe via their dynamic (potential) dimension. For instance,a pilot is a person that can fly a plane. Even so, remember thatthe static and dynamic dimensions of an entity arecomplementary notions that can add and build onto the other.Change is perceived against a background of constancy.

• Dually, constancy is merely the inability to perceive a slow rateof change. In addition, our treatment of the static dimensionof objects before addressing the dynamic dimension shouldnot be seen as an imperative for the OO analysis process.

For example, an automated teller machine can be understood as adevice that can support a range of financial transactions. (Theterm machine in its name already emphasizes the dynamic aspect.)However, it may still be described in terms of its static features.The following first impression for class ATM (to be revisedextensively in coming chapters) lists attributes indicating functionalcomponents of an ATM machine:

89

• For a different kind of example, the following TransferDaemonclass represents the static dimension of procedures that are runperiodically to transfer an amount provided a condition is met.For instance, such a procedure may automatically transfer moneyto a savings account when a checking account has too muchmoney.

For now, we sketch out characterizations of the attributes thathelp to control dynamics:

TimeIntervaldescribes how often a transfer will be attempted. Possible valuescan range from minutes (or perhaps even shorter) to months (oreven longer).

AmountExpressionIs any expression describing the amount to be transferred. Thismight just be a fixed sum. Alternatively, we can envision that theAB bank allows for amounts that are functions of certainparameters. For example, to maintain a certain balance in the fromaccount, it might take the form:(the balance of the from account) — (a fixed sum).

TransferBooleanDescribes a truth-valued function to be used to block the transferwhen certain conditions are not met. For example, a value calculatedby the function outlined in the previous attribute should not betoo small, or one may want to constrain the maximum amounton the target account.

RelationshipsA relationship may be seen as a named family of typed tuples.They are typed in the sense that the nth element in a tuple is aninstance from a specific domain or class.The signature of a relationship is just a listing of these types. Forexample, the signature of the Ownership relationship is ( Client,Account) since it has a family of 2-tuples where the first domain isthe class of Clients and the second domain is the class of Accounts.Following the tradition of the data modeling community andother OOA methods, a diamond is used to depict a relationshipin our graphical notation. A diamond is connected via edges tothe domains of the tuple elements. Obviously, we will alwayshave at least two edges.For example, to indicate that class Client and class Account areconnected by the relationship Own:

In the same way that we may want to refer to particular instancesof classes in a particular target system, we may want to expressthat certain instances actually belong to a relationship.For example, we may want to express that a particular client ownsa particular account. An instance of a relation is represented with adiamond containing a filled circle:

90

Graphical notation can sometimes cause an ambiguity when arelationship connects identical domains. For example, the Superviserelationship between two Persons is described in textualrepresentations by ordering the arguments, as in:Supervise(Person, Pe r son ) .We can agree that the first argument represents the supervisor andthe second argument the “supervisee” (person that is beingsupervised). To avoid ambiguity in diagrams we can add rolenames, as in (letting Spv stand for Supervise):

CardinalityConsider a domain in which an account cannot have more thanone owner. This means that a particular instance of Account canoccur not more than once in an Own tuple.Cardinalities (the relational versions of multiplicities) may be usedto indicate such properties. Here, we can add the cardinality notation[0:1] to the diagram:

Alternatively, we could express that each client can own one tomultiple accounts and each account can have one to multipleowners:

As another example, we may want to express that a peculiar groupof *Client*s have at least three but at most five accounts with:

The date that a client becomes a customer may be described as arelationship. Each client must have exactly one start date. A clientmay have started on the same date as another client.Letting CsSn stand for CustomerSince(Client, Date):

QualifiersRelationships may be classified according to their technicalproperties.

ReflexiveFor all x, R(x, x) holds; i.e., every element is necessarily related toitself. For example, the relationship SameAgeAs.

SymmetricFor all x and y, R(x, y) implies R(y, x); i.e., the relationship is“bidirectional”. For example, the relationship SiblingOf .

TransitiveFor all x, y, z, if R(x, y) and R(y, z) hold, then R(x, z) holds. Forexample, the relationship AncestorOf .

Constraints

In the same way that constraints provide supplementaryinformation about simple attributes, additional constraints mayexpress restrictions on the allowed instances of a relation.For example, we can rephrase the fact that instances of class Personhave the attribute spouse as a binary relationship Spouse betweenPerson and Person (assuming the spouse attribute has been eliminatedfrom class Person):

The [0:1] cardinality captures a monogamy restriction.

The arity, or number of elements in the signature is another wayof classifying relationships. Binary relations (such as Own andSupervise) have tuples of length two. Ternary relations have tuplesof length three. Examples include:

InBetween,a relationship among three Locations. For example, Chicago is inbetween San Francisco and New York.

TravelTimeBetween,a relationship among two Locations and a TimeInterval. For example,the travel time between New York and San Francisco is six hours.

ParentsOf,a relationship among three Persons. For example, John and Maryare the parents of Susanna.ResideInSince,a relationship among a Person, a Location, and a Date. For example,John resides in Stockholm since December.

BorrowedFrom,a relationship among two Persons and a Thing. For example, Johnborrowed a lawn mower from Mary. (“ Thing” here is perhaps toobroad. Can someone borrow the Sun?)We can have relations with tuple lengths larger than three as well.Graphically, more than two edges are obviously required forrelationships with arity greater than two. For example, we mayconstrue Transfer as a relation among a pair of accounts, anamount, and a date (letting Trans stand for Transfer(fromAccount,toAccount, amount, date)):

91

SetsSets are the most well-known and useful kinds of collectionsOnce we have sets, we can open the floodgates and adjoin to ourrepresentational apparatus the notations that are available in settheory. These include:for intersection,for summation,for subtraction,for the subset relationship,for the superset relationship.We denote sets by expressing their domains as “arguments”. Forexample, a set of branches is denoted as SET(Branch). Observethat we now have two ways to describe multivalued attributes;sets and multiplicity features. The following two depictions maybe treated as equivalent:

Multiplicity and set notations may be combined, for example,when we introduce multivalued attributes where each individualvalue is a set. In the following example the class School treats itsfaculty as an undifferentiated set of employees and treats the studentbody as a family of sets of students:

When a multivalued attribute would have more specific multiplicitybounds, as in [3:7], the corresponding set notation may beannotated accordingly in any agreed on manner.

Other CollectionsIf necessary, the analyst is invited to employ other collectionnotations and the usual operations associated with them:

Sequences.For example, the class String may be described as SEQ(Char).Other examples include the ATM attribute logOfSessions, whichhas as value domain SEQ(Session).

Arrays.For example, the class 2D-4-5-grid may be described asARRAY[3:4](Point). The days of a year can be represented as anarray, for instance, to record a savings account interest rate for thattime period: ARRAY[365](Day).

Bags. For example, the collection of accounts involved in receiving fundsin a certain time period may be described as a BAG(Account). Sincean account may receive funds more than once we can haverepetitions.

Generic ClassesAdditional collections and related constructs may be defined asgeneric classes. These classes capture the commonalities of a broadrange of other classes. Inheritance is an excellent mechanism toexploit abstract classes and create more specific versions. Genericclasses instead use the style of procedure or function variables toexpress genericity.Our notations for sets and other collections are special cases ofthat for generic classes. By convention we use upper case namesfor generic classes. For example, the following generic class QUEUEhas instances with elements of type X.

When the class Job happens to be around, we can introduce theclass QUEUE(Job) .

Identifying RelationshipsRelationships versus ClassesAnalysts often have some freedom in whether to use classes versusrelationships to represent static features of a domain. The notionof Transfer is an example.The main consideration is that classes and relationships describedifferent kinds of instances.. Instances of relationships do notnecessarily share these properties. A relation instance need not beascribed an independent identity. It may be fully characterizedmerely by listing the elements of the tuple. Relation instancesneed not have any intrinsic properties outside of those of the

92

tuple. And they cannot change state or communicate with otherobjects at all.Analysts may choose the approach that appears most appropriateto the task at hand. When aspects of a purported relation appearclass-like, or vice-versa, descriptions may change accordingly.

Intensional Versus Extensional DefinitionThe ways in which classes and relationships are defined also differ.Classes list the central defining characteristics of identifiable objectsin a domain..Like sets, relationships are normally described in a partially extensionalfashion. Most relationships describe tuples corresponding to thestate of affairs in the “world” and are determined by circumstances.Thus, they have been obtained by some form of observation.The Ownership relation is an example. In this case, the family oftuples is simply a set, and in practice is a “small” finite set. For allpractical purposes, relational modeling deals only with extensionallydefined relations in which the family of tuples is small and canconceivably be handled by storage media that will satisfy resourcerequirements constraints.While a useful guide, this distinction does not intrinsically separateclasses from relationships. Intensionally defined relationships mayprovide a definition (e.g., a predicate) that characterizes which tuplesbelong to the relation and which do not. Grandparenthooddefined as being the parent of a parent is an example. Anotherexample from the realm of math is the successor relationshiprelating every natural number N with its successor N+1. Here, thefamily of tuples is still a set, although not small and in fact ofinfinite size. Relationships where the family of tuples is not a setany longer are possible as well.

Relationships versus AttributesAs a result of the similarity between attributes and binaryrelationships, an analyst must take care not to prematurely absorbbinary relationships into a class definition.The main conceptual issue is whether a feature is definitionallyintrinsic to an object. One question to ask is whether every instanceof a class is necessarily related to a member of the otherdomain. In this case it is normally a genuine attribute; in othercases it is better represented as a relationship. On the other hand,one should be pragmatic as well. For example, in spite of theexistence of Gliders, it makes sense to see Engine as a [0:M](multivalued) attribute of Airplane. Consequently, Gliders may bedescribed as effectively lacking the attribute Engine by giving themthe multiplicity feature [0].A related question is whether one object is conceptually “incontrol” of the values assumed in the other domain.Binary acquaintance relations serve this need. However, when oneobject must be able to determine its partner(s), this informationmay be listed in attribute form.

FunctionsFunctional relationships (or just “functions”) represent the meetingpoint of these considerations. A tuple component of a relationdepends functionally on the other components if its value isuniquely determined by the other components. The cardinalities[0:1] and [1:1] for any of the domains indicate a functional

dependency. The cardinality [0:1] reflects a partial function thatneed not “hit” every element in the domain.For example, the following diagram indicates that every personhas precisely one mother, and every mother has at least one child.Letting Mo stand for the MotherOf relation:

Functions are among the most common kinds of relationships.In functional relationships, at least one direction of the relationassociates a single element of one domain to those in the other. Itis convenient and often reasonable to treat them as attributes infunctional direction if this appears central to the definition of theclass. In this sense (as exploited in design — see Chapter 16) allattributes are functions. For example, to indicate that each personmust have a mother:

Similarly, consider the MaintainedBy(Account, Branch) relation sayingthat an account must be maintained by one branch, and a branchmaintains at least one, possibly more accounts. This could bedescribed as a functional relationship (letting MnBy stand forMaintainedBy ):

Alternatively, the Account class could have an attribute maintainerwith domain Branch. The “other” direction in a functionalrelationship may also be described as an attribute when thiscontributes to the definitional characterization of a class. However,in this case, the attribute normally has a SET domain. For example,each Branch could have an attribute maintainedAccts with domainSET(Account).More generally, any binary relationship may be described with apair of possibly set-valued functional attributes (one per domain)when it is meaningful to do so. However, the “equal partnership”implicit in the idea of describing pairs of functional attributes isbetter captured as a relationship proper.The extreme case of a functional relationship is a one-to-one function,where the cardinalities of both domains are [1:1]. In this case, eachelement of one domain is “matched’ with a unique element ofthe other. (If one of the domains has cardinality [0:1], this insteadrepresents a partial one-to-one function). For example, the“relationship” between an Account and its accountNumber is one-to-one, as would be a relationship between Departments and

93

Managers saying that each department has a unique manager andeach manager manages a single department. These relationshipsare most naturally captured as attributes. When doing so, attributemultiplicity notation may be extended as [1:1]-[1:1], or abbreviatedas unique to indicate this property.We summarize these classifications by showing how somestandard function categories are described as attributes:

One-to-OneA function is one-to-one if each distinct argument maps to adistinct result. This corresponds to unique.

PureA function is pure if multiple applications with the same argumentalways give the same result. This corresponds to per-object fixed.

SingularA function is singular (or fully many-to-one) if it always gives thesame answer, regardless of argument. This corresponds to per-class common (i.e., constraining all instances to possess the samevalue).

PartialA function is total if it is defined for each possible argument.Otherwise it is partial. Partial functions are denoted with [0:1]multiplicities.

MultivaluedA multivalued (or one-to-many) function corresponds to either[1:N] multiplicities or SET or other collection domains.Inheritance is a core concept of the object-oriented paradigm,emerging in two basic contexts, abstraction and reuse.

AbstractionFirst, one may recognize that two constructs A and B havesomething in common. To avoid having to deal twice with thisshared aspect, one may create a construct C that captures thecommonality, remove this commonality from A and B and restoreit in A and B by letting them inherit from C. Consider Apples,Pears, and Oranges. It may pay off to introduce the notion of Fruitand factor out in Fruit the commonalities of apples, pears, andoranges. Similarly, it may pay off to introduce the class Account tocapture the commonalities in CheckingAccount, SavingsAccount,BusinessAccount, etc. Hierarchical abstraction of common featurescontributes to the overall human understanding of the objectsand classes comprising a system.

Reuse and SpecializationA second reason for using inheritance can arise during modelconstruction. During the construction of, say, class D, one mayrecognize that a desired feature of D has been developed alreadyand is available in, say, class E. Instead of reconstructing thisfeature, one establishes a directed inheritance link between D andE. The more specialized class D reuses all features of E. In theprogramming realm, this is sometimes known as “programmingby differences”.

Property InheritanceThe notions subject to inheritance in an analysis, a design, and animplementation are respectively properties, computation, andcode. Since classes are not described through code in the analysisphase, we have a more abstract notion of inheritance than seen in

OO programming, property inheritance. Properties consist ofdeclarative class features and associated constraints. (We consideronly explicit features and constraints ruling out features, values,etc.)

Property inheritance is a relation between a subclass and a

Superclass. Class Q is a subclass of superclass P when every attribute,constraint, and transition network of P is also an attribute,constraint and transition network of Q and wherever P participatesin a relationship Q does as well. Additionally, the subclass Q is“stronger” than P. Instances of Q have all the definitional propertiesdefined in class P, but are also constrained by at least one additionaldefinitional feature. Thus, the family of instances of Q i s asubfamily of the instances of P. In more detail:

AttributesIf all instances of P possess attribute a, then so do all instances of Q. Allfeatures and constraints applying to a in P also apply to a in Q.

RelationshipsIf there is a relationship between P and a class R, then there is arelationship between Q and R as well. If this relationship isfunctional and all of P is in the domain of the relationship, thenfor every instance q in Q there is an associated instance r in R.

TransitionsIf the behavior of P is described by a transition network withstate S and transition T, then Q has state S and transition T aswell.

Interactions:If instances of P may interact with, accept event input datadescribing, and/or generate output event data describing instancesof a class R, then so may instances of Q.All classes may be considered to be subclasses of a common base.We consider class Any to describe any object. It thus serves as theroot of any inheritance hierarchy. The class defines no attributes ortransitions. Any is an example of a class that is not directly(deterministically) instantiable. No object is a member only ofclass Any, but instead of one of its subclasses (or their subclasses,or ...). Non-instantiable classes are common results of superclassabstraction.

SubclassesOne can simply declare that a class is a subclass of another, forexample that class CheckingAccount is a subclass of the class Account.It is, of course, much more defensible to provide a reasonedjustification of why the class is a subclass of the other. In general,inheritance is justifiable when the subclass description imposesadditional features and/or constraints without invalidating anyproperties described in the superclass.We will give a set of more precise justifications, along withexamples. In this section we focus on the definition of a subclassQ with a single superclass P. We will later broaden this to includemultiple inheritance

Additional AttributeQ adds an attribute to those that it has obtained from P. As anexample, a Room has the subclass Bathroom with the attribute bathof domain Bathtub:

94

As illustrated here, our graphical notation of the superclass-subclassinheritance relation is an arc directed to the superclass.For another example, consider a bank to be a family of brancheswhere the headquarters is considered to be a special branch. Thissuggests defining the class Headquarters as a subclass of Branch. Wecan distinguish these two classes by giving Headquarters anadditional attribute president with domain Employee:

A variation on this justification is for Q to require that additionalelements be contained in a SET or other collection attribute definedfor P, assuming that P does not possess any constraints (e.g.,collection size bounds) that preclude this.

Additional TransitionA subclass Q inherits everything in parent class P, including itstransition network. In the simplest case, the transition networkfor Q is the same as the transition network for P. This providestransitions “for free” in the subclass. However, it is possible thatthe transition network of Q contains additions to P’s transitionnetwork.A subclass may contain additional attributes that in turn generatenew states and transitions. For example, a savings account mayhave an attribute that describes the interest rate. As a result, thebehavioral description may have an additional transition thataccounts for interest debits. Other examples include:· Let P be a particular kind of editor. Q does the same and

supports in addition an undo operation.

· Let P be a particular kind of car. Q has exactly the same features,however it has the additional behavior that it can be operatedin four-wheel drive.

Additional ConstraintSubclass Q may differ from P because Q carries an additionalconstraint on the attributes of P. For example, let P be the class ofCustomers, and Q the class of GoldenCustomers ( GC) with thefeature that they have been customers for at least ten years.

Narrowed MultiplicityA special case of additional constraint is a narrowed multiplicityfeature. For example, let P be the class of Airplanes with themultivalued attribute engine having multiplicity feature [0:M] statingthat a plane has zero or more engines. Now let Q be the class ofgliders where we narrow down the multiplicity feature of engine to[0]:

As another example, consider the class of bikes that can have asinstances unicycles, bicycles, and tricycles

Narrowed DomainAssume that P has an attribute with the class PR as a value domain.Subclass Q differs from P because it has for this attribute the valuedomain QR instead of the value domain PR, where QR is asubclass of PR. Thus, we see that the subclass notion has a recursivecomponent.As an example, let P be the class Person having the attributecountryOfBirth where the value domain PR is equal to Country. LetQ be the class European. We choose EuropeanCountry as thecorresponding value domain QR. Indeed, with this choice QR is asubclass of PR and thus Q is a subclass of P:

95

Fixed DomainSubclass attributes may be narrowed down to fixed values. Toextend the previous case, instead of being restricted to a subclassof PR, Q’s attribute may be fixed to a certain value of PR, say, qr.Elaborating the previous example, Canadian becomes a subclassof Person by fixing the value domain of countryOfBirth to theinstance Canada of the class Country.

Similarly, we can obtain the subclass Albino out of Mammal byfixing a color attribute in Mammal to white:

Multiple InheritanceA subclass may have two or more superclasses, inheriting allproperties and constraints from each. For example, we mayintroduce an account that combines the features of a checkingaccount and a savings account, a so-called BahamaAccount:

Careless use of multiple inheritance can result in the introductionof frivolous subclasses that do not describe any possible instance.For example, one may define a meaningless subclass that inheritsfrom, say, both Account and Mammal. Such constructions may be

avoided by demanding that every defined class be illustrated withat least one prototypical instance.

Attribute Ambiguity

In multiple inheritance, equal attributes from multiple sources areprojected into a single occurrence. This is one reason that differentconcepts and roles should not be associated with the same namein OO models. For example, consider the class of employees whoare also clients:

Multiple inheritance may lead to ambiguity when a subclass inheritsa feature that has two or more different interpretations in thedifferent superclasses. For example, suppose that both the classEmployee and the class Client introduce an attribute address. Assumethat the value domain for address in Employee is, say, LongAddress(supporting an extended zip code), while the value domain foraddress in Client is ShortAddress. What is the domain for address inEmployeeClient?It is the responsibility of the analyst (and/or a support tool) toavoid or repair these ambiguities. Here, one solution is to redefinethe class Client by making it a subclass of the class ClientNA,which is like the original Client class but does not have the addressattribute. The ShortAddress attribute may then be added to Client.Class EmployeeClient avoids the address ambiguity by inheritingfrom both Employee and ClientNA . Letting LA stand forLongAddress and SA for ShortAddress, we obtain:

Alternatively, the ancestor class Person could be subdivided in ananalogous fashion. For example, subclass PersonWithLongAddresscould be made the common superclass of EmployeeLA andClientLA. Pushing the distinction up one level has the advantageof addressing similar ambiguities that may arise in any additional

96

Person subclasses that are introduced. An even better strategy is touse only one form of Address, if this is possible.

Sibling RelationshipsThe relationship among the n sibling subclasses Q1, Q2, ... Qn ofsuperclass P may be stronger than indicated by the mere fact thatthey are all subclasses of the same superclass. We discuss threespecial cases, exclusion, covering, and partitioning.

ExclusionWe may know that sibling subclasses are definitionally disjoint,thus exclude each other. Among other constraints, this impliesthat if we have an instance of Q1 then we know that this instancedoes not satisfy the definitional characteristics of Q2, ... Qn.For example, clients may be divided into two definitionally exclusivecategories:P = the class of clientsQ1 = those clients that are also employeesQ2 = those clients that are not employees.For another example, assume that different account subclasseshave been characterized in terms of attributes and/or constraintssuch that they are, in principle, mutually exclusive:Accoun t = BankAccount + ClientAccountClientAccount = Personal + Joint + BusinessA “+” is conventionally used in textual listings of disjoint classes.We also denote this graphically as follows:

The subclasses in a family of subclasses Q1, Q2 , ..., Qn of Pbearing an exclusion property are connected in an indirect way tothe superclass P. Their family membership is expressed byconnecting them first to an intermediate box which is in turn isattached to the superclass. This notation is also used for coveringand partitioning. To discriminate among them, we put an E, C, orP in the little intermediate box.

Multiple RelationshipsA class may bear more than one family of exclusions, coveringsand/or partitionings. These sets are independent (or orthogonal) whenthe intersection of any tuple of subclasses taken from the differentcharacterizations is nonempty. As an example, consider thefollowing sets of properties describing Human s :

National i ty = American + NonAmericanGender = Female + MaleHeight = Short (< 1.6m) + Medium + Tall (> 1.8m).All crossings are permitted. For example, the intersection ofAmericans, females, and people of height less than 1.6m leads toa meaningful class.Assuming that each of these have been described as subclassstructures, there are two variant techniques for using them toderive new subclasses, attribute narrowing and mixin1 inheritance.In the first, properties are listed as attributes of a base class, andnarrowed in subclasses. The superclass may list unconstraineddomains, and the subclass constrained ones:1FootnoteThe term “mixin” has grown to be used so commonly in aparticular technical sense to have lost its hyphen. This also true ofa few other terms, including “callback”Using mixin inheritance, classes representing completelyindependent properties are “mixed together” via multipleinheritance in the target class. The superclasses used in mixininheritance are often totally useless, and even unnatural bythemselves, but readily combine with others to form meaningfulclasses. For example:

IndependenceThe previous example illustrated two different strategies for relatingpartitioned attribute structures through inheritance. While similar,these are not always equivalent in effect. For example, consider aMailingLabel class with a set of attributes containing no explicitcodependency constraints:

While unstated, there are some implicit constraints among theattributes, especially the fact that together they describe an actualpostal address. However, these constraints are not even specifiablewithout recourse to a model of the entire postal system, andthus, probably, of the entire planet.

97

There are many ways in which these properties could have beenfactored into classes. One extreme is to create a class for each attributeand then to use multiple inheritance to bind them together:

This class structure suggests that the different aspects of aMailingLabel may be viewed “in isolation”. But this is not necessarilytrue, especially if each of the mixed-in classes contains a transitionthat changes the value of the single attribute it maintains.Changing, say, the city surely requires changes in the zipcode. Whenproperties are truly orthogonal, multiple inheritance is a good wayof describing property combinations. But the implicit constraintsthat the parts together form a legal address indicate otherwise here(and in nearly all similar situations). Most often, interdependenciesare much more explicit than in this example, thus arguingimmediately against multiple inheritance.Here, an intermediate factoring is more attractive. By isolating theaddress properties in an Address class, we can still structurally reflectthe cohesion of the address attributes. The MailingLabel class thenconnects the address to a name. By doing this, we will have createdan Address class that seems generally useful beyond what is neededfor mailing label purposes.Construction of an Address class is, of course, a pretty obviousmaneuver. But once we have broken out Address, we can thinkabout extending and refactoring this new class. For example, itseems like a bad idea to use a zip code attribute, since this onlyapplies to addresses in the United States. It seems safe to say thatall addresses, world wide, need street and city properties (orsurrogates such as post office boxes, which are OK since these arejust uninterpreted string attributes). But different countries havedifferent postal codes and/or other information required onmailing labels. This could be captured through standardsubclassing mechanics.

Adding AttributesAs illustrated in the previous example, inheritance may be used tohelp elicit and flesh out tacit dependencies among attributes.Attempts to factor classes into hierarchies may also reveal attributesthat were not originally listed in classes, but only implicitlyassumed.For example, an Employee class might be defined as a subclass ofPerson, with additional attributes such as salary. But there may beother properties that distinguish employees from people in generalthat nobody bothered to list. Assuming that this class is used inour banking application, an obvious one is the predicateworksForAB, which is true for employees but not others, andsimilarly for isEmployed, mayParkInEmployeeLot, and perhaps manyothers.It is sometimes difficult to avoid implicit distinctions during initialclass definition. There may be innumerable ways in which objectsof conceptually defined subclasses differ from those of theirsuperclasses. These are only made explicit when analysts notice

their importance in a given model or hierarchy. Leaving themimplicit can be a source of error. Of course, the best solution is toadd appropriate attributes. For example:

ReviewAttibute FeaturesOptional FeaturesStatic and Dynamic properties

Class Relationships• Property Inheritance• Subclasses• Multiple Inheritance• Inheritance of Relations

Questions1. Identify objects, introduce their classes, give attributes, their

features and constraints as suggested by the following text:Mr. White is married. He teaches OO Software Engineering classeson Fridays. He is a part-time member of the faculty at the CSDepartment of the All-Smart Institute. His 23-year-old son Johnwas enrolled in the OOA class that Mr. White taught in theprevious semester. John does not like broccoli. Mrs. White uses aten-speed for transportation to and from the campus (she teachesPhilosophy at the same institute). Class size is limited at theinstitute to 14 students. The faculty at the institute, when seen asparents, have at most two children. The sister of John has aboyfriend that is two years younger than she is and plays twodifferent instruments.12345

98

2. A “meta” constraint on a class may express how many instancesit can have in a particular target system. As a special case, aconstraint may express for a class that it has only one instance.Would such a construct obviate the notion of an instance?Consider the notions of the president of a company, NewYear, the first day of the year, Washington, the capital of theUnited States, and the headquarters of a bank.

123451. Describe a set of classes that represent entities in your kitchen.12345Formulate a relation that has tuples of length four, five, ... Try toavoid relations that are constructed by adjoining time and/orspace qualifiers as in: John travels from A to B on Sunday .12345Can the following information be represented as relationships?1. The balance of an account ten days ago.2. Accounts associated with the zip code(s) of their owners.3. Employees located in Toronto.4. The grandparents of the children living in Springfield.5. The weather report of 2001 January 1.6. The molecular structure of H2O.7. The contents of a library.8. The public transportation schedule in LA (assuming they have

one).9. The recipes in a cookbook.10. The patterns of traffic lights at an intersection.11. The contents of an encyclopedia.12. The grammar of FORTRAN.12345678

91011122. Give examples of generic classes having one, two, ... arguments.123452. Discuss whether the following families of objects can be

represented as a set and/or as a class.1. The states of the US.2. The members of your family.3. The atoms in the universe.4. The inhabitants of Berlin.5. The colors of the rainbow.6. The natural numbers.7. The days of the week.123451. We have advocated introducing subclasses through the

mechanism of applying only one of the subclassingmechanisms at a time. Multiple inheritance will in general deviatefrom this advice. Is the advice wrong? Should multipleinheritance be avoided?

123451. To obtain justification for relationship inheritance, we looked

into the justification of class inheritance. Check the list of classjustifiers and try to construct additional justifiers for relationshipinheritance. Consider, for example, multiple inheritance forrelations.

123452. Consider a domain with which you are familiar, for example, a

university environment, a kitchen, a hardware store, etc. Describefragments of such a domain exploiting (multiple) inheritance.

99

123453. Does it make sense to make Human a subclass of Mammal and

Male and Female subclasses of Human? If not, what would bean alternative?

123454. Give an example of classes related by inheritance, possibly

involving multiple inheritance, where there are at least fourlevels of parent — child classes.

12345Compare Waterfall and Iterative Enhancement model.

References• G. Booch. Object Oriented Design with Applications. Benjamin/

Cummings, 1990.• R.J. et al Brachman. Living with classic: When and how to use

a kl-one-like language. In John F. Sowa, editor, Principles ofSemantic Networks. Morgan Kaufmann, 1991.

• R. Carnap. Meaning and Necessity. The University of ChicagoPress, 1947.

• D.W. Embley, B. Kurtz, and S.N. Woodfield. Object-OrientedSystems Analysis. Yourdon Press/Prentice Hall, 1992.

• R.J. Brachman. A structural paradigm for representingknowledge. Technical Report 3605, BBN, May 1978.

• D.W. Embley, B. Kurtz, and S.N. Woodfield. Object-OrientedSystems Analysis. Yourdon Press/Prentice Hall, 1992.

• D. Maier. The Theory of Relational Databases. Computer SciencePress, 1983.

• Z. Manna and R. Waldinger. The Logical Basis for ComputerProgramming. Addison-Wesley, 1985.

• J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W.Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991.

• J.D. Ullman. Principles of Database Systems. Computer SciencePress, 1982.

100

CHAPTER IISYSTEM INVESTIGATIONLESSON 20 :

INTRODUCTION TO FACTFINDING TECHNIQUES

Topics Covered• Introduction to system Investigation• Fact Finding Techniques• Observation• Interview• Investigation• Questionnaire

ObjectivesUpon completion of this Lesson, you should be able

to:

• Explain the Nature of System Investigation• Explain the various fact finding techniques• Know about Fact analysis

Introduction System InvestigationRequirements Analysis Goals

• Fully describe the current system• Study and analyze the current system (gather and study facts)• Determine the ideal information system• Identify resource constraints• Define and prioritize requirements• Inspire user confidence/ownership

Study & Analyze Current System

• Gather information on what the system should do from asmany sources as possible

• Concentrate on WHAT is needed, not HOW to do it• “Don’t try to fix it unless you understand it”• Major problem: analyst not understanding user needs

Initial investigation

Ø This phase introduces the objectives of the initial investigation,the steps required to initiate an investigation; the tasks involvedin the initial investigation, and the data gathering andinterviewing techniques.

Ø It also includes information and exhibits that should be in theinitial investigation report, with regard to “How the standardsmanual might be used?” and “why to do this after reading thissection.”

Overall Strategy for Fact Finding

1. Learn all you can from existing documents2. If appropriate, observe the system in action3. Conduct interviews4. Use questionnaires to clear up things you don’t fully understand

5. Follow-up

Study & Analyze Current System

— Activities —

1. Learn about current system (gather facts)2. Model current system3. Analyze problems/opportunities (study facts)4. Establish new system objectivesOutput —1. Complete statement of user environment2. Models of current system3. List of major problems/causes/effects4. System objectives

Some Questions That Must be Answered

• What are the inputs to this system?• What are the outputs of this system?• What is the business process (i.e., how is data processed)?• Who are the direct end-users?

• How will the users feel about this system?• Who developed the existing system?

Learn About Current System (gather facts)

Gather information from:–Current information system:

–External sources

• Reviewing other IS outside the organization can reveal practicalideas and techniques

–Internal sources

• Single most important source of facts is the user• Existing paper work or documents is also a good source

Analyze Problems / Opportunities(study facts)

• Study and analyze the “current” system• Problem analysis is difficult.–We often try to solve problems without analyzing them.–We try to state the problem in terms of a solution.

101

• Use the PIECES framework to frame your investigation ofthe problems, opportunities, and requirements

– Performance analysis– Information and data analysis– Economic analysis– Control and security analysis– Efficiency analysis,Service analysis

Requirements Analysis Document

• Parts

How analysis was conducted

• Credibility• Restarts

User requirements

System constraints

Realistic System Objectives

User Requirements

• User system objectives (unedited)• Reports (type/frequency)• User training needs• Effect of system on various users

Organization Chart

Tactics

• Listen - don’t lecture• Don’t pre-solve problem• Compare stories• Look for reluctant responses• Observe your effects on system• Avoid politics (head nodding)• Expect hard, boring work• Fact-finding Methods• Research and site visits• Existing documentation• Observation• Questionnaires• Interviews

Observation

• Not for long periods of time

Will change what your measuring

• Vary observation periods• Take only minimal, preplanned notes• Coordinate visit beforehand and Beware of Selective

Perception!!!

Fact-FindingAfter obtaining this background knowledge, the analyst begins tocollect data on the existing system’s outputs inputs, and costs.They are

• Review of written documents,• On-site observations,• Interviews, and• Questionnaires.• Brainstroming• Delphi Method

Review of Written Documents

• When available, all documentation on data carriers (forms,records, reports, manuals, etc.) is organized and evaluated.

• Included in procedures manuals are the requirements of thesystem, which helps in determining to what extent they aremet by the present system.

• Unfortunately, most manuals are not up to date or may no bereadable. Day-to-day problems may have forced changes thatare not reflected in the manual.

• Furthermore, people have a tendency to ignore procedures andfind shortcuts as long as the outcome is satisfactory.

• Regarding existing forms, the analyst needs to find out howthey are filled out, how useful they are to the user (in ourscenario, the customer.) what changes need to be made, andhow easy they are to read.

On-Site Observation

• Another fact-finding method used by the system analyst is on-site or direct observation. The analyst’s role is that of aninformation seeker.

• One purpose of on-site observation is to get as close as possibleto the “real” systems being studied.

• As an observer, the analyst follows a set of rules. While makingobservations, he/she is more likely to listen than talk, and tolisten with interest when information is passed on. He/sheavoids giving advice, does not pass moral judgment on what isobserved, does not argue with the user staff, and does notshow undue friendliness toward one but not others.

• On-site observation is the most difficult fact-finding technique.It requires intrusion into the user’s area and can cause adversereacting by the user’s staff I not handled properly.

• The analyst observes the physical layout of the current system,the location and movement of people, and the workflow. He/she is alert to the behavior of the user staff and of the peoplewith whom they come into contact.

• A change in behavior observed in perspective.

The following questions should precede a decision to use onsit observation.

1. What behavior can be observed that cannot be described inother ways?

2. What data can be obtained more easily or more reliably byobservation than by other means?

3. What assurances can be given that the observation process isnot seriously affecting the system or the behavior beingobserved?

4. What interpretation needs to be made on observational datato avoid being misled by the obvious?

102

• If one-site observation is to be done properly in a complexsituation, it can be time-consuming. Proper samplingprocedures must be use to ascertain the stability of the behaviorbeing observed. Without knowledge of stability, inferencesdrawn from small samples of behavior (small time slices) canprove inaccurate and, therefore, unreliable.

Interviews and Questionnaires

• On-site observation is directed toward describing andunderstanding event and behavior as they occur. This method,however, is less effective for learning about people’s perceptions,feelings, and motivations.

• The alternative is the personal interview and the questionnaire.In either method, heavy reliance is placed on the interviewee’sreport for information about the job, the present system, orexperience. The quality of the response is judged in terms ofits reliability and validity.

• Reliability means that the information gathered is dependableenough to be used for making decisions about the systembeing studied.

• Validity means that the questions asked are so worded as toelicit the intended information.

• So, the reliability and validity of the data gathered depend onthe design or the interview or questionnaire and the manner inwhich each instrument is administered.

• In an interview, since the analyst (interviewer) and the person(s)interviewed meet face to face, there is an opportunity for greaterflexibility in eliciting information.

• The interviewer is also in a natural position to observe thesubjects and the situation to which they are responding. Incontrast, the information obtained though a questionnaire islimited to the written responses for the subjects to predefinedquestions.

Fact Analysis

• As data are collected, they must be organized and evaluatedand conclusions drawn for preparing a report to the user forfinal review and approval.

• Many tools are used for data organization and analysis.• Input/output analysis identifies the elements that are related

to the inputs and outputs of a given system. Flowcharts anddata flow diagrams are excellent tools for input/output analysis.

• Data flow diagrams are also used to analyze the safe depositbilling system.

• They can be very effective in settings that pose few constraintson data flow diagram whose content is equivalent to theinformation-oriented flowchart .

• It shows the general steps in the safe deposit billing system. Asan input/output analysis technique, it enables the analyst tofocus on the logic of he system and develop feasible alternative.

• The circles (also called bubbles) represent a processing pointwithin the system. The open rectangles represent data stores orpoints where data are stored. The square are departments orpeople involved in the billing system. The major steps in thebilling process are extracting the customer account, applying

the renewal cycle, preparing the bill, processing the payment,and accounting for cash receipts.

• Decision tables describe the data flow within a system. They aregenerally used as a supplement when complex decision logiccannot be represented clearly in flowchart.

• As a documenting tool, they provide a simpler from of dataanalysis than the flowchart. When completed, they are an easy-to-flow communication device between technical and nontechnical personnel. They are verbally oriented to managers,easy to learn and update,

Input/output Analysis Sheet

Dept: Safe Deposit System: Billing Date: ------

Input Processing/Files Output

Customer file record Customer record pulled out to determine expiration date and renewal rate.

If expiration date is less than 30 days, a billing statement is prepared.

Customerfile record

Customer Payment Payments are sent to the accounting department.

Payment /credit memo is sent to data processing for

verification and crediting customer’s account. The memo is

returned for filing.

Memo creates a journal entry in a cash and balance journal.

Data processing produces ages receivable report.

Memo becomes a part of customer safe deposit active list.

Data processing produces safe deposit revenue report.

Copy is sent to safe deposit and another copy kept on file .

Customer receipt of payment mailed to customer.

• A structure chart is a working tool and an excellent way to keeptrack of the data collected for a system.

• There are several variations of structure chart, locates the moduleassociated with the IPO on the hierarchy chart, and identifiesthe data elements along the line linking the module to a higherlevel (parent).

HEADTELLER

Verify and Processpayment

Account Journal

ExtractAccountto Read

Readexpirationdate and Rate

Apply New BillingRenewalCycle

PrepareStatement

AccountingDepartment

Customer File

Cash and BalanceJournalCustomer

DepositDetailedTransaction Data

Receipt Payment1 Unpaid

Balance 5Expiring

BoxReading

2 3

103

SafeDeposit Box Rates

Categories of InformationKinds of information Information

Describing

• Policies• Goals• Objective• Organization• Arbitary Relationships• Information Requirements• Interpersonal Relationships• Work flow• Methods and procedure• Work schedule

Information about User Staff• Another kind of information for analysis is knowledge about

the people who run the present system – their job functionsand information requirements, the relationships of their jobsto the existing system, and the interpersonal network that holdsthe user group together.

• We are actually focusing on people’s roles, authorityrelationships, hob status and functions, informationrequirements, and interpersonal relationships.

• Information of this kind highlights the organization chartand establishes a basis for determining the importance of theexisting system for the organization.

• In summary, the major focus is to find out what people theanalyst is going to be dealing with and what each person expectsto get out of a candidate systems before it goes though designand final implementation.

• Once such information is secured, the next step is to showhow various jobs hang together within work schedules andprocedures.

Information about Work Flow\Workflow focuses on what happens to the data though variouspoints in a system. This can be shown by a data flow diagram ora system flowchart. A data flow diagram represents the information generated at eachprocessing point in the system and the direction it takes fromsource to destination.In contrast, a system flowchart described the physical system. Theinformation available from such charts explains in the proceduresused for performing tasks and work schedules. Details on chartsare converted.

Theorganization

Userstaff

The work itself

Information

Information-Gathering Methods

Review literature, procedures and forms

On-site observation

InterviewsInformation gathering tools

Data organization

Questionnaires

Where Does Information Originate ?• Information is gathered from tow principal sources: personnel

or written documents from within the organization and fromthe organization’s environment. The primary external sourcesare :

1. Vendors2. Government documents3. Newspapers and professional journals.Ø The primary internal sources are:1. Financial reports.2. Personnel staff.3. Professional staff (legal counsel, EDP [electronic data

processing] auditor, etc).4. system documentation or manuals.5. The user of user staff.6. Reports and transaction documents.• Hardware vendors are traditional sources of information about

systems and software. Other equipment manufactures provideinformation about competitive system’s A third source thathas experienced tremendous growth during the past decade isthe software house.

• There are thousands of software packages on the market tosuit virtually every problem area with reasonable modifications.

• Independent listings of software packages and their vendorsare available through associations such as computerworld andDATAPRO, or other organizations with experience in theapplication under consideration.

• Other external sources if information are governmentdocuments, technical newspaper, and professional journal.Computerwrold, for example, provided weekly informationabout new hardware, hardware installations, softwaredevelopments, and trends in the field.

• Articles are also published in system development,documentation, and EDP journals, such as Communicationsof the ACM and Journal for System Management. They provideinvaluable updates in the system area.

104

• Internal sources of information are limited to the user staff,company personnel, and various reports. User personnel arethe font-line contacts for acquiring and validating informationabout a system.

• An important sources of information is the key employeewho has been in the user area for years and is familiar withpresent activities and applications. As we shall se in some cases,that is the only source available to the analyst.

Information-gathering ToolsØ No two projects are ever the same. This means that the analyst

must decide on the information gathering tool and how itmust be use.

Ø Although there are no standard rules for specifying their use,an important rule is that information must be acquired accurately,methodically, under the right conditions, and with minimuminterruption to user personnel.

Ø For example, if the analyst need only information available inexisting manuals, then interviewing is unnecessary except wherethe manual is not up to date. If additional information isneeded, on-site observation or a questionnaire may beconsidered. Therefore, we need to be familiar with variousinformation-gathering tools. Each tool has a special function,depending on the information needed.

Review of Literature, Procedure, and Forms

• Very few system problems are unique. The increasing numberof software packages suggests that problem solutions arebecoming standardized.

• Therefore, as a first step, a search of the literature thoughprofessional references and procedures manuals, textbooks,company studies, government publications, or consultantstudies may prove invaluable.

• The primary drawback of this search is time. Often it is difficultto get certain reports. Publications may be expensive, and theinformation may be outdated due to a time lag in publication.

• Procedures manuals and forms are useful sources for he analyst.They describe the format and functions of the present system.

• Included in most manuals are system requirements that helpdetermine however various objectives are met. Up-to-datemanuals save hours of information-gathering time.Unfortunately in many cases, manuals do not exist or areseriously out of date.

• Included in the study of procedures and manuals is close lookat existing forms. Printed forms are widely used for capturingand providing information.

• The objective is to understand how forms are use.The following questions may be useful.1. Who uses the form(s) ? How important are they to the user?2. Do the forms include all the necessary information ? What

items should be added or deleted?3. How many departments receive the existing form(s) ? Why?4. How readable and easy to follow is the form?5. How does the information in the form help other users make

better decisions? What other uses does the form offer the userarea?

Review• Intial Investigation• Fact Finding Techniques• Observation• Interview• Investigation• Questionnaire

Questions1. Why is it difficult to manage system development?

2. What important information does the user’s request formprovide? Why is it so important in the initial investigation?

3. Why is it difficult to determine user requirements? IIustrate

Describe about input/output analysis.

What is the difference between Open ended and Closed endedQuestions asked in an interview?What are some of the disadvantages of interviewing?Where structured analysis used in the system specification?Compare Waterfall and Iterative Enhancement model.

105





quantitative techniquesNew Delhi : Galgotia Publications, 1997

Hawryszkiewycz, IgorIntroduction to systems analysis & design

4th ed. New Delhi : Prentice Hall of India, 2002Awad, Elias M.


New Delhi : Galgotia Publications, 1997Heuring, Vincent P.


Whitten, Jeffrey L.Systems analysis and design methods




Website Addresseswww.scit.wlv.ac.ukwww.privcom.gc.cawww.conferences.global-investor.comwww.umsl.edu

Notes

106

LESSON 21 :FACT FINDING TECHNIQUES

Topics Covered• Onsite Observation• Observation methods• Interview and Questionnaires (In Detail)

Objectives

Upon completion of this Lesson, you should be able to:

• Explain about the onsite observation method• Discuss the Problems in observation method• Describe about the method interviewing• Discuss the advantage of interview• Recollect the fact finding method which we have gone through

in the previous Lesson before reading this Lesson

On-Site Observation• Another information-gathering tool used in system studies is

one-site observation. It is the process of recognizing and notingpeople, objects, and occurrences to obtain information.

• The analyst’s role is that of an information seeker who isexpected to be detached (therefore unbiased) from the systembeing observe.

• This role permit participation with the user staff openly andfreely.

• The major objective of on-site observation is to get as close aspossible to the “real” system being studied.

• For this reason it is important that the system.• For example, if the focus of the analysis is communication,

one needs to know as much s possible about the modes ofcommunication available though the organization structureand the aspects of the physical layout that might adverselyaffect communication.

The following questions can serve as a guide for on-siteobservations.1. What kind of system is it? What does it do?2. Who runs the system? Who are the important people in it?3. What is the history of the system? How did tit get to its

present stage of development?4. Apart form its formal function, what kind of system is it in

comparison with other systems in the organization? Is it fastpaced or is it a leisurely system that responds slowly to externalcrises?

• As an observer , the analyst follows a set of rules. While makingobservations, he/she is more likely to listen than talk and tolisten with a sympathetic and genuine interest wheninformation is conveyed.

• The emphasis is not on giving advice or passing moraljudgment on what is observed.

• Furthermore, care is taken no to argue with the persons beingobserved or to show hostility toward one person and unduefriendliness toward another.

When human observers are used, four alternative observationmethods are considered :

Natural or contrived.• A natural observation occurs in a setting such as the employee’s

place of work; a contrived observation is et up by the observerin place lie a laboratory.

Obtrusive or unobtrusive.• An obtrusive observation takes place when the respondent

knows he/she is being observed; an unobtrusive observationtakes place in a contrived way such as being a one-way mirror.

Direct or indirect.• A direct observation takes place when the analyst actually

observes the subject or the system at work. In an indirectobservation, the analyst uses mechanical devices such as camerasand videotapes to capture information.

Structured or unstructured.• In a structured observation the observer looks for and records

a specific action such as the number of soup cans a shopperpicks up before choosing one.

• Unstructured methods place the observer in a situation toobserve whatever might be pertinent at the time.

• Any of these methods may be use in information gathering.Natural direct, obtrusive, and unstructured observation arefrequently used to get an overview of an operation.

• The degree of structure is increased when observations have aspecific purpose. An example is tracing the rout of a salesinvoice though a system.

• The degree of obtrusiveness may decrease when one wants ofobserve the tasks that make up a given job.

• For example the analyst may want to create a list of the activitiesof production supervisor by observing him/her form a remotelocation. Indirect observation could be used in a similar manner.

• For instance, the daily routine of a bank teller may be observedindirectly via a video camera.

• Finally, contrived situations re used to test or debug a candidatesystem. They are also used in training program to help evaluatethe progress of trainees.

• Electronic observation and monitoring methods are becomingwidely used information-gathering tools because of their speed,efficiency, and low cost.

107

• For example, some truck fleets use an electronic recorder systemthat records, analyzes, and reports information (online) aboutthe hours and minutes a vehicle was driven faster than 60 milesper hour, the number of hours an engine was idle in a day, andhow much out-of-service time a vehicle had.

• These and other electronic methods expedite the information-gathering process in systems analysis.

On-site observations are not without problems1. Intruding into the user’s area often results in adverse reactions

by the staff. Therefore, adequate preparation and training areimportant.

2. Attitudes and motivations of subjects cannot be readilyobserved only the actions that result from them.

3. Observation are subject to error due to the observer’smisinterpretation and subjective selection of what to observe, as well as the subjects’ altered worked pattern duringobservation.

4. Unproductive, long hours are often spent in an attempt toobserve specific, one-time activities or events.

In deciding to use an on-site Observation, SeveralQuestions are Considered

1. What behavior can be observed that cannot be described inother ways?

2. What data can be obtained more easily or more reliably byobservation than by other means?

3. What assurances can be given that the observation process isnot seriously, affecting the system or the behavior beingobserved?

4. What interpretation needs to be made about observationaldata to avoid being misled by the obvious?

5. How much skill is required and available for the actualobservation?

• For on-site observation to be done properly in a complexsituation it can be very time-consuming.

• Proper sampling procedures must be used to ascertain thestability of the behavior being observed.

• Without a knowledge of stability, inferences drawn from smallsamples of behavior (small time slices) can be inaccurate.

Interviews and Questionnaires• As we have seen, on-site observation is directed primarily toward

describing and understanding event as they occur. It haslimitations when we need to learn about people’s perceptions,feelings, or motivations, however.

• Therefore, other information-gathering tools are also use foranalysis.

• Information-gathering tools fan be categorized by their degreeof directness. If we wish to know about something, we simplyask someone about it directly, but we may not get an answer.

• Most of the information-gathering tools used in system analysisare relatively direct. This is a strength because much of theinformation needed can be acquired by direct questions.

• There is information of a more difficult nature that user staffmay be reluctant opt give directly, however-for example,information on company politics or satisfaction with thesupervisor.

• When asked by direct questions, the respondent may yieldinformation that is invalid; yet properly handled, informationcan be successfully obtained with interviews or questionnaires.

Interviews• The interview is a face-to-face interpersonal role situation in

which a person called the interviewer asks a person beinginterviewed questions designed to gather information about aproblem area.

• The interview is the oldest and most often used device forgathering information in system work. It has qualities thatbehavioral and on-site observations do not possess.

It can be used for Two Main Purposes

(1)As an exploratory device to identify relations or verifyinformation, and

(2)To capture information as it exists.• Validity is no small problem. Special pains are taken to eliminate

interview bias.• We assume that information is more valid, the more freely it is

given.• Such an assumption stressed the voluntary character of the

interview as a relationship freely and willingly entered into bythe respondent.

• If the interview is considered a requirement, the interviewermight gain the respondent’s time and attention, but cannot becertain of the accuracy of the information gathered during theinterview.

• In an interview, since the analyst (interviewer) and the personinterviewed meet face to face, there is an opportunity forflexibility in eliciting information.

• The analyst is also in a position to observe the subject.• In contrast, the information obtained though a questionnaire

is limited to the subject’s written responses to predefinedquestions.

There are four primary advantages of heinterview1. Its flexibility makes the interview a superior technique for

exploring areas where not much is known about what questionto ask or how to formulate questions.

2. It offers a better opportunity than the questionnaire to evaluatethe validity of the information gathered. The interviewer canobserve not only what subject say but also how they say it.

3. It is an effective technique for eliciting information aboutcomplex subjects and fro probing the sentiments underlyingexpressed opinions.

4. Many people enjoy being interviewed, regardless of the subject.They usually cooperate in a study when all they have to do istalk. In contrast, the percentage of returns to a questionnaire isrelatively low: oven less than 20 percent. Attractive designedquestionnaires that are simple to return, easy to follow, and

108

presented in a context that inspires cooperation improve thereturn rate.

• The major drawback of the interview is he long preparationtime. Interviews also take a lot of time to conduct, whichmeans time and money. So whenever a more economicalalternative captures the same information, the interview isgenerally not used.

The Art of Interviewing• “Interviewing an art”. Few analysts learn it in school, but most

of them develop expertise though experience thoughexperience.

• The interviewer’s art consists of creating a permissive situationin which the answers offered are reliable.

• Respondents’ opinions are offered with no fear of beingcriticized by others.

• Primary requirements for a successful interview are to create afriendly atmosphere and to put the respondent at ease.

• Then the interview proceeds with asking questions properly,obtaining reliable responses, and recording them accurately andcompletely.

Arranging the Interview• The interview should be arranged so that the physical location,

time of he interview, and order of interviewing assure privacyand minimal interruption.

• Usually a neutral location that is non-threatening to therespondent is preferred.

• Appointments should be made well in advance and a fixedtime period adhered to as closely as possible.

• Interview schedules generally begin at the top of theorganization structure and word down so as not to offendanyone.

Guides to a Successful Interview• Interviewing should be approached as logically as

programming.

In an Interview, the following steps should be Taken

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.

Stage setting• This is an “ice breaking,” relaxed, informal phase where the

analyst opens the interview by focusing on(a)the purpose of the interview,(b) why the subject was selected, and(c) the confidential nature of the interview.

• After a favorable introduction, the analyst asks the first questionand the respondent answers and goes right through theinterview.

• The job of the analyst should be that of a reporter rather thana debater.

• Discouraging distracting conversation controls the directionof the interview.

• During stages setting the interview3r evaluated the cooperationof the interviewee.

• Both the content and tone of the responses are evaluated.• How well the interview goes depends on whether the

interviewee is the friendly type, the timid type who needs to becoaxed to talk, or the resident expert, who bombards the analystwith opinions disguised as facts.

• In any case, the analyst adjusts his/her own image to counterthat of he interviewee.

Establishing Rapport• In one respect, data collection is an imposition on user staff

time and an intrusion into their privacy.• Even though the procedure is authorized by management in

advance, many staff members are reluctant to participate.• There is seldom a direct advantage I n supplying information

to outsiders, regardless of their credentials. There is a strongperception that it may do them harm.

• This factor makes it important to gain and maintain rapportwith the user staff.

• The investigation is an art.Although there are no ground rules to follow, there arepitfallsto avoid.

a. Do not deliberately mislead the user staff about the purposeof the study. A careful, well-thought-out briefing of participantsshould not provide any more detail than is necessary. Too muchtechnical detail may tend to confuse people. The briefing shouldbe consistent for all participants to avoid rumors.

b. Assure interviewees confidentiality that no information theyoffer will be released to unauthorized personnel. The promiseof anonymity is very important.

c. Avoid personal involvement in the affairs of the user’sdepartment or identification with one faction a the cost ofanother. This may be difficult when several groups are involvedin the study.

d. Avoid show in off you knowledge or sharing informationreceived from other sources.

e. Avoid acting like an expert consultant. This can reduce theobjectivity of the approach and discourage people form freelygiving information.

f. Respect the time schedules and preoccupations of your subjects.Do not make an extended social event out of the meeting. Ifthe subject does nto complain, subordinates might, especiallyif they are waiting to see the subject (boss).

g. Do not promise anything you cannot or should not deliver,such as advice or feedback.

h. Dress and behave appropriately for the setting and thecircumstances of the user contact.

i. Do not interrupt the interviewee. Let him/her finish talking.

109

Asking the questions• Except in unstructured interviews, it is important that each

question is asked exactly as tit is worded. Rewording orimprompt explanation may provoke a different answer or biasthe response.

• The questions must also be asked in the same order as theyappear on the interview schedule.

• Reversing the sequence could destroy the comparability of theinterviews.

• Finally, each question must be asked unless the respondent, inanswering a previous question, has already answered the nextone.

Obtaining and recording the response• Interviewers must be prepared to coax respondent to elicit

further information when necessary. The “probing” techniqueenables the interviewer to act as a catalyst, for example:

Interview: I see what you men. Could you elaborate further onthat?Analyst (interviewer): How do you feel about separating the presentloan division into commercial and loan departments?Financial vice president (respondent): well, I’m not sure.Sometimes I think that we have to take this route eventually.Analyst: I see. Can you tell me more about that?• These statements indicate that the analyst is listening, is

interested, understands what the respondent is trying to say,and is making an effort to gain more information. Theinformation received during the interview is recorded for lateranalysis.

Data recording and the notebook.• Many system studies fail because of poor data recording. Care

must be taken to record the data, their source, and time ofcollection.

• If there is no record of a conversation, the analyst runs the riskof not remembering enough details, attributing them to thewrong source, or otherwise distorting the data.

• The form of the notebook varies according to the type ofstudy, the amount of data, the number of analysts, and theirindividual preferences.

• The “notebook” may be a card file, a set of carefully coded filefolders, or a loose-leaf binder. It should be bound and thepages numbered.

Data Capture and the Notebook1. Originals or duplicate copies of all notes taken during

investigation are documented. They are the chief sources ofinterview and observational data, as well as backgroundinformation on the system. Each page of notes should benumbered serially, and a running chronological record of themshould be kept. The name of the analyst, the date the noteswere taken, and surrounding circumstances are all important.Since handwritten notes often are not intelligible to others. Itis good to have them transcribed or typed soon after they aretaken.

2. Copies of all information-gathering tools – questionnaires,interview schedules, observation guides – are placed in thenotebook for future reference.

3. Copies of all data- originals or duplicates – are include. Loss ofkey data, even temporarily, can be costly.

4. Minutes of all meetings as well as a record of discussion,decisions, and changes in design all become part of thenotebook.

• The organization of the notebook is also important. In somecases, a purely chronological arrangement will suffice.

• In others, system of categories with cross-classification wouldbe appropriate.

• Proper indexing makes it easier to retrieve information whenneeded.

Review

Onsite ObservationObservation methodsProblems in observation methodInterviewAdvantage of interviewing

QuestionsList the problems faced while interviewing.

A question may be closed or open ended. Illustrate the difference.

What are the advantages of interviewing?

110

References

Hoffer, Jeffrey A.

2nd ed. Delhi : Pearson Education Asia, 2000Modern systems analysis and design

Hawryszkiewycz, Igor

4th ed. New Delhi : Prentice Hall of India, 2002Introduction to systems analysis & design

Awad, Elias M.

New Delhi : Galgotia Publications, 1997Systems analysis and design

Heuring, Vincent P.

Delhi : Pearson Education Asia, 1997Computer systems design and architecture

Whitten, Jeffrey L.

5th ed. New Delhi : Galgotia Publications, 2001Systems analysis and design methods

Shelly, Gary B.

3rd ed. New Delhi : Galgotia Publications, 1999Systems analysis and design

Sarkar, A.K.

New Delhi : Galgotia Publications, 1997

Systems analysis, data processing and quantitative techniques


Notes

111


Topics Covered• Questionnaire• Types of interviews• Various types of Questions

Objectives

Upon completion of this Lesson, you should be ableto

• Differentiate various types of Interviews• Explain the types of Questions asked to collect data .Also you

should be able to differentiate the types.

Questionnaires• In contrast to the interview is the questionnaire, which is a

term used for almost any tool that has questions to whichindividuals respond. It is usually associated with self-administered tools with items of the closed or fixed alternative

type.

By its nature, a questionnaire offers the followingadvantage

1. It is economical and requires less skill to administer than theinterview.

2. Unlike the interviews, which generally questions one subject ata time, a questionnaire, can be administered to large numbersof individuals simultaneously.

3. The standardized wording and order of the questions and hestandardized instruction for reporting response ensureuniformity of questions. In contrast, the interview situationis rarely uniform form one interview to the next.

4. The respondents feel greater confidence in the anonymity ofquestionnaire than in that of an interview. In an interview, theanalyst usually knows the user staff by name, job function, orother identification. With a questionnaire, respondents giveopinions without fear that the answer will be connected totheir names.

5. The questionnaire places les pressure on subjects for immediateresponses. Respondents have time to think the questions overand do calculations to provide more accurate data.

• The advantage of the self-administered questionnaireoutweigh disadvantage, especially when cost is a consideration.The principal disadvantage is a low percentage of returns.

• Another disadvantage is that many people have difficultyexpressing themselves in writing, especially when respondingto east (open) questions. Many dislike writing. Because of thesedisadvantages, the interview is probably superior to thequestionnaire.

Types of Interviews and Questionnaires

• Interviews and questionnaires vary widely in form and structure.Interviews range from the highly unstructured, where neitherthe questions nor the respective responses are specified inadvance, to the highly structured alternative in which thequestions and response are fixed. Some variation within thisrange is possible.

The Unstructured Alternative• Ø In unstructured interview is a relatively nondirective

information-gathering technique. It allows respondent toanswer questions freely in their own words.

• The responses are spontaneous rather than forced.• They are self-revealing and personal rather than general and

superficial.• The role of the analyst an interview is to encourage the

respondent to talk freely and serve as a catalyst to the expressionof feeling and opinions.

• This is best achieved in a permissive atmosphere in which thesubjects have no feeling of disapproved.

• The Structured Alternative• In the structured approach, the questions are presented with

exactly the same wording and in the same order to all subjects.• If the analyst asks a subject, “Would you like to see a

computerized approach to solving your accounts receivableproblem?” and asks another subject,” How do you feel aboutcomputers handling accounts receivable?” the response maynot be the same even though the subjects both have the sameopinion. Standardized questions improve the reliability of heresponses by ensuring that all subjects are responding to thesame questions.

• Structured interviews and questionnaires may differ in theamount of structuring of the questions.

• Questions may be either closed or open-ended. An open-endedquestion requires no response direction or specific response. Ina questionnaire, it is written with space.

Examples of open-Ended Questions• Now that you have had the new installation for six months,

how would you evaluate the benefits?• What is your opinion regarding the “no smoking” policy in

the DP center?• If you had a choice, how would you have designed the present

information center?

Examples of Fill-in-the Blank of your Questions

• What is the name of the MIS director of your firm.• How many analysis handle the accounts receivable conversion?• What is the average number of calls you receive from clients ?

112

Provided for the responseSuch questions are more often used in interviews than inquestionnaires because scoring takes time.• Closed questions are those in which the responses are presented

as set of alternatives.

These are five major varieties of closedquestions1. Fill-in-the blanks questions request specific information .These

responses can then be statistically analyzed.2. Dichotomous (yes/no type) questions that offer two answers

have advantage similar to those of the multiple-choice type(explained later). The problem is making certain that a reliableresponses can be answered by yes or no; otherwise, andadditional choice (e.g. yes no, I don’t know) should be included.The questions sequence and content are also important.

3. Ranking scales questions ask the respondent to rank a list ofitems in order of importance or preference. The first questionsasks the respondent to rank five statements on the basis ofhow they describe his/her present job.

4. Multiple-choice questions offer respondents specific answerchoices . This offers the advantage of faster tabulation and lessanalyst bias due to the order in which the answers are given.Respondents have a favorable bias toward the first alternativeitem. Alternating the order in which answer choices are listedmay reduce bias but at the expense of additional time to respondto the questionnaire. In any case, it is important.

Examples of Dichotomous Questions• Are you personally using a microcomputer in your business?

(please circle one yes no• If not, do you plan to be using one in the next 12 months?

(please circle one) yes no.• In the performance of your work, are you personally involved

in computer hardware/software purchase decisions? (pleasecircle one) yes no.

An Example of a Ranking Scales Questions

• Please rank the five statements in each group on the basis ofhow well they describe the job mentioned on the front page.Write a “1” by the statement that best describes the job; write a“2” by the statement that provides the next best description,and continue ranking all five statements, using a “5” for thestatement that describes he fob least well.

• Workers on this job…..— Are busy all the time.— Have work where they do things for other people.— Try out their own ideas.— Are paid well in comparison with other workers.— Have opportunities for advancements.To be aware of these types of bias when constructing multiple-

choice questions.5. Rating scales questions are an extension of the multiple-choice

design. The respondent is offered a range of responses along asingle dimension.

Open-ended and closed questions have advantages and limitations.Open-ended questions are ideal in exploratory situation wherenew ides and relationships are sought. The main drawback is thedifficulty of inter-

Examples of Multiple-Choice Questions• What is the average salary of an entry-level analyst? (Please

check one)• Under $15,000• $15,000-$19,999• $20,000-$24,999• Over $25,000• Please check one category that best describes the business of

the firm where you are employed.• Saving bank• College, school, library, association• Computer service

Industrial company• Outside computer consulting• Other (please describe)

An Example of Rating Scale Question

• How satisfied are you with the following aspects of you presentjob? (Please Circle one for each question)

Very

Dissatisfied

Dissatisfied No

Opinion

Satisfied Very

Satisfied

1. They way my job

provides for steady

employment

1 2 3 4 5

2.The chance to be

responsible for the

work of others.

1 2 3 4 5

3.The pleasantness of

the working

conditions.

1 2 3 4 5

4. The chance to make

use of my best

abilities.

1 2 3 4 5

• Interpreting the subjective and the tedious responses to open-ended questions. Other drawback include potential analyst biasin interpreting the data and time-consuming tabulation.

• Closed questions are quick to analyze but typically most costlyto prepare. They are move appropriate for securing factualinformation (for example, about age, education, sex, and salary).

• They have the additional advantage of ensuring that answersare given in frame of reference consistent with the line ofinquiry.

113

Structured and Unstructured InterviewTechnique

Interview

Type

Advantage Drawback

Structured I. Easy to administer and

evaluate due to

standardization

II. Required limited training

III. Easy to train

new staff

I. High initial preparation cost

II. Standardization of questions tends to

reduce spontaneity

III. Mechanizes interviewing, which makes

it impractical for all interview settings

Unstructured � Provides for greater

creativity and spontaneity

in interviewing

� Facilities deeper

understanding of the

feeling and standing of the

interviewee

� Offers greater flexibility

in conducting an overall

interview

� More information of questionable use is

gathered

� Takes more time to conduct-therefore,

costly

� Requires extensive training and

experience for effective results.

Procedure for QuestionnaireConstructionThe procedure for constructing a questionnaire consists of sixsteps:1. Decide what data should be collected; that is, define the problem

to be investigated.2. Decide what type of questionnaire (closed or open-ended)

should be used.3. Outline the topic for the questionnaire and then write the

question.4. Edit the questionnaire for technical defects or biases that reflect

personal values.5. Pretest (try out) the questionnaire to see how well in works.6. Do a final editing to ensure that the questionnaire is ready for

administration. This include a close look at the content, form,and sequ3ence of questions as well as the appearance andclarity of the procedure for using the questionnaire.

Ø A critical aspect of questionnaire construction is the formulationof reliable and valid question.

Ø To do a satisfactory job, the analyst must focus on questioncontent, wording, and format. The following is a checklist ofwhat to consider.

1. Question contenta. Is the question necessary? Is it a part of other questions?b. Does the question adequately cover the area intended?c. Does the subject(s) have proper information to answer the

question?d. Is the question biased in a given direction?e. Is the question likely to generate emotional feelings that might

lead to untrue responses?

2. Question wording.

a. Is the question worded for the subject’s background andexperience?

b. Can the question be misinterpreted? What else could it meanto a respondent?

c. Is the frame of reference uniform for all respondents?d. Is the wording biased toward a particular answer?e. How clear and direct is the question?3. Question Format.a. Can the question best be asked in the form of check

answer(answered by a word or two or by a number) or with afollow-up free answer?

b. Is the response from easy to use or adequate for the job?c. Is the answer to the question likely to be influenced by the

preceding question? That is, is there any contamination effect?

Reliability of Data from Respondents.• The data collected from the user staff are presumed to accurately

correspond with the actual way in which events occur.• If such reports are the only source of data, there may be several

uncontrolled sources of error :1. The respondent’s perceptual slant. Perceptual ability is known

to vary. Reports of a given event from several staff memberswho have no training in careful observation often have littleresemblance to one another.

2. The respondents failure to remember just what did happen.Assuming that he or she received a fairly reliable impression ofan event at the time that it happened, it generally become moredifficult with the passage of time to describe the details of anevent.

3. Reluctance of persons being interviewed to report their “true”impressions of what occurred. A subject often distortsdescriptions of events for fear of retaliation, a desire not toupset others, or a general reluctance to verbalize a particulartype of situation.

4. Inability of subjects to communicate their reports or inabilityof the analyst to get from subjects the information that theyare qualified to provide.

The Reliability-Validity Issue• An information-gathering instrument faces two major tests:

reliability and validity. Before administering the instrument,the analyst must ask and answer the questions: What is thereliability of the measuring instrument? What is its validity?

• The term reliability is synonymous with dependabilityconsistency, and accuracy. Concern of reliability comes from thenecessity for dependability in measurement. Using thequestionnaire as an example, reliability may be approached inthree ways:

1. If we administer the game questionnaire to the same subject,will we get the same or similar results? This question implies adefinition of reliability as stability, dependability, andpredictability.

114

2. Does the questionnaire the true variables it is designed tomeasure? This question focuses on the accuracy aspect ofreliability.

3. How much error of measurement is there in the proposedquestionnaire? Errors of measurement are random errorsstemming from fatigue or fortuitous conditions at a giventime, or fluctuation in mood that extent that errors ofmeasurement that errors of measurement are present in aquestionnaire. To the extent that errors of measurement arepresent in a questionnaire, it is unreliable. Thus, reliability isviewed as the relative absence of errors of measurement in ameasuring instrument.

• To illustrate, suppose we administered a questionnaire tomeasure the attitude of the user staff toward a new computerinstallation. The “true” scores of the five staff members wear92 (excellent attitude), 81, 70, 59, and 40. Suppose further thatthe same questionnaire was administered again to the samegroup within the same time period and the scores were 96, 82,69, 61, and 55. Although not a single case hit the “true” scoreagain, the second test showed he same rank order. The reliabilityin these examples is extremely high.

• Now suppose that the last set of scores had been 72, 89, 51, 74,and 67. They are the same five scores, but they have a differentrank order. In this case, the test is unreliable. There are threesets of scores. The rank orders of the first two sets of scoresvary exactly. Even though the test scores in the tow column arenot the same, they are in the same rank order. To this extent,the test is reliable. The opposite case is shown in column (1)and (3). The rank order changed, making the test unreliable.

• It can be seen, the, that for an information-gathering instrumentto be interpretative, it must be reliable.

• Unreliable measurement is overloaded with error. Althoughhigh reliability is no guarantee of good questionnaire results,there can be no good results without reliability. It is a necessary,but not sufficient, condition for the value of questionnaireresults and their interpretation.

• The most common question that defines validity is : Does theinstrument measure what we think it is measuring?

• It refers to the notion that the questions asked are worded toproduce the information sought. In contrast, reliability meansthat the information gathered is dependable enough to beused for decision making. Invalidity, the emphasis is on whatis being measured.

• For example, an analyst administers a questionnaire to a usergroup to measure their understanding of a billing procedureand has included in the questionnaire only factual items thatidentify the parts of the billing system.

• The questionnaire is not valid because, whereas it m ay measureemployees’ factual knowledge of the billing system, it doesnot measure their understanding of it.

Reliable and unreliable Test Scores

1 2 3

“True”

Scores

Ra

nk

Scores from

Reliable

Questionnaire Rank

Scores f rom

Unreliable

Questionnaire Rank

92

81

70

59

40

1

2

3

4

5

96

82

69

61

55

1

2

3

4

5

72

89

51

74

67

3

1

5

2

3

• The analyst intended to measure. For this reason, it is importantto pretest a questionnaire for validity as well as for reliability.

• It can be concluded, then that the adequacy of an information-gathering tool is judged by the criteria of validity and reliability.Both depended on the design of the instrument as well as theway it is administered.

Review

QuestionnaireTypes of questionsTypes of interviews

Questions1. Differentiate each types of Questions.

2.Explain about the types of interviewing method to collect data.

115

References

Sarkar, A.K.


Systems analysis, data processing and quantitative techniques

Hawryszkiewycz, Igor

4th ed. New Delhi : Prentice Hall of India, 2002Introduction to systems analysis & design

Awad, Elias M.

New Delhi : Galgotia Publications, 1997Systems analysis and design

Heuring, Vincent P.

Delhi : Pearson Education Asia, 1997Computer systems design and architecture

Whitten, Jeffrey L.

5th ed. New Delhi : Galgotia Publications, 2001Systems analysis and design methods

Shelly, Gary B.

3rd ed. New Delhi : Galgotia Publications, 1999Systems analysis and design

Hoffer, Jeffrey A.

2nd ed. Delhi : Pearson Education Asia, 2000Modern systems analysis and design


Notes

116


Topics Covered• Brainstroming• Delphi Method

ObjectivesUpon completion of this Lesson, you should be able to:v

Explain the about the brainstormingv

Explain about Delphi method

Decision Making VS Problem SolvingWhat is the difference between decision making and problemsolving?

• Decision making - you choose from alternatives• Problem solving - you determine the response that will alleviate

a problem

Decisions

Programmed

• Routine• Repetitive• Follow established procedures.

Non Programmed

• Little or no precedent.• Unstructured.• Follow your philosophy.

Three stages of decision making (Herbert Simon)

1. Intelligence“Information is Power”

2.Design”Think out of the Box”

3.Choice”What makes or breaks you”

Intuitive ApproachDecisions made under reactions to emotion, hunches, or “gutfeelings” are risky.

Emotions can rule these decisions.

Odiorne identified five emotional attachments thatcan hurt decision makers:

Fastening on unsubstantiated facts and sticking with them.Being attracted to scandalous issues and heightening theirsignificance.Pressing every fact into a moral pattern.Overlooking everything except the immediately useful.Having an affinity for romantic stories and finding suchinformation more significant than any other kind, including hardevidence.

Decision Situatio• ns• Certainty - outcomes are known in advance.• Risk - some idea of the probabilities associated with the different

outcomes is known.Uncertainty - very little or no information on outcomes.

117

Decision making by Groups

Advantages

• Greater knowledge.• Wider range of alternatives.• Increased acceptance of groups decision by members.• Group members better understand the decision and the

alternatives.• Most important - avoids more mistakes.

Disadvantages• One individual may dominate and/or control.• Pressure to conform.• Competition can develop and slant the process.• Tend to accept the first solution and not give as much

consideration to the other alternatives.• Most important - speed of process is reduced.

Four barriers to effective decisionmaking1. Complacency2. Defensive avoidance3. Panic4. Deciding to decide

Aids to creativity• Brainstorming - pre senting a problem to a group of people

and allowing them to present ideas to its solution.• Gordon Technique - similar to brainstroming but no one except

the group leader knows the exact nature of the real solution.• Brainwriting - group members jot down their ideas in response

to a problem situation without discussion. Anonymously,papers are exchanged with others who add their thoughts and

repeat the process until all have participated.

The Delphi Method

Definition and Historical Background• The objective of most Delphi applications is the reliable and

creative exploration of ideas or the production of suitableinformation for decision making.

• The Delphi Method is based on a structured process forcollecting and distilling knowledge from a group of experts bymeans of a series of questionnaires interspersed with controlledopinion feedback (Adler and Ziglio, 1996).

• According to Helmer (1977) Delphi represents a usefulcommunication device among a group of experts and thusfacilitates the formation of a group judgement. Wissema (1982)underlines the importance of the Delphi Method as amonovariable exploration technique for technology forecasting.

• He further states that the Delphi method has been developedin order to make discussion between experts possible withoutpermitting a certain social interactive behavior as happens duringa normal group discussion and hampers opinion forming.

• Baldwin (1975) asserts that lacking full scientific knowledge,decision-makers have to rely on their own intuition or on expertopinion. The Delphi method has been widely used to generateforecasts in technology, education, and other fields (Cornish,1977).

• The technology forecasting studies which eventually led to thedevelopment of the Delphi method started in 1944. At thattime General Arnold asked Theodor von Karman to prepare aforecast of future technological capabilities that might be ofinterest to the military (Cornish, 1977).

• Arnold got the Douglas Aircraft company to establish in 1946a Project RAND (an acronym for Research and Development)to study the “broad subject of inter-continental warfare otherthen surface.”

• In 1959 Helmer and fellow RAND researcher Rescher publisheda paper on “The Epistemology of the Inexact Sciences,” whichprovide a philosophical base for forecasting (Fowles, 1978).

• The paper argued that in fields that have not yet developed tothe point of having scientific laws, the testimony of experts ispermissible. The problem is how to use this testimony and,specifically, how to combine the testimony of a number ofexperts into a single useful statement.

• The Delphi method recognizes human judgement as legitimateand useful inputs in generating forecasts. Single expertssometimes suffer biases; group meetings suffer from “followthe leader” tendencies and reluctance to abandon previouslystated opinions (Gatewood and Gatewood, 1983, Fowles,1978).

• In order to overcome these shortcomings the basic notion ofthe Delphi method, theoretical assumptions andmethodological procedures developed in the 1950s and 1960sat the RAND Corporation.

• Forecasts about various aspect of the future are often derivedthrough the collation of expert judgement. Dalkey and Helmerdeveloped the method for the collection of judgement forsuch studies (Gordon and Hayward, 1968).

• Fowles (1978) asserts that the word Delphi refers to thehallowed site of the most revered oracle in ancient Greece.Forecasts and advices from gods were sought throughintermediaries at this oracle.

• However Dalkey (1968) states that the name “Delphi” wasnever a term with which either Helmer or Dalkey (the founders

118

of the method) were particularly happy. Dalkey (1968)acknowledged that it was rather unfortunate that the set ofprocedures developed at the RAND Corporation, and designedto improve methods of forecasting, came to be known as“Delphi”.

• He argued that the term implies “something oracular,something smacking a little of the occult”, whereas, as a matterof fact, precisely the opposite is involved; it is primarily concernedwith making the best you can of a less than perfect kind ofinformation.

• One of the very first applications of the Delphi method carriedout at the RAND Corporation is illustrated in the publicationby Gordon and Helmer (1964). Its aim was to assess thedirection of long-range trends, with special emphasis on scienceand technology, and their probable effects on society.

• The study covered six topics: scientific breakthroughs;population control; automation; space progress; war prevention;weapon systems (Gordon and Helmer, 1968). The first Delphiapplications were in the area of technological forecasting andaimed to forecast likely inventions, new technologies and thesocial and economic impact of technological change (Adler andZiglio, 1996).

• In terms of technology forecasting, Levary and Han (1995)state the objective of the Delphi method as to combine expertopinions concerning the likelihood of realizing the proposedtechnology as well as expert opinions concerning the expecteddevelopment time into a single position.

• When the Delphi method was first applied to long-rangeforecasting, potential future events were considered one at atime as though they were to take place in isolation from oneanother.

• According to Wissema (1982), unfortunately the Delphimethod is also sometimes used for a normal inquiry among anumber of experts. Delphi has found its way into industry,government, and finally, academe. It has simultaneouslyexpanded beyond technological forecasting (Fowles, 1978).

• Since the 1950s several research studies have used the Delphimethod, particularly in public health issues (such as, policiesfor drug use reduction and prevention of AIDS/HIV) andeducation areas (Adler and Ziglio, 1996; Cornish, 1977).

The Basics of the Delphi Method• The Delphi method is an exercise in group communication

among a panel of geographically dispersed experts (Adler andZiglio, 1996). The technique allows experts to deal systematicallywith a complex problem or task.

• The essence of the technique is fairly straightforward. Itcomprises a series of questionnaires sent either by mail or viacomputerized systems, to a pre-selected group of experts.

• These questionnaires are designed to elicit and developindividual responses to the problems posed and to enable theexperts to refine their views as the group workprogresses inaccordance with the assigned task.

• The main point behind the Delphi method is to overcome thedisadvantages of conventional committee action. According

to Fowles (1978) anonymity, controlled feedback, and statisticalresponse characterize Delphi.

• The group interaction in Delphi is anonymous, in the sensethat comments, forecasts, and the like are not identified as totheir originator but are presented to the group in such a way asto suppress any identification.

• In the original Delphi process, the key elements were (1)structuring of information flow, (2) feedback to the participants,and (3) anonymity for the participants. Clearly, thesecharacteristics may offer distinct advantages over theconventional face-to-face conference as a communication tool.

• The interactions among panel members are controlled by apanel director or monitor who filters out material not relatedto the purpose of the group (Martino, 1978). The usualproblems of group dynamics are thus completely bypassed.Fowles (1978) describes the following ten steps for the Delphimethod:

1. Formation of a team to undertake and monitor a Delphi on agiven subject.

2. Selection of one or more panels to participate in the exercise.Customarily, the panelists are experts in the area to beinvestigated.

3. Development of the first round Delphi questionnaire4. Testing the questionnaire for proper wording (e.g., ambiguities,

vagueness)5. Transmission of the first questionnaires to the panelists6. Analysis of the first round responses7. Preparation of the second round questionnaires (and possible

testing)8. Transmission of the second round questionnaires to the

panelists9. Analysis of the second round responses (Steps 7 to 9 are

reiterated as long as desired or necessary to achieve stability inthe results.)

10. Preparation of a report by the analysis team to present theconclusions of the exercise

• Delbecq et al., (1975) argue that the most important issue inthis process is the understanding of the aim of the Delphiexercise by all participants. Otherwise the panelists may answerinappropriately or become frustrated and lose interest.

• The respondents to the questionnaire should be well informedin the appropriate area (Hanson and Ramani, 1988) but theliterature (Armstrong, 1978; Welty, 1972) suggest that a highdegree of expertise is not necessary. The minimum number ofparticipants to ensure a good group performance is somewhatdependent on the study design.

• Experiments by Brockhoff (1975) suggest that under idealcircumstances, groups as small as four can perform well.

• Before deciding whether or not the Delphi method should beused, it is very important to consider thoroughly the contextwithin which the method is to be applied (Delbecq et al. 1975).

• A number of questions need to be asked before making thedecision of selecting or ruling out the Delphi technique (Adlerand Ziglio, 1996):

119

• What kind of group communication process is desirable inorder to explore the problem at hand?

• Who are the people with expertise on the problem and whereare they located?

• What are the alternative techniques available and what resultscan reasonably be expected from their application?

• Only when the above questions are answered can one decidewhether the Delphi method is appropriate to the context inwhich it will be applied. Adler and Ziglio (1996) further claimthat failure to address the above questions may lead toinappropriate applications of Delphi and discredit the wholecreative effort.

• The outcome of a Delphi sequence is nothing but opinion.• The results of the sequence are only as valid as the opinions of

the experts who made up the panel (Martino, 1978). The panelviewpoint is summarized statistically rather than in terms of amajority vote.

• The Delphi method has got criticism as well as support. Themost extensive critique of the Delphi method was made bySackman (1974) who criticizes the method as being unscientificand Armstrong (1978) who has written critically of its accuracy.

• Martino (1978) underlines the fact that Delphi is a method oflast resort in dealing with extremely complex problems forwhich there are no adequate models. Helmer (1977) states thatsometimes reliance on intuitive judgement is not just atemporary expedient but in fact a mandatory requirement.

• Makridakis and Wheelright (1978) summarize the generalcomplaints against the Delphi method in terms of (a) a lowlevel reliability of judgements among experts and thereforedependency of forecasts on the particular judges selected; (b)the sensitivity of results to ambiguity in the questionnaire thatis used for data collection in each round; and (c) the difficulty inassessing the degree of expertise incorporated into the forecast.Martino (1978) lists major concerns about the Delphi method:

• Discounting the future: Future (and past) happenings are notas important as the current ones, therefore one may have atendency to discount the future events.

• The simplification urge: Experts tend to judge the future ofevents in isolation from other developments. A holistic viewof future events where change has had a pervasive influencecannot be visualized easily. At this point cross-impact analysisis of some help.

• Illusory expertise: some of the experts may be poor forecasters.The expert tends to be a specialist and thus views the forecastin a setting which is not the most appropriate one.

• Sloppy execution: there are many ways to do a poor job.Execution of the Delphi process may loose the requiredattention easily.

• Format bias: it should be recognized that the format of thequestionnaire may be unsuitable to some potential societalparticipants.

• Manipulation of Delphi: The responses can be altered by themonitors in the hope of moving the next round responses ina desired direction.

• Goldschmidt (1975) agrees that there have been many poorlyconducted Delphi projects. However, he warns that it is afundamental mistake to equate the applications of the Delphimethod with the Delphi method itself, as too many critics do.

• There is, in fact, an important conceptual distinction betweenevaluating a technique and evaluating an application of atechnique.

• On the other hand there have been several studies (Ament,1970; Wissema, 1982; Helmer, 1983) supporting the Delphimethod.

• A study conducted by Milkovich et al. (1972) reports the use ofthe Delphi method in manpower forecasting. The results ofthe comparison indicated high agreement between the Delphiestimate and the actual number hired and less agreementbetween quantitative forecasts and the number hired. Anotherstudy by Basu and Schroeder (1977) reports similar results in ageneral forecasting problem.

• They compared Delphi forecasts of five-year sales with bothunstructured, subjective forecasts and quantitative forecasts thatused regression analyses and exponential smoothing. TheDelphi forecasting consisted of three rounds using 23 keyorganization members. When compared against actual salesfor the first two years, errors of 3-4% were reported for Delphi,10-15% for the quantitative methods, and of approximately20% for the previously used unstructured, subjective forecasts.

• In general, the Delphi method is useful in answering one,specific, single-dimension question. There is less support forits use to determine complex forecasts concerning multiplefactors. Such complex model building is more appropriate forquantitative models with Delphi results serving as inputs(Gatewood and Gatewood, 1983). This point is supported byGordon and Hayward (1968) who claim that the Delphimethod, based on the collation of expert judgement, suffersfrom the possibility that reactions between forecasted itemsmay not be fully considered. The need for the cross impactmatrix method of forecasting integrated with the Delphimethod is pointed out by many researchers (Gordon andHayward, 1968; Gatewood and Gatewood, 1983; Adler andZiglio, 1996). An improvement in forecasting reliability overthe Delphi method was thought to be attainable by taking intoconsideration the possibility that the occurrence of one eventmay cause an increase or decrease in the probability of occurrenceof other events included in the survey (Helmer, 1978). Thereforecross impact analysis has developed as an extension of Delphitechniques.

Review

BrainstromingDelphi method

120

Questions1. Explain about brainstorming with an example.

Describe about the history about Delphi method



2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.Systems analysis, data processing and






New Delhi : Galgotia Publications, 1997Heuring, Vincent P.








Notes

121

LESSON 24 :FLOW DIAGRAMS

Topics covered• Flow Graph• Produce Flow Graph

ObjectivesUpon completion of this Lesson, you should be able to:• Create flow graph for the given problem

Flowgraph analysis• A flowgraph analysis is concerned with statically determining

the number of different paths by which flow of control canpass through an algorithm.

• It can be argued that a developer or maintainer must be able toconceptualise the flow of control through an algorithm inorder to fully understand its dynamic behaviour.

• Unless such an understanding is available the developer willnot be able to fully predict the dynamic behaviour of thesoftware and thus will not be able to ensure that all possiblecontingencies are allowed for in its design or implementation.

Producing a simple flowgraphAlthough a flowgraph analysis can be made at the design stagethis lesson will concentrate upon the production of flowgraphsfrom source code, as this is a pre-requisite for the technique ofwhite box testing.0014 function SquareRoot( Number : in FLOAT;0015 Accuracy : in FLOAT) return FLOAT is00160017 MaximumValue : FLOAT;0018 MinimumValue : FLOAT;0019 CurrentGuess : FLOAT;0020 CurrentGuessSquared : FLOAT;0021 CurrentError : FLOAT;0022 CloseEnough : BOOLEAN := FALSE;00230024 begin — SquareRoot0025 if Number > 1.0 then0026 MaximumValue := Number;0027 MinimumValue := 0.0;0028 else0029 MaximumValue := 1.0;0030 MinimumValue := Number;0031 end if;0032 while not CloseEnough loop0033 CurrentGuess := (MaximumValue +

MinimumValue) / 2.0;0034 CurrentGuessSquared := CurrentGuess *

CurrentGuess;0035 CurrentError := abs( Number+

CurrentGuessSquared);0036 if CurrentError <= Accuracy then0037 CloseEnough := TRUE;

0038 else0039 if CurrentGuessSquared >= Number then0040 MaximumValue := CurrentGuess;0041 else0042 MinimumValue := CurrentGuess;0043 end if;0044 end if;0045 end loop;0046 return CurrentGuess;0047 end SquareRoot;• The first stage in constructing a flowgraph is to note that at

some stage flow of control will enter the subprogram and willat some stage leave the subprogram. This produces an initialflowgraph as follows.

• A flowgraph consists of a number of nodes, shown as circlescontaining identifying letters, connected by arcs which havearrows indicating the direction in which flow of control willpass.

• The flowgraph above indicates that flow of control enters thesubprogram at node a, flows through the arc and leaves atnode b. The construction of the flowgraph continues by refiningthe flow of control within the subprogram, between points aand b.

• Refinement proceeds by dividing the implementation into partswhere flow of control has a single entry and exit point. In theSquareRoot function there is a sequence of four parts.

The first part comprises the declaration and initialisation of thelocal variables between lines 0017 and 0024, the second comprisesthe if structure between lines 0025 and 0031, the third is the whileloop between lines 0032 and 0045 and the last is the single returnstatement on line 0046. The flowgraph can be refined to reflectthese three regions of code, producing the following flowgraph.

122

• The four parts where flow of control enters and leaves areshown between nodes a and c, c and d, d and e and between eand b.

• The first and last of these arcs require no further refinement asthey represent regions where simple sequences of instructions,within which flow of control moves sequentially frominstruction to instruction.

• The second arc requires further refinement which can proceedby substituting the standard two way flowgraph for the arcbetween c and d. The standard two way flowgraph is as follows.

• Flow of control enters the flowgraph at node s and leaves atnode t, following one of the two arcs connecting the nodes.

• This flowchart can be used to represent flow of control throughif statements of the following forms.

— One way if structure — Two way if structureif Condition then if Condition then — Actions. — First actions.end if; else

— Second actions.end if;

• For the one way if structure flow of control can cause theActions to either be performed or omitted. For the two way ifstructure flow of control can cause either First actions or Secondactions to be performed.

• The two possible flows of control are represented by the twoarcs connecting the nodes. For more complex sequential selection

structures, for example an elsif structure or a case structure ofthe following forms, a more complex flowgraph would berequired.

• — Three way elseif structure — Three way case structure• If FirstCondition then case SelectionValue is• — First actions. when => FirstValueList• Elsif SecondCondition then — First actions.• — Second actions. when=> SecondValueList• Else — Second actions.• — Third actions. when others =>• End if; — Third actions• End case;

• Additional elsif options or case options in the sequentialselection structures will cause additional arcs connecting thetwo nodes to be added. Inserting a two way selection flowgraphinto the SquareRoot flowchart to represent the two way ifstructure between lines 0025 and 0031, will produce thefollowing flowgraph.

• Refinement continues with the arc between nodes d and ewhich represent the while loop in the implementation. Thestandard loop flowgraph is as follows.

• Flow of control can pass straight from node l to node mwithout following the circular arc back to the node.

123

• This would be the case for a while loop if the first time thecondition controlling the loop was tested, it evaluated false. Ifa for loop was being represented then flow of control wouldavoid the circular route if the loop conditions were such thatthe body of the loop was not executed.

• The circular route represents the body of the loop and incircumstances where flow of control enters the loop body arepresentation of flow of control would indicate that node lwas visited more than once indicating that the circular arc wasfollowed. Inserting the standard loop flowgraph into theSquareRoot flowchart produces the following refinement.

• The construction of the flowgraph continues by the refinementof the body of the loop. The first refinement would divide itinto a sequence of two parts, the first is the sequence ofstatements between lines 0026 and 0028.

• The second part is the nested if statements between lines 0029and 0037. Substituting a flowgraph representing a sequence oftwo parts into the arc which represents the body of the loopproduces the following flowgraph.

• The arc between d and f represents a sequence of simpleinstructions and requires no further refinement, the arc betweenf and d represents the nested if statement which will have tobe refined in two stages.

• The first stage of refinement will substitute a standard twoway selection flowgraph to represent the outermost if,producing the following flowgraph.

• The final refinement will replace one of the arcs between f andd with a two way flowgraph to represent the two way if structureon lines 0039 to 0043.

• The final, completely refined, flowchart for the SquareRootfunction is as follows.

Flowgraph complexity analysis• The complete flowgraph which has been produced by successive

refinement from the source code now indicates all the possible

124

paths by which flow of control can pass through the SquareRootfunction.

• In its current state it provides a simple pictorial representationof the dynamic complexity of the subprogram, which can becompared visually with other flowgraphs to compare the relativecomplexity of two or more subprograms.

• A more satisfactory approach to deriving a measure ofcomplexity from a flowgraph would require some measurementof the graph.

• The most obvious measurement might be to count the numberof nodes and the number of arcs. In the final SquareRootflowgraph above there are 8 nodes and 10 arcs. Each noderepresents a location within the software where a simplesequential flow of control joins with another simple sequentialflow of control and each arc represents the flow of controlthrough a simple sequence.

• Although a count of the number of arcs and nodes givessome indication of the complexity of a flowgraph, the realindication of the software’s complexity is in the topologicalrelationship of the nodes and arcs.

• The topology of a graph is the number of non connected areason the graph, each non-connected area is known as a regionand number of regions is independent of the precise way inwhich the graph is laid out.

• The following three flowcharts have a similar number of nodesand arcs, but the two right hand flowcharts intuitively have agreater complexity than the left hand chart as they have a greaternumber of regions.

• The left hand flowgraph has four nodes and three arcs, themiddle four nodes and four arcs and the right hand flowgraphthree nodes and three arcs.

• The relationship between the number of arcs and the numberof nodes is significant. Where a flowgraph has one fewer arcsthan nodes it can be argued that every arc must connect onenode with another node, without any two nodes beingconnected by more than one arc. This will produce a flowgraphconsisting of a single region, as shown on the left handflowgraph above.

• Continuing the argument it can be shown that there can neverbe less than this number of arcs as this would result in somenodes being unconnected with the rest of the flowgraph.

• The situation where there are as many arcs as nodes producesflowgraphs such as the two right hand graphs above whereone arc must either duplicate an existing connection betweentwo nodes or define a loop arc connecting a node to itself. Inboth cases the additional arc has changed the topology of thegraph by defining a region within the graph.

• It can be shown that for every additional arc above the numberof nodes another closed region is added to the graph. Thefollowing sequence of flowgraphs illustrate that adding arcsincreases the number of regions.

• Thus the number of regions in a flowgraph is the mostimportant indicator of complexity and can be derived either bycounting the number of regions on the flowgraph, includingthe external region in the count.

• Alternatively the number of nodes and arcs can be countedand the number of regions decided by using the formula

regions = arcs - nodes + 2

• This measure of the complexity of an algorithm, the numberof regions in its flowgraph, is known as McCabes complexitymetric.

• Although this technique established a metric for the complexityof an algorithm, it does not give any indication of theappropriate complexity which should be aimed for. Cognitivepsychologists have determined that a human is only capable ofmaintaining and manipulating cognitive models which containseven plus or minus two, i.e. between five and nine, cognitivechunks of information.

• Assuming that a region on a flowgraph is equivalent to acognitive chunk then it can be concluded that subprogramsshould not be constructed which contain more than a maximumof about nine regions and preferably should be limited to lessthan seven.

ReviewFlow Graph AnalysisProducing Flow GraphFlowgraph complexity analysis

QuestionsDiscuss about Flow graph analysis1

125

2345

Produce a flow graph for a sequence of code of your own choice.1234

5







3rd ed. New Delhi : Galgotia Publications, 1999Bennett, Simon

Object-oriented systems analysis and

Design using UML

2nd ed. New Delhi : McGraw Hill Book, 2002Booch, Grady

Object-oriented analysis anddesign : with applications

2nd ed. Reading : Addison-Wesley Publishing, 2000Hoffer, Jeffrey A.


2nd ed. Delhi : Pearson Education Asia, 2000Kain, Richard Y.

Advanced computer architecture :

A systems design approch

New Delhi : Prentice Hall of India, 1996Sima, Dezso

Advanced computer architectures :A design space approch

Delhi : Pearson Education Asia, 1997Sarkar, A.K.








Notes

126

LESSON 25 :STANDARD DOCUMENTATION TECHNIQUE

Topics covered• Standard documentationTechnique

ObjectivesUpon completion of this Lesson, you should be able to:• Explain about Standard Documentation.

SOFTWARE LIFE-CYCLESElements and DefinitionsLifeCycle

ANSI / IEEE Std 729-1983

• A life-cycle is– a period of time that– starts when a software product is conceived and– ends when the product is no longer available for use.• Organised in phases

2

Requirements

System Design

Detailed Design

Implementation

Installation & Testing

Maintenance

TheWATERFALL

LIFE-CYCLE

Phases of a Life-Cycle• Requirements• System Design• Detailed Design• Implementation• Testing & Installation• Operations & Maintenance• Retirement

==> results (= inputs & outputs): documentsð verify transformations at milestones

Documentation==> supported by standards• Internal technical documentation:– The results of each phase– The rationale and assumptions behind the decisions

Made in each phase– Layouts and results of tests– Error & fixes log• External technical documentation:– System structure– Required environment– Instructions for installation– Maintenance & operation– Guidelines for trouble shooting• End-user documentation:– User handbook– Quick reference– Guided tour– Standard set-up

Milestone• A scheduled event– For which some project member or manager is

Accountable and– That is used to measure progress.• Supported by standards

Standards•Project independent–rules and procedures–embedded in a common system of terms–and quality criteria–that ensure inter-project adaptability–and compatibility of solutions.•Important organisations: ANSI, IEEE

127

14

Requirements

System Design

Detailed Design

Implementation

Installation & Testing

Maintenance

TheWATERFALL

LIFE-CYCLE

Standards

Milestones

Documents

Introduction to the CommunicationProcessØ In its most basic form, communicating involves a sender who

takes his/her thoughts and encodes them into verbal andnonverbal messages that are sent to a receiver .

Ø The receiver then decodes the messages and attempts tounderstand what the sender meant to communicate.

Ø The communication process is completed when the receivertransmits verbal and nonverbal feedback to indicate his/herreception and understanding of the message.

Ø This process takes place within a context, also known as arhetor i ca l s i tuat ion , which includes all that affects thecommunication process such as the sender-receiver’s culture,the sender-receiver’s relationship, the circumstances surroundingthe sender-receiver’s interaction, and the physical environmentof the interaction.

Ø Because the basic communication process is the same in everysituation, there are some similarities across all types ofinteractions. Just the same, each interaction remains distinctand therefore each rhetorical situation will be different.

Ø For example, think about how you communicate with anotherperson in the library and at a party.

Ø In both cases you are sending messages and reacting to feedback.Ø But the the rhetorical situation of the library means that you

will be speaking in whispers, whereas at the party you will bespeaking much louder and with more animated gestures.

Ø If you were to switch styles—whispering at the party and yellingat the library—then your communication style would beineffective to say the least. In both situations you are engagingin the same communication process, but the rhetorical situationsrequire you to act in different ways.

The Communication Process and PublicSpeaking• By focusing on the process of communication and the rhetorical

situation, a speaker can maximize the effectiveness of messages.• This means that an effective speaker doesn’t “write” a speech in

isolation and then simply stand up and deliver it. Instead, aneffective speaker develops messages in relation to the situation,the audience, and the communication goals.

• Throughout the semester we will go into more detail abouthow to do this, but for now it is important to understand thefollowing:

What the sender intends to communicate is notalways what the receiver decodes.

• The communication process can break down in any number ofways, and an effective speaker should not take the audience’sunderstanding of messages for granted.

• An effective speaker makes sure to learn all that is possibleabout the audience and to adapt the message to that audience.

“Actions speak louder than words.”Non-verbal messages are usually believed more than verbalmessages.

• When there is a conflict between nonverbal and verbal messages,the audience tends to believe the nonverbal. An effective publicspeaker makes sure that the nonverbal messages complimentand strengthen the verbal messages.

More Communication does not EqualBetter Communication.• What’s the use of more communication if it is ineffective or

bad communication? An effective public speaker focuses onthe quality of communication, not the quantity.Becoming an Effective Listener

• Listening is a vital skill, not only for this class but for life ingeneral. Becoming an effective communicator starts withbecoming a better listener.

• The main thing to remember is that hearing does not equallistening. Hearing is a physiological process that involves thereception of vibrations by the delicate structures within ourears.

• Listening is a psychological process that involves theinterpretation of what we hear. Hearing is passive—it take noeffort on our part, while listening is active—it take effort and awillingness to tune in.

• One of the most important parts of public speaking is learninghow to listen to or read your audience.

• This means being able to observe and to utilize the feedbackfrom the audience. Being a good listener also helps in thedevelopment of your speech because it allows you to gainskills in analyzing messages and retaining information.

• So how do you start improving your listening skills? The key isto actively focus on your listening behavior, and to starteliminating behaviors that lead to poor listening. These negativebehaviors include:

128

· Mentally jumping to conclusions before the other person hasfinished speaking.

· Focusing on how the person communicates rather than what isbeing communicated.

· Starting to think of a response before the other person hasfinished a thought.

· Being aware of such behaviors, and actively trying to eliminatethem is a major step toward being a more effectivecommunicator.

ReviewStandard documentation

System Life cycleBecoming an effective public speaker starts with an understandingof the communication process and the listening process. Eventhough the process of communicating is similar in all interactions,each specific situation will require you to make several choicesabout how to get your message across.

QuestionsDescribe about the communication process.

1

234

5

Relate the SDLC with dcumentation.

1

234

5

References0Heuring, Vincent P.







Object-oriented systems analysis andDesign using UML


Object-oriented analysis and

Design : with applications




Advanced computer architecture :A systems design approch


Advanced computer architectures :

A Design space approch



Quantitative techniques






129

SYSTEM

S AN

ALY

SIS

LESSON 26 :OVERVIEW DATA AND FUNCTIONAL

MODELLING

Topics covered• Overview of data and functional modelling

OBJECTIVESUpon completion of this Lesson, you should be able to:• Function diagram• DFD

Overview of functional and datamodelling• This deals with techniques applied in information system

analysis, data modeling and normalization.• This Lesson shows a process of providing full specification of

systems to users to help them consider and accept.• This specification is also a major information source for

designers of the new system.• It not only specifies the system’s objectives but also describes

the work and its constraints to which designers have to comply.

Analysis of structured system• This part discusses the process of system analysis, analysis

methods and tools supporting the analysis of data collected inprevious surveys.

Overview of system analysis• System analysis is a relatively young field in mankind’s

knowledge but demand for system analysis existed manycenturies before the introduction of computers.

• In mid 19 century, practitioners in labor, organization andmethodology had established many improved methods ofworking.

• This is the first approach to system analysis.• With the development of information technology, system

analysis science also develops more and more vigorously andhas a significant role in a life cycle of an IT application and ofIT projects in general.

• At the moment, there is no method that ensures success andthat can be viewed as a “right” way for analysis but theapplication of structured system analysis increases the chanceof success for most of typical applications and it proves efficientin a range of analysis in real life.

• Until today, system approach is still viewed as a soundfoundation for structured system analysis.

• Structural system analysis is a modern approach to differentanalysis and design phrases of the system development process

which is accepted because of its strong points over othertraditional approaches.

The structural system analysis has the followingmain characteristics:

• The system is developed in the top - down order;• During system analysis and design, several tools, techniques

and models are used to record and analyze the current systemand new requirements of users, and define a format for thefuture system;

• The major tools used in structural system analysis include:function diagram, data flow diagram, data dictionary, processspecification, Entity-Relationship diagram;

• Separation between physical model ad logical model. A physicalmodel is often used in surveying the current system anddesigning the new system while a logical model is used inanalyzing system’s requirements. This is a significant advantagebrought about by the structural system analysis method;

• Acknowledging users’ role in different steps of systemdevelopment;

• Different steps in structural analysis and designing can be carriedout at the same time rather than in one by one order. Each stepcan improve the analysis and designing made in a previousstep;

• Structural analysis is supported by advanced technology in bothhardware and software, therefore system development withthis method is less complicated;

• Structural analysis when put together with the prototypemethod can help users and analysts have an idea of the newsystem and help make best use of both methods.

Two models of structural system analysis

Waterfall Model

• Has been a basis for a majority of structural system analysismethods since the 1970s. This model consists of differentphases carried out one after the other. Each phase can be assignedto a group of experts.

Spiral model• Initiated by Barry Boehm, has become more and more popular

and a basis to iterative development systems.• This approach also consists of various phases carried out one

after the other as in the Waterfall model.• However, the system development process is divided into

different steps and smoothened after repetitive steps, the systembecomes more perfect after each repetitive steps.

CHAPTER IIISYSTEM INVESTIGATION

130

• In this model, system developer can hand system’s functionsover to users more frequently rather than giving them all thefunctions at the end of the development process.

Nature of analysis• Analysis is the focus of system developing and is the stage

when system designers have to work at two levels of definitionregarding the study of situational issues and possible solutionsin terms of “what to do” and “how to do”.

System analysis process in its most general formincludes the following main step:

• Identify the operation of the existing system;• Understand what the existing system is doing;• Understand the need of the users;• Decide on what the new system should be doing;• Decide on how the new system will function.• In the process of system analysis, it is not always possible to

study every aspect of each of the above steps and this is thetime to pay attention to the following:

• If the method of working applied to participants of systemdevelopment (users, analysts, designers, and programmers) isefficient?

• If the update of changes that happen in the process of systemdevelopment is touched upon;

• Tool for analysis;• If workload allocation is reasonable? (Users have to take part

in 2 systems (old and new) at the same time);• If documents are easy to understand to all participants?

Importance of analysis in system’s life cycle

• A system’s analysis and development life cycle include thefollowing tasks: survey, analysis, design, implementation,system testing and approving, installation and maintenance.

• Main subjects in the whole life cycle of the system are: users,mangers and technical experts including analysis, design andprogram specialist...)

• The primary purpose of the analysis activity is to transform itstwo major inputs, users policy and system charter, intostructured specification. This involves modeling the users’environment with functioning diagrams, data diagrams, entity-relationship diagrams and the other tools of the system analysis.

• The quality of system analysis can have a big effect on speed ofsystem designing, the programming and time for testing because50 per cent of faults in the system originated from shortcomingsin system analysis.

• Programmers can complain about slow speed of work becausethey have to review analysis and designing.

• This shows the bad quality of system analysts (because ofinadequate experience or improper working attitude).

• Moreover, speed of system analysis activities is also a veryimportant issues because there are always complaints abouttime, etc. And the products of the system analysts are oftenspecification description and diagrams of technical nature andthese are not highly valued.

• For users, what they care about is what functions the programcan perform if it meets the professional need dictated by thesystem, if its reliability is prove while testing with real figures,if the interface is users-friendly.

• Analysis plays a very important part in the life cycle of thesystem because this activity relates to almost all other activitiesand all subjects participated in the system.

Role and requirement of system analysts• The system analyst is a key member of any systems

development project. In a broader sense, the systems analystplays several roles:

• Archaeologist and scribe: As a systems analyst, one of the mainjobs is to uncover detail and to document business policy thatmay exist only as “tribal folklore”, passed down fromgeneration to generation of users.

• Innovator: The systems analyst must separate the symptomsof the user’s problem from the true causes. With his or herknowledge of computer technology, the analyst must help theuser explore useful, new applications of computers.

• Mediator: The system analyst who often finds himself in themiddle of users, managers, programmers, auditors and variousother players, all of whom frequently disagree with one another.

• Project leader: Because the systems analyst is usually moreexperienced than the programmers on the project and since heis assigned to the project before the programmers beginworking, there is a natural tendency to assign projectmanagement responsibilities to analyst.

This Means that, as a Systems Analyst,you Need• More than just the ability to draw flowchart and other technical

diagrams;• Skills to interview users, mediate disagreements;• Application knowledge to understand and appreciate the user’s

business;• Computer skills to understand the potential uses of computer

hardware and software in the user’s business;• Able to view a system from many different perspectives;• Able to partition it into levels of subsystems;• Able to think of a system in abstract terms as well as physical

terms.

Popular methods of system analysis• In the following presentation, you will be introduced to using

a range of tools and techniques that enable analysts to have abetter understanding and to find a solution for every singlecase of application.

• The usage of tools and techniques forms an approach namedstructure system analysis.

• Structure system analysis originated from observations thatprinciples of structure programming can also applied to analysisand designing stage.

The moving towards structure system analysis canbe explained by the following description:

131

Graphic: composed of variety of diagrams, supported by detailedtextual material that, in many cases, serves as reference materialrather than the main body of the specification.Partitioned: so that individual portions of the specification can beread independently of other piece.Minimally redundant: so that changes in the user requirementscan usually be incorporated in just one part of the specification.This approach is now used in the majority of systems developmentorganizations, as well as a large number of engineering-orientedorganizations.Tools supporting analysis: Functioning diagram, data flowdiagram, and relationship diagram...• In the process of system analysis, analysts often construct

models to give an overview or stress on aspects of the wholesystem. This enables analyst to contact users in the best wayand when users’ need is changed, it is possible to modify orconstruct a new model.

Analysts use model to• Concentrate on important features of the system, pay less

attention to less important ones;• Be able to respond to changes or changes in user’s requirements

with low cost and risk;• Properly understand users’ environment and write documents

in the same way that designers and programmers construct thesystem.

Three important modeling tools used insystem analysis isFunctional diagram (FD)

• A functional diagram is used to show system’s functions thatwill be constructed and the implementation process of datadiagram. Moreover, function diagram will also be used todetermine the appearance frequency of smaller process in thedata flow chart.

• If during the construction of functional diagram, analystsidentify new functions, the analysts need to determine if it is awrong move to ignore the discovered functions. It is necessaryto decide to add or remove in the most appropriate way.

• Functional analysis with the help of modeling tools providesimportant details that will be used often in later stages ofanalysis.

• With detailed job description, information processing andexchanging process, input and output of every function willhelp analysts understand more clearly system’s requirements.

• However, it is necessary to note that function approach to issueis not a comprehensive approach.

• A function diagram only shows what to do not how to do. Ina functional diagram, a function is divided into many smallerfunctions and each smaller function contains many even smallerones.

Constructing diagram is a process of division, from a higherfunction to appropriate smaller functions. Diagrams need to bepresented clearly, simply, exactly, and fully and balanced. Functionof the same level has the same level of difficulty need to be on thesame page.

In the current example, the function hierarchydiagram is as follows

Data flow DiagramDescribe the information flow in the system The next step ofsystem analysis is to consider in detail the information necessaryfor the implementation of functions discussed above and theone necessary for the improvement of the functions. Modelingtool frequently used for this purpose is data flow diagrams.

Data flow diagram will support 4 main activities

• Analysis: DFD is used to determine requirements of users.• Design: DFD is used to map out plan and illustrate solutions

to analysts and users while designing a new system.• Communication: One of the strength of DFD is its simplicity

and ease to understand to analysts and users;• Documents: DFD is used to provide special description of

requirements and system design. DFD provide an overview ofkey functional components of the system but it does notprovide any detail on these components. We have to use othertools like database dictionary, process specification to get anidea of which information will be exchanged and how.

The data dictionary is an organized listing of all the data elementspertinent to the system, with precise, rigorous definitions so thatboth user and systems analyst will have a common understandingof all inputs, outputs, components of stores, and intermediatecalculations.

The data dictionary defines the data elements by doing thefollowings

• Describing the meaning of the flows and stores shown in thedata flow diagrams;

• Describing the composition of aggregate packets of datamoving along the flow;

• Describing the composition of packets of data in stores;

132

• Specifying the relevant values and units of elementary chunksof information in the data flows and data stores.

• Describing the details of relationships between stores that arehighlighted in an entity-relationship diagram.

The system analysis can ensure that the dictionary is complete,consistent, and non-contradictory. He can examine the dictionaryon his own and ask the following questions:• Has every flow on the data flow diagram been defined in the

data dictionary?• Have all the components of composite data elements been

defined?• Has any data element been defined more than once?• Has the correct notation been used for all data dictionary

definition?• Are there any data elements in the data dictionary that are not

referenced in the functioning diagrams, data flow diagrams, orentity-relationship diagrams.

Building a data dictionary is one of the more important aspectsand time consuming of systems analysis. But, without a formaldictionary that defines the meaning of all the terms, there can beno hope for precision.

The process specificationAs we know, there are a variety of tools that we can use to producea process specification:Decision tables, structured English, pre/post conditions,flowcharts, and so on. All most systems analysts use structuredEnglish. But, any method can be used as long as it satisfies twoimportant requirements:• The process specification must be expressed in a form that can

be verified by the user and the systems analysts;• The process specification must be expressed in a form that can

be effectively communicated to the various audiences involved.The process specification represents the largest amount of detailedwork in building a system model. Because of the amount ofwork involved, you may want to consider the top – downimplementation approach: begin the design and implementationphase of your project before all the process specifications havebeen finished.The activity of writing process specifications regarded as a check ofthe data flow diagrams that have already developed. In the writingprocess specifications, you may discover that the processspecifications needs additional functions, input data flow or outputdata flow...Thus, the DFD model may be changed, revisions, and correctionsbased on the detailed work of writing the process specifications.

Data flow diagram can be described inthe following ways• What functions should the system perform?• Interaction between functions?• What does the system have to transfer?• What inputs are transferred to what outputs?• What type of work does the system do?

• Where does the system get information from to work?• And where does it give work results to?

Regardless of the ways it is described, the data flowdiagram needs to meet the followingrequirements:

• Without explanation in words, the diagram can still tell thesystem’s functions and its information flowing process.Moreover, it must be really simple for users and systems analyststo understand.

• The diagram must be balancely laid out in one page (for smallsystems) and in every single page showing system’s functionsof the same level (for larger systems).

It is best for the diagram to be laid out with computer supportingtools, because that way the diagram will be consistent andstandardized. Also, the adjustment process (when needed) will bedone quickly and easily.

ReviewRole of AnalystPopular method of system analysisData Flow diagramFunctional diagram, Data dictionary

QuestionsDiscuss about Data Flow diagram

1

234

5

Produce a Functional diagram with a real system

1

234

5

133









Design using UML











A design space approch









Notes

134

LESSON 27 :DATA FLOW DIAGRAM

Topics covered• Data Flow Diagram

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the various notation used in the DFD

The main components of data flowdiagram are• The process: The process shows a part of the system that

transforms inputs into outputs; that is, it shows how one ormore inputs are changed into outputs. Generally, the process isrepresented graphically as a circle or rectangle with rounded edges.The process name will describe what the process does.

• The flow: The flow is used to describe the movement ofinformation from one part of the system to another. Thus,the flow represents data in motion, whereas the stores representdata at rest. An arrow into or out of a process represents a flowgraphically.

• The store: the store is used to model a collection of data packetsat rest. Two parallel lines represent a store graphically. The nameof a store identified the store is the plural of the name of thepackets that are carried by flows into and out of the store.

• External factors: External factors can be a person, a group ofpersons or an organization that are not under the studyingfield of the system (they can stay in or out of the organization),but has certain contact with the system. The presence of thesefactors on the diagram shows the limit of the system andidentifies the system relationship to the outside world. Externalfactors are important components crucial to the survival ofevery system, because they are sources of information for thesystems and are where system products are transferred to. Anexternal factor tends to be represented by an rectangle, oneshorter edge of which is omitted while the other is drawn by aduplicated line.

• Internal factors: While the external factors’ names are alwaysnouns showing a department or an organization, internalfactors’ names are expressed by verbs or modifiers. Internalfactors are systems’ functions or process. To distinguish itselffrom external factors, an internal factor is represented by anrectangle, one shorter edge of which is omitted while the otheris drawn by a single line.

You can construct DFD model of systemwith the following guidelines

How to Draw Data Flow Diagrams (DFD)

What are Data Flow Diagrams?Data flow diagrams illustrate how data is processed by a system interms of inputs and outputs.

A data flow diagramData Flow Diagram NotationsYou can use two different types of notations on your data flowdiagrams:Yourdon & Coad or Gane & Sarson.Process Notations

Yourdon and CoadProcess Notations

Gane and SarsonProcess NotationDatastore Notations

Yourdon and CoadDatastore Notation

ProcessA process transforms incomingdata flow intooutgoing data flow.

135

Gane and SarsonDatastore NotationsDataflow Notations

External Entity Notations

• Choose meaningful names for processes, flows, stores, andterminators

• Number of processes• Re-draw the DFD many times• Avoid overly complex DFD• Make sure the DFD is consistent internally and with any

associated DFDTo recap, DFD is one of the most important tools in a structuredsystem analysis. It presents a method of establishing relationshipbetween functions or processes of the system with information ituses. DFD is a key component of the system requirementspecification, because it determines what information is neededfor the process before it is implemented.Many systems analysts reckon that DFD is all they need to knowabout structured analysis. On the one hand, this is because DFDis the only thing that a systems analyst remembers after reading abook focussing on DFD or after a course in structured analysis.On the other hand, without the additional modeling tools suchas Data Dictionary, Process Specification, DFD not only can’t showall the necessary details, but also becomes meaningless and useless.

ReviewData Flow Diagram

Questions

DataStoreDatastores are repositories ofdata in the system. They aresometimes also referred to asfiles.

DataflowDataflows are pipelines throughwhich packets of information flow.Label the arrows with the name ofthe data that moves through it.

External EntityExternal entities are objectsoutside the system, withwhich the system communi-cates. External entities aresources and destinations ofthe system’s inputs andoutputs.

Discuss about various notation used in DFD

1

234

5

1.Precision Tools sells a line of high quality woodworking tools.When customers place orders on the company’s website , thesystem checks to see if the items are in stock, issues a atatusmessage to the customer and generates a shipping order to thewarehouse, which fills the order. When the order is shipped ,the customer is billed. The system also produces variousreports.

(i) Draw a context diagram for the order system(ii) Draw a DFD diagram 0 for the order system(iii) Name four attributes that you can use to define a process in

the order system.(iv) Name four attributes that you can use to define an entity in

the order systemDo you think DFD’s are more appropriate to the subject, usageand system world?









Design using UML











A design space approch

136









Notes

137

LESSON 28 :DFD AND ER DIAGRAM

Topics covered• Data Flow Diagram• Entity Relationship Diagram

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the about ER DiagramIn the example of library management system, corresponding toeach level of function hierarchy diagram, we develop the data flowdiagrams:

138

SummaryAt the end of function analysis phase, we have 2 diagrams: thefunction hierarchy diagram and the data flow diagram. They willbe a basis for finding out entities and relationships between them(which is defined in the Entity-Relationship diagram).

Entity-Relationship diagram (ERD)Though the relationship among data warehouse is not emphasizedin data flow diagram, it is well reflected in ERD. When developinga new information system, analyst often has discussion with users,especially database manager, on the current system. It’s they whohave the responsibilities to collect necessary information aboutthe system required by system analyst. ERD is one of the mostuseful model forming tools to organize this discussion. ERD isnetwork model that describes stored data of a system at a highlevel of abstraction. For system analyst, ERD has a major benefit:it highlights the relationship between data stores on DFD whichwould otherwise only be seen in the specification process.

The main Components of an ERD Include

• Entity• Attribute• RelationshipEntity is a subject, a duty, or an event that has a significant meaningto the future system and is displayed by a rectangle with roundcorners. Each entity has its own name. In some cases, entities ofthe same sort can be merged into one entity type. Entity type of a system is defined base on the outcome of systemfunction analysis.The simplest approach to decide whether a type of informationshould be put in the model as a type of entity is to make up thefollowing question: Are these information tables useful for thesystem? If the answer is yes, system analyst has to identify thebasic entities that create flows in the data table.After a suitable type of entity, entity nature have been identified,the next important step is to define the information that needs tobe archived for each entity.• Attributes are the characteristics of the entity displayed by fields

or columns of a table.Relationship shows connections among the system’s entities.Triangle headed arrows display these connections.

There are 3 major Types of Relationship used in ERDs

• One - one relationship• One - many relationship• Many - many relationshipLet’s assume that we have 2 entities in tables A and table B, a one- one relationship will exist between them if:With each entity in table A, there is a corresponding entity in tableB and vice versa, with each entity in table B, there is a correspondingentity in table A. A normal connection line displays thisrelationship.

Assume that we have 2 entities in table A and table B, a one -many relationships will exist between them if:

With each entity in table A, there are several entities in table B andwith each entity in table B, there is one and only one entity in table

A. A triangle-headed connection line displays this relationship.The non-triangle headed end shows to the table with one entityand the other end shows the table with various entities.Assume that we have 2 entities in table A and table B, a many -many relationship will exist between them if:With each entity in table A, there are several entities in table B andwith each entity in table B, there are several entities in table A. Aconnection line displays this relationship with triangle at bothends.In fact, the many - many relationship is often transferred to theone - many relationship via “connection entity” with 2 upperentities.Thus, of the 3 types of relationships, the one - many relationshipis the most important and popular because the one - onerelationship can be integrated in a table, the many - manyrelationship is transferred to one - many relationship by creating a“connection entity”, which facilitates the data modeling.In the example of library management system, we see the followingrelationships:We realize that: one book or magazine (documents) must bebelong to one language, but one language can have many booksor magazines, so this relationship is one - to - many(one languagehas many documents).The similar relationships are: documents and nation, documentsand collection, documents and specialty.With the magazines: we realize that each magazine category hasmany volumes (depend on years, months, and numbers...), butone volume must be belong to one magazine category, so thisrelationship is one - to - many.The relationship between department and readers is also one -to- many relationships, because one reader must belong to one andonly one department, but one department can have many readers(staffs).

And the last relationship

the relationship between readers and documents: This is a specialrelationship: one reader can borrow many documents, and onedocument can be borrowed by many readers at different time(because, when a reader gives back a document, it can be borrowedby another reader again). So we can say that this relationship is“many - to -many” relationship, and separate it into 2 “one - to -many” relationships and one entity, the Borrowing/Returning_Ticket entity, with its primary key is the compose ofthe primary key of document entity, the primary key of readerentity, and the BORROW_DATE attribute.

So we have the Entity-Relationship diagrams asfollow

139

Mayille is a rural village with a population of 500. Until nowMayville was served by a bookmobile from a larger town. TheMayville village council has authorized funds for a small publiclibrary and you have volunteered to set up an information systemfor the library. Assume that the library will have multiple copiesof certain books.(i) Draw an ERD for the Mayille library system(ii) Indicate cardinality.Top Text Publishing is a textbook publishing company with aheadquarters location, a warehouse and three sales offices thateach have a sales offices that each have sales manager and salesreps. Top Text sells to schools, colleges and individual customers.Many authors write more than one book for Top text and somebooks are written by more than one author. Top text maintains

an active list of over 100 books each identified by a universal codecalled an ISBN number. (i) Draw an ERD for the Top Text information system (ii) Indicate cardinalityFastFlight Airlines is a small air carrier operating in threenortheastern states. FastFlight is the process of computerizing itspassenger reservation system. The following data were identified:reservation number, flight number, flight date, origin, destination,departure time, arrival time, passenger name and seat number. (i) Create an ERD, including cardinality for the reservation system.








Object-oriented systems analysis and design usingUML


Object-oriented analysis and design : withapplications




Advanced computer architecture : a systems designapproch


Advanced computer architectures : a design spaceapproch


Systems analysis, data processing and quantitativetechniques






140

LESSON 29 :OVERVIEW DATA MODELLING

Topics covered• Data modelling

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the about data modelling

Data Modelling• What is systems modeling and what is the difference between

logical and physical system models?• What is data modeling and what are its benefits?• Can you recognize and understand the basic concepts and

constructs of a data model?• Can you read and interpret a entity relationship data model?• When in a project are data models constructed and where are

they stored?• Can you discover entities and relationships?• Can you construct an entity-relationship context diagram?• Can you discover or invent keys for entities?• Can you construct a fully attributed entity relationship diagram

and describe all data structures and attributes to the repositoryor encyclopedia?

What is Data modeling?

An entity is something about which data will be stored within thesystem under consideration. In this example the data group invoicecan be identified as a system entity.The other main component on a data model is the relationshipline. A Relationship is an association between two entities towhich all of the occurrences of those entities must conform.The relationship is represented by a line that joins the two entities,to which it refers. This line represents two reciprocalrelationships:That of the first entity with respect to the second,and that of the second entity with respect to the first.Data modeling is all about identifying entities and their

relationships and then drawing a diagram that accurately depictsthe system. This applies equally to the design of a new system orthe analysis of an existing one.The end result of data modeling should be a clear picture of howinformation is stored and related within a proposed, or existing,system.

Systems Analysis EntitiesOn this we illustrate the concept of an entity, which can be appliedto almost anything that is significant to the system being studied.Some examples of information systems and entities are listedbelow:Airline system: Aircraft, Passenger, Flight, Airport.Banking system: Customer, Account, Loan.A precise definition of ‘entity’ is not really possible, as they evenvary in nature. For example, in the airline system, whilst an aircraftis a physical object (entities often are) a flight is an event and anairport is a location. However entities are nearly always those thingsabout which data will be stored within the system underinvestigation.Note that entities are always named in the singular; for example:customer, account and loan, and not customers, accounts andloans.This course uses symbols that are standard in the IT industry.This uses the soft-box symbol shown to represent an entity. If asite uses a different symbol set, this is not a problem, as datamodeling techniques are the same regardless of the symbols beingused.

Systems Analysis – Entity Types &OccurrenceSimilar entity occurrences are grouped together and collectivelytermed an entity type. It is entity types that are identified anddrawn on the data model.An entity occurrence identifies a specific resource, event, location,notion or (more typically) physical object.In this course the term ‘entity’ is, by default, referring to entitytype. The term entity occurrence will be specifically used where thatis relevant.Each entity has a data group associated with it. The elements ofthe data group are referred to as the ‘attributes ‘ of the entity. Thedistinction between what is an attribute of an entity and what isan entity in its own right is often unclear. This is illustrated shortly.

Systems Analysis– Entity NamingEntity names are normally single words and the name chosenshould be one familiar to the users. The entity name can include aqualifier in order to clarify their meaning. However, if differentnames are currently used to describe a given entity in differentareas of the organization then a new one should be chosen that isoriginal, unique and meaningful to all of the users.

141

For example, the terms ‘signed contract’, ‘sale’ and ‘agreement’might be recreated as the entity ‘completed’.Conversely an organization may be using a ‘catch all’ term todescribe what the analyst identifies as being a number of separateentities. For example the term ‘invoice’ may be being used todescribe 3 invoice types - each of which is, in fact, processed in adifferent manner.In this case prefixing the entity names with qualifiers, is likely tobe the best solution.

Systems Analysis – Entity IdentificationIt is usual for an experienced analyst to use an intuitive approachto identifying entities, in order to produce a shortlist of thingsthat could potentially be entities. The viability of each of these canthen be considered using a set of entity identification guidelines.This should result in some of them being confirmed as entities,whilst others will be rejected.In this exercise you will be asked to identify a set of potentialentities within a simple business scenario. This should help youto understand and appreciate the entity identification guidelinesbetter.Read the following case study. Study this information carefullyand see if you can identify the entities - remember that entities arethose things about which data will be stored.Make your own list of those things that you think are likely to beentities, before moving to the next screen.

Systems Analysis – Entity IdentificationCase StudyCity Cameras is an independent retailer of cameras, video-camerasand accessories. The owner fulfils the roles of shopkeeper andmanager and he purchases a variety of products from a numberof different suppliers.The owner can check on different suppliers wholesale andrecommended retail prices with reference to their price lists, asshown.During a normal day several customers will enter the shop and anumber of them will buy one or more of the products on sale.At some stage the owner may decide that one or more productlines need to be re-ordered, following a visual stock-take. He willthen consult the latest suppliers price lists to see who is offeringthe best deals on given product lines.Following this, he will ring one or more of the suppliers to ordersome of their products. At the same time he will also make awritten record of the orders that have been placed with each supplieron a separate sheet of paper. These records are then used to verifyincoming orders and invoicing details.

Systems Analysis– Entity Identification –Exercise #1With reference to the case study information, make a list of all ofthose things mentioned in the case study that could be entities -that is the potential entities.Your list should look something like that shown below:Suppliers Price List, Customer, Product, Order, Invoicing Details& Supplier

There are six potential entities listed. From this initial list we willconsider the ‘suppliers price list’ to be a likely attribute of theentity ‘supplier’. Therefore we shall consider this within the contextof the supplier entity. The ‘invoicing details’ are stated to beattributes of the ‘order record’ entity, so we shall also discountthis as a potential entity at this stage.Remember that entities are described in the singular as they relateto entity types. ‘Customer’ for example represents the entity type‘customer’ which encompasses an infinite number of ‘customer’entity occurrences.Taking these four as our list of potential entities, each will bediscussed in turn:

Systems Analysis – Entity Identification –Exercise # 2In many business systems, information about the customer is ofgreat importance. An insurance company or bank, for example,could not function without a customer database on whichcomprehensive personal details are stored. This customer databasealso serves as an essential resource for selling new financial productsand services.But how much customer information is likely to be stored by CityCameras?Are they even going to record the name & address of theircustomers?Interviews with the owner reveal the answer to be that he has noreal interest in storing ‘information’ about his customers. He onlyrecords their details onto any necessary warranty documents andthen sends these off to the appropriate supplier.Therefore, in the context of this system customer is NOT anentity.

Systems Analysis – Entity Identification –Exercise # 3It is a natural assumption that all retail businesses would hold asignificant amount of product information. However in this studythe only level of product information is that which is held on thesuppliers’ price lists.Lets look again at the suppliers price list in the case study. Thisconfirms that product information is held within this system andit is apparent from the case study that products are of real interest.

So have we Identified an Entity?

At this stage it would be likely that product would be consideredto be an entity. However, you will shortly see why the analysisphase needs to be iterative - enabling decisions to be altered later,if necessary.

142

Systems Analysis– Entity Identification –Exercise # 4

Once again a natural assumption would be that a retail businesswould store substantial information about its’ suppliers.On requesting to see information about City Cameras’ suppliers,the owner once again reaches for the suppliers’ price lists.Lets look again at the suppliers’ price list in the case study. Each ofthese lists has the name, address and telephone number of thesupplier on the first page. The suppliers’ price list is the only placewhere City Cameras stores information about suppliers.Whilst the early investigation indicated that ‘product’ was probablyan entity, it now becomes apparent that the unique identificationof a product and access to the product information is also onlypossible after locating the relevant suppliers price list.It has now been established that all of the information that isstored in relation to the two potential entities ‘product’ and‘supplier’ are held in the same place - the suppliers’ price list. Thismeans that the suppliers’ price list is an entity and that bothproduct and supplier represent information held within this entity.Both supplier and product are therefore identified as beingattributes of the entity ‘suppliers price list’.

Systems Analysis– Entity Identification –Exercise # 5What about the potential entity: ‘Order’. Investigation revealsthat the re-ordering process consists of visual stocktaking on anad-hoc basis, followed by mental recall of those suppliers thatstock the identified products.The appropriate suppliers price lists are then referred to for theup-to-date pricing information and contact details and the orderis placed over the telephone. The owner keeps a written record ofthe orders he places, each order on a separate sheet of paper, andthese are then filed.


Computer systems Design and Architecture


Systems Analysis and Design Methods


Systems Analysis and Design


Object-Oriented systems Analysis andDesign using UML


Object-oriented Analysis and



Modern systems Analysis and Design


Advanced Computer Architecture :

A systems Design Approch


Advanced computer Architectures :

A Design space Approch


Systems analysis, Data Processing

and Quantitative Techniques


Introduction to Systems Analysis & Design




143

LESSON 30 :ENTITY IDENTIFICATION

Topics covered• Entity Identification

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the System analysis entity identification

Systems Analysis – Entity Identification –Exercise # 6Having started with six potential entities (suppliers price list,customer, product, order, invoicing details and supplier), theanalysis has identified that only two of these are in fact entities.We eliminated customer, as no customer information is recordedor stored within this retail outlet.The stored information relating to both a product and a supplierwas found to only exist within the suppliers’ price list. ThereforeSuppliers’ Price List was identified as being the only entity amongstthese three.Order was confirmed as a system entity and the invoicing detailswere identified early on as being an attribute of this entity.Even in this simple scenario it should be apparent that entityidentification needs careful consideration. Interestingly, both ofthe entities that were identified existed as documents within thesystem. Entities are often synonymous with discrete informationstores within a system - whether physical or electronic.The precise definition of what is an entity and what is an attributewill not always be clear. Therefore the process of entity identificationshould be iterative, enabling the review of decisions made earlier.Remember, entity types are always named in the singular and thisname then represents all of the occurrences of that entity type.

Systems Analysis – Entity Identification GuidelinesThere are a variety of methods that can be employed when tryingto identify system entities. There follows a series of entityidentification guidelines, which should prove helpful to theinexperienced analyst:An informal questioning approach can be adopted, in which theanalyst asks targeted questions to determine what information isnecessary and whether or not that information is recorded withinthe system.During face to face discussions with users the nouns (or givennames of objects) should be recorded - as these often indicatethose things that are entities within a system.The existing documentation often contains clues as to theinformation that needs to be held and once again the nouns in thetext may indicate potential entities.Every fact that is required to support the business is almost certainlyan attribute (or data item). In turn each of these attributes willbelong to an entity. If no ‘parent’ entity can be found for one or

more of these low level facts, then this indicates that your entitysearch is incomplete.However, don’t get hung up on the initial analysis. Entityidentification can continue once the drawing of the data modeldiagram has begun. As this diagram is developed and refinedfurther entities may become apparent.

Systems Analysis– Attributes & KeysEach entity type can always be described in terms of attributes,and these attributes will apply to all occurrences of that givenentity type. In the camera shop example, all occurrences of theentity ‘supplier’ could be described by an identifiable set ofattributes, including:The Supplier Name, the Supplier Address, Telephone Number,etcetera, as shown.

A given attribute belonging to a given entity occurrence can onlyhave one value. Therefore, if a supplier could have more than oneaddress or telephone number then this should be determinedbefore defining the attributes of that entity type.In this example the defined entity may require two or three addressand/or telephone number attributes. It is the maximum practicalinstances of a given attribute that should be catered for in theentity type definition.

Systems Analysis – Entity KeysAn entity is defined by its attributes. Furthermore, each entityoccurrence can be uniquely identified, by using an attribute or acombination of attributes as a key.The primary key is the attribute (or group of attributes) that serveto uniquely identify each entity occurrence. Consider the problemthat might arise if the name and address of an individual wereused as the primary key for identifying the patients within ahospital.

144

Take the example of a patient called David Smith living at 23Acacia Avenue. He has a son also called David Smith living at thesame address.Name and Address would not necessarily provide a uniqueidentifier and confusion could easily arise, potentially creating amix up with the patient records.For this reason, in a hospital system patients each have a PatientNumber as their primary key.If two or more data items are used as the unique identifier, thenthis represents a compound key. For example, a compound keyused to identify a book could be ‘Title’ together with ‘Author’.There may be occasions of authors using a previously used titlebut not of an author using the same title for more than one oftheir own books.Where several possible primary keys exist they are called candidatekeys.For example, a book could be identified, either by ‘Title’ togetherwith ‘Author’ or by the widely used unique identifier for books -the ISBN number.Where an attribute of one entity is a candidate key for anotherentity, it is termed a foreign key.For example, the attribute ‘Author’ belonging to the entity Bookis a foreign key within the entity Author. You may be able to thinkof some shortcomings to the use of this attribute as the primarykey, for example two authors having the same name.It is worth noting that entity relationships are often indicated bythe presence of foreign keys.

Systems Analysis – Relationships

A relationship is the association between two entities to which allof the occurrences of those entities must conform. The diagramshown represents the beginnings of a data model where therelationship between a manager and a department needs to bedefined.The entities on data models are linked by relationship lines andtogether these are the only two components that make up a datamodel diagram. A relationship is an association between twoentities to which all of the occurrences of those entities mustconform.Every relationship line shows two reciprocal relationships:That of the first entity with respect to the second and that of thesecond entity with respect to the first. In this example a manageris responsible for a department and a department is theresponsibility of a manager.Each relationship line has three distinct properties: Firstly therelationship link phrase, secondly the degree or cardinality of therelationship and thirdly the participation or optionality of therelationship. These three properties combine to form therelationship statement.

Systems Analysis– Relationship Link Phrase

The first property of the relationship statement is the relationshiplink phrase. This should be a short description of the nature ofthe relationship, typically between three and five words long. It isalways read clockwise with respect to the entities that it links, so inthis example:’Manager is responsible for department’, and ‘Department isresponsibility of manager’If the same relationship were to be drawn with department onthe left hand side then the positions of the link phrases wouldhave to be reversed.

Systems Analysis – Relationship CardinalityThe second property of the relationship statement is the degree,or maximum cardinality, of the relationship. If an entity has acrowsfoot symbol drawn against it, then many occurrences ofthat entity may relate to the other entity. Conversely if no crowsfootis drawn against it, at most one occurrence of that entity may relateto the other entity.

In this example: Each company employs one or more employees,but Each employee is employed by only one company. This iscalled a one-to-many relationship.Maximum cardinalities may be combined to give another tworelationship types, In this example:

Each manager is responsible for only one department and eachdepartment is the responsibility of only one manager. This iscalled a one-to-one relationship.

And in this example

Each lecturer teaches one or more courses and each course is taughtby one or more lecturers. This is called a many-to-many relationship.To recap, three different relationship types have been illustrated,one-to-many, one-to-one and many-to-many.

145

Questions1. What is system analysis and structured system analysis?2. Please tell several models used to analyse system.3. Why does system analysis play an important role in the system’s

development life cycle?4. Please tell the roles of system analysts.5. What are the popular tools used during the system analysis?6. What is BFD? Why is it important?7. What are the main components of BFD?8. What are the main components of DFD?9. What is data dictionary? Please tell some of its main

components.10. What is process specification? Please tell some of its main

components.11.Base on which foundation do you build the ERD? What are

their main components?12. What are some of the popular relationships?13. What is recursive relationship?14. What are some popular normalization used in the building

and testing of models?


Computer Systems Design and Architecture






Object-Oriented systems Analysis and

Design using UML


Object-Oriented Analysis and

Design : with Applications


Modern systems analysis and Design


Advanced Computer Architecture :a systems Design approchNew Delhi : Prentice Hall of India, 1996

Sima, DezsoAdvanced computer Architectures :a Design space Approch

Delhi : Pearson Education Asia, 1997

Sarkar, A.K.Systems Analysis, Data processing andQuantitative Techniques


Introduction to systems Analysis & Design




Notes

146

LESSON 31 :RELATIONSHIPS

Topics covered• Relationships

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss the various notation used in entity relation modelling

Systems Analysis – Relationship ParticipationThe third and final property of the relationship statement is theparticipation or optionality. A solid line shows that an entityoccurrence must be associated with each occurrence of the otherentity. In this example:

Each passenger must possess a ticket, and Each ticket must belongto a passenger. A dotted line shows that an entity occurrence maybe associated with each occurrence of the other entity, In thisexample

Each book may be borrowed by a borrower, and Each borrowermay borrow one or more books. Furthermore, these symbols canbe combined. In this example:

Each book may be recalled by a reservation, but Each reservationmust be recalling a book.Remember, there are only two components to a data modeldiagram, entities and relationships. A relationship is an associationbetween two entities to which all of the occurrences of those twoentities must conform.There are three distinct properties of the relationship; firstly therelationship link phrase, secondly the degree or cardinality of therelationship and thirdly the participation or optionality of therelationship. These three properties are collectively termed therelationship statement.

Systems Analysis– Identifying RelationshipsThere are just two questions that need to be asked, in order toestablish the degree of the relationship that exists between anytwo entities.

In order to identify the degree of the relationship between theentities X and Y the following two questions need to be asked.

Question 1Can an occurrence of X to be associated with more than oneoccurrence of Y?

Question 2Can an occurrence of Y to be associated with more than oneoccurrence of X?Each of these questions can be answered ‘Yes’ or ‘No’ and bothquestions must be answered. This means that there are fourpossible outcomes as shown in the table.

The nature of the relationship associated with each outcome is asfollows:Option 1, Question1 equals Yes, Question2 equals No.In this case a one-to-many relationship has been identified,represented by the relationship line shown.Option 2, Question1 equals No, Question2 equals YesAs in the first case a one-to-many relationship has been identified,represented by the relationship line shown.Option 3, Question1 equals Yes, Question2 equals YesIn this case a many-to-many relationship has been identified.Many-to-many relationships may be shown in the early‘preliminary’ data model in order to aid the clarity of these earlydiagrams. However, such relationships are invalid and are thereforealways re-modeled using ‘link entities’ in later diagrams. Thisprocess is explained later in the course.Option 4, Question1 equals No, Question2 equals NoIn this case a one-to-one link has been identified.Legitimate one-to-one relationships are rare and it is likely thatthis relationship is one that needs to be rationalized. The methodsused to investigate one-to-one relationships and to re-model themwhere necessary are explained later in the course.In a one-to-many relationship the entity at the ‘one’ end is normallyreferred to as the master, and the entity at the ‘many’ end referredto as the detail entity. Some analysts adopt the ‘no dead crows’rule and avoid drawing crowsfeet pointing upwards. This ensuresthat detail entities are shown below the master entities to whichthey belong.This makes the diagram clearer, although congestion may makethis rule difficult to enforce throughout the data model.

147

Systems Analysis– Relationship StatementsThe relationship statement is a formal description thatencompasses the three properties of the relationship.The relationship statement encompasses the three properties ofthe relationship. The first property is the relationship link phrase,the second the degree or cardinality of the relationship and thethird the participation or optionality of the relationship.

Systems Analysis - DFD Introduction

Data flow diagrams can be used to provide a clear representationof a business function. The technique starts with an overall pictureof the business and continues by analyzing each of the functionalareas of interest to the level of detail required. The techniqueexploits a method called top-down expansion to conduct theanalysis in a targeted way.The result is a series of diagrams that represent the businessactivities in a way that is clear and easy to communicate. A businessmodel comprises one or more data flow diagrams (also known asbusiness process diagrams). Initially a context diagram is drawn,which is a simple representation of the entire system underinvestigation.This is followed by a level 1 diagram; which provides an overviewof the major functional areas of the business. Don’t worry aboutthe symbols at this stage, these are explained shortly. Using thecontext diagram together with additional information from thearea of interest, the level 1 diagram can then be drawn.The level 1 diagram identifies the major business processes at ahigh level and any of these processes can then be analyzed further- giving rise to a corresponding level 2 business process diagram.This process of more detailed analysis can then continue – throughlevel 3, 4 and so on. However, most investigations will stop atlevel 2 and it is very unusual to go beyond a level 3 diagram.Identifying the existing business processes, using a technique likedata flow diagrams, is an essential precursor to business processre-engineering, migration to new technology, or refinement of anexisting business process. However, the level of detail requiredwill depend on the type of change being considered.

Systems Analysis– DFD NotationThere are only five symbols that are used in the drawing ofbusiness process diagrams (data flow diagrams). These are nowexplained, together with the rules that apply to them.

This diagram represents a banking process, which maintainscustomer accounts. In this example, customers can withdraw ordeposit cash, request information about their account (for examplethe balance) or update their account details (for example withchange of address information).The five different symbols used in this example represent the fullset of symbols required to draw any business process diagram.

External Entity

An external entity is a source or destination of a data flow whichis outside the area of study. Only those entities which originate orreceive data are represented on a business process diagram. Thesymbol used is an oval containing a meaningful and uniqueidentifier. In this example the customer exists outside of thebanking business system.

Process

A process shows a transformation or manipulation of data flowswithin the system. The symbol used is a rectangular box whichcontains 3 descriptive elements:Firstly an identification number appears in the upper left handcorner. This is allocated arbitrarily at the top level and serves as aunique reference.Secondly, a location appears to the right of the identifier anddescribes where in the system the process takes place. This may,for example, be a department or a piece of hardware.Finally, a descriptive title is placed in the centre of the box. Thisshould be a simple imperative sentence with a specific verb, forexample ‘maintain customer records’ or ‘find driver’.

Data Flow

A data flow shows the flow of information from its source to itsdestination. A data flow is represented by a line, with arrowheadsshowing the direction of flow. Information always flows to orfrom a process and may be written, verbal or electronic. Each dataflow may be referenced by the processes or data stores at its headand tail, or by a description of its contents.

148

Data Store

A data store is a holding place for information within the system:It is represented by an open ended narrow rectangle.Data stores may be long-term files such as sales ledgers, or may beshort-term accumulations: for example batches of documentsthat are waiting to be processed. Each data store should be givena reference followed by an arbitrary number.

Resource Flow

A resource flow shows the flow of any physical material from itssource to its destination. For this reason they are sometimesreferred to as physical flows.The physical material in question should be given a meaningfulname. Resource flows are usually restricted to early, high-leveldiagrams and are used when a description of the physical flow ofmaterials is considered to be important to help the analysis.

Systems Analysis – Drawing Data FlowDiagrams

ProcessesWhen naming processes, avoid glossing over them, without reallyunderstanding their role. Indications that this has been done arethe use of vague terms in the descriptive title area - like ‘process’ or‘update’.The most important thing to remember is that the descriptionmust be meaningful to whoever will be using the diagram.

Data FlowsDouble headed arrows can be used (to show two-way flows) onall but bottom level diagrams. Furthermore, in common withmost of the other symbols used, a data flow at a particular level ofa diagram may be decomposed to multiple data flows at lowerlevels.

External EntitiesIt is normal for all the information represented within a system tohave been obtained from, and/or to be passed onto, an externalsource or recipient. These external entities may be duplicated on adiagram, to avoid crossing data flow lines. Where they areduplicated a stripe is drawn across the left hand corner, like this.The addition of a lowercase letter to each entity on the diagram isa good way to uniquely identify them.

Data StoresEach store should be given a reference letter, followed by an arbitrarynumber. These reference letters are allocated as follows:’D’ - indicates a permanent computer file’M’ - indicates a manual file’T’ - indicates a transient store, one that is deleted afterprocessing.

In order to avoid complex flows, the same data store may bedrawn several times on a diagram. Multiple instances of the samedata store are indicated by a double vertical bar on their left handedge.

Systems Analysis – DFD RelationshipGridThere are rules governing various aspects of the diagramcomponents and how they can relate to one another.

Data Flows

For data flows the rules are as follows:Data flows and resource flows are allowed between external entitiesand processes. Data flows are also allowed between differentexternal entities. However, data flows and resource flows are notallowed between external entities and data stores.

Processes

For processes the data flow rules are as follows:Data flows and resource flows are allowed between processes andexternal entities and between processes and data stores. They arealso allowed between different processes. In other words processescan communicate with all other areas of the business processdiagram.

Data Stores

For data stores the data flow rules are as follows:Data flows and resource flows are allowed between data storesand processes. However, these flows are not allowed betweendata stores and external entities or between one data store andanother. In practice this means that data stores cannot initiate acommunication of information, they require a process to do this.

The context diagram represents the entire system underinvestigation. It should be drawn first, and used to clarify andagree the scope of the investigation. The system underinvestigation is represented as a single process, connected toexternal entities by data flows and resource flows.The context diagram clearly shows the interfaces between thesystem under investigation and the external entities with which itcommunicates. Therefore, whilst it is often conceptually trivial, acontext diagram serves to focus attention on the system boundaryand can help in clarifying the precise scope of the analysis. Thecontext diagram shown on this screen represents a book lendinglibrary. The library receives details of books, and orders booksfrom one or more book suppliers.

149

Books may be reserved and borrowed by members of the public,who are required to give a borrower number. The library willnotify borrowers when a reserved book becomes available or whena borrowed book becomes overdue. In addition to supplyingbooks, a book supplier will furnish details of specific books inresponse to library enquiries.Note, that communications involving external entities are onlyincluded where they involve the ‘system’ process. Whilst a booksupplier would communicate with various agencies, for example,publishers and other suppliers - these data flow are remote fromthe ‘system’ process and so this is not included on the contextdiagram.




Systems Analysis and design methods




Object-oriented systems Analysis andDesign using UML


Object-Oriented Analysis and Design :with applications




Advanced Computer Architecture :a systems Design approch


Advanced Computer Architectures :a Design space Approch


Systems Analysis, Data processing andQuantitative Techniques






Notes

150

LESSON 32 :CONTEXT DIAGRAM

Topics Covered• Context Diagram

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss about context diagrams

Systems Analysis Context DiagramGuidelinesFirstly, draw and name a single process box that represents theentire system.Next, identify and add the external entities that communicatedirectly with the process box. Do this by considering origin anddestination of the resource flows and data flows.Finally, add the resource flows and data flows to the diagram.In drawing the context diagram you should only be concernedwith the most important information flows. These will beconcerned with issues such as: how orders are received and checked,with providing good customer service and with the paying ofinvoices. Remember that no business process diagram is thedefinitive solution - there is no absolute right or wrong.

Systems Analysis– Level 1 Diagrams

There is no formula that can be applied in deciding what is, andwhat is not, a level 1 process. Level 1 processes should describeonly the main functional areas of the system, and you shouldavoid the temptation of including lower level processes on thisdiagram. As a general rule no business process diagram shouldcontain more than 12 process boxes.#The level 1 diagram shows the main functional areas of the systemunder investigation. As with the context diagram, any systemunder investigation should be represented by only one level 1diagram.The level 1 diagram is surrounded by the outline of a process boxthat represents the boundaries of the system. Because the level 1diagram depicts the whole of the system under investigation, itcan be difficult to know where to start.There are three different methods, which provide a practical wayto start the analysis. These are explained in the following sectionand any one of them, or a combination, may prove to be themost helpful in any given investigation.

There are three different methods, which provide a practical way tostart the analysis. These are introduced below and any one ofthem, or a combination, may prove to be the most helpful in anygiven investigation:

Systems Analysis – Resource FlowAnalysisResource flow analysis may be a useful method for starting theanalysis if the current system consists largely of the flow of goods,as this approach concentrates on following the flow of physicalobjects.Resource flow analysis may be a useful method for developingdiagrams if the current system consists largely of the flow ofgoods. Physical resources are traced from when they arrive withinthe boundaries of the system, through the points at which someaction occurs, to their exit from the system. The rationale behindthis method is that information will normally flow around thesame paths as the physical objects.

Systems Analysis – OrganizationalStructure AnalysisThe organizational structure approach starts from an analysis ofthe main roles that exist within the organization, rather than thegoods or information that is flowing around the system.Identification of the key processes results from looking at theorganizational structure and deciding which functional areas arerelevant to the current investigation. By looking at these areas inmore detail, and analyzing what staff actually do, discrete processescan be identified.Starting with these processes, the information flows between themand between these processes and external entities are then identifiedand added to the diagram.

Systems Analysis – Document FlowAnalysisThe document flow analysis approach is appropriate if the part ofthe business under investigation consists principally of flows ofinformation in the form of documents or computer input andoutput.Document flow analysis is particularly useful where informationflows are of special interest. The first step is to list the majordocuments and their sources and recipients. This is followed bythe identification of other major information flows such astelephone and computer transactions. Once the document flowdiagram has been drawn the system boundary should be added.

151

Systems Analysis – Top Down Expansion

The screen explains the process of top down expansion andillustrates that whilst there can only be one context and one level 1diagram for a given system, these normally give rise to numerouslower level diagrams.Each process within a given data flow diagram may be the subjectof further analysis. This involves identifying the lower levelprocesses that together constitute the process as it was originallyidentified. This procedure is known as top-down expansion orleveling.As a business process diagram is decomposed, each process boxbecomes a boundary for the next, lower level, diagram.

Systems Analysis – Top Down ExpansionIllustrated

In order to illustrate the process of top-down expansion, considerthe three processes shown within this business process diagram.No detail is shown, only the outline of the process boxes, whichhave been identified during the drawing of a level 1 diagram.Any area of a level 1 diagram is likely to require further analysis, asthe level 1 diagram itself only provides a functional overview ofthe business system.Therefore, below the level 1 diagram there will be a series of lowerlevel diagrams. These are referred to as level 2, level 3, etcetera. Inpractice, level 2 is usually sufficient and it is unusual to carry out ananalysis beyond level 3.In this example the process numbered 3, at level 1, will beinvestigated further thereby giving rise to a level 2 diagram.

In the level 2 diagram four processes of interest have been identifiedand the numbering of these processes must reflect the parentprocess. Therefore the level 2 processes are numbered 3.1, 3.2, 3.3and 3.4Suppose that of these four level 2 processes, one was of sufficientinterest and complexity to justify further analysis. This process,let’s say 3.3, could then be further analyzed resulting in acorresponding level 3 diagram. Once again the numbering of theseprocesses must reflect the parent process. Therefore these threelevel 3 processes are numbered 3.3.1, 3.3.2 and 3.3.3.

Systems Analysis – DFD Numbering Rules

The process boxes on the level 1 diagram should be numberedarbitrarily, so that no priority is implied. Even where data fromone process flows directly into another process, this does notnecessarily mean that the first one has to finish before the secondone can begin.Therefore the processes on a level 1 diagram could be re-numberedwithout affecting the meaning of the diagram. This is true withinany business process diagram - as these diagrams do not implytime, sequence or repetition.However, as the analysis continues beyond level 1 it is importantthat a strict numbering convention is followed. The processes onlevel 2 diagrams must indicate their parent process within the level1 diagram. This convention should continue through level 3diagrams, and beyond, should that level of analysis ever berequired.The diagram on this screen clearly illustrates how processes onlower level diagrams identify their ancestral path.

Systems Analysis - When to Stop TopDown ExpansionIt is important to know when to stop the process of top-downexpansion. Usually this will be at level 2 or level 3.There are 3 useful guidelines to help you to decide when to stopthe analysis:Firstly, if a process has a single input data flow or a single outputdata flow then it should be apparent that there is little point inanalyzing it any further.Secondly, when a process can be accurately described by a singleactive verb with a singular object, this also indicates that the analysishas been carried out to a sufficiently low level. For example, theprocess named validate enquiry contains a single discrete task.

152

Finally, ask yourself if anything useful will be gained by furtheranalysis of a process. Would any more detail influence yourdecisions?If the answer is no, then there is little point in taking the analysisfurther.

Systems Analysis– Keeping DFDs ClearIn this section a variety of simple techniques are introduced toshow how a business process diagram can be clarified. The examplesused do not relate to any specific scenario but are hypotheticalabstracts used for the purpose of illustration.

Exclude Minor Data FlowsWhere information is being retrieved from a data store, it is notnecessary to show the selection criteria, or key, that is being used toretrieve it.In the banking example, the customer details are shown beingretrieved from the data store but the key used to retrieve thisinformation is not shown.Where a data store is being updated, only the data flow representingthe update needs to be shown. The fact that the informationmust first be retrieved does not need to be shown.Only the most important reports, enquiries, etcetera should beshown on the diagram. Communications that are of lesssignificance can, if necessary, be detailed in support documentation.

Combining Data StoresIn a similar way, data stores that are holding related informationshould be suffixed with a lower case letter.Related data stores can also be combined, and where this is thecase the numbers placed after the identifying alphabetic characterare not shown.

Combining External EntitiesAnother way to reduce the complexity of a business processdiagram is to combine any related external entities.For example, a business system will often be dealing with differentunits from within the same external organization, and these canbe combined into a single external entity. Where these units areuniquely identified a number should follow the entity identificationletter. However, when they are combined the numbers placedafter the identifying alphabetic character are not shown.Combining ProcessesFirstly, where a diagram is considered to contain too manyprocesses, those that are related can often be combined. As ageneral rule no business process diagram should contain morethan 12 process boxes.In some examples multiple process boxes can be identified asbeing related and can be combined into a single process box witha collective description.

Questions:.Precision Tools sells a line of high quality woodworking tools.When customers place orders on the company’s website , thesystem checks to see if the items are in stock, issues a atatusmessage to the customer and generates a shipping order to thewarehouse, which fills the order. When the order is shipped , thecustomer is billed. The system also produces various reports.

(i) Draw a context diagram for the order system(ii) Draw a DFD diagram 0 for the order system(iii) Name four attributes that you can use to define a process in

the order system.(iv) Name four attributes that you can use to define an entity in

the order system








Object-Oriented systems Analysis andDesign using UML


Object-Oriented Analysis andDesign : with applications




Advanced computer Architecture :A systems Design Approach


Advanced computer Architectures :a Design space Approach








153

LESSON 33 :SYSTEM MODELING

Topics Covered• System modeling (data modeling)

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss about data modelling

An Introduction to Systems ModelingSystems Modeling

• One way to structure unstructured problems is to draw models.• A model is a representation of reality. Just as a picture is worth

a thousand words, most system models are pictorialrepresentations of reality.

• Models can be built for existing systems as a way to betterunderstand those systems, or for proposed systems as a wayto document business requirements or technical designs.

What are Logical Models?• Logical models show what a system ‘is’ or ‘does’. They are

implementation-independent; that is, they depict the systemindependent of any technical implementation. As such, logicalmodels illustrate the essence of the system.

What are Physical Models?

• Physical models show not only what a system ‘is’ or ‘does’,but also how the system is physically and technicallyimplemented. They are implementation-dependent becausethey reflect technology choices, and the limitations of thosetechnology choices.

• Systems analysts use logical system models to depict businessrequirements, and physical system models to depict technicaldesigns.

• Systems analysis activities tend to focus on the logical systemmodels for the following reasons:

• Logical models remove biases that are the result of the way thecurrent system is implemented or the way that any one personthinks the system might be implemented.

• Logical models reduce the risk of missing businessrequirements because we are too preoccupied with technicaldetails.

• Logical models allow us to communicate with end-users innon-technical or less technical languages.

• Data modeling is a technique for defining businessrequirements for a database.

• Data modeling is a technique for organizing and documentinga system’s DATA. Data modeling is sometimes called databasemodeling because a data model is usually implemented as adatabase. It is sometimes called information modeling.

• Many experts consider data modeling to be the most importantof the modeling techniques.

• Why is data modeling considered crucial?• Data is viewed as a resource to be shared by as many processes

as possible. As a result, data must be organized in a way that isflexible and adaptable to unanticipated business requirements-and that is the purpose of data modeling.

• Data structures and properties are reasonably permanentcertainly a great deal more stable than the processes that use thedata. Often the data model of a current system is nearly identicalto that of the desired system.

• Data models are much smaller than process and object modelsand can be constructed more rapidly.

• The process of constructing data models helps analysts andusers quickly reach consensus on business terminology andrules.

System Concepts for Data Modeling

System Concepts

• Most systems analysis techniques are strongly rooted in systemsthinking.

• Systems thinking is the application of formal systems theoryand concepts to systems problem solving.

• There are several notations for data modeling, but the actualmodel is frequently called an entity relationship diagram (ERD).

• An ERD depicts data in terms of the entities and relationshipsdescribed by the data.

Entities

• All systems contain data.• Data describes ‘things’.• A concept to abstractly represent all instances of a group of

similar ‘things’ is called an entity.• An entity is something about which we want to store data.

Synonyms include entity type and entity class.• An entity is a class of persons, places, objects, events, or concepts

about which we need to capture and store data.• An entity instance is a single occurrence of an entity.

Attributes

• The pieces of data that we want to store about each instance ofa given entity are called attributes.

• An attribute is a descriptive property or characteristic of anentity. Synonyms include element, property, and field.

• Some attributes can be logically grouped into super-attributescalled compound attributes.

• A compound attribute is one that actually consists of moreprimitive attributes. Synonyms in different data modelinglanguages are numerous: concatenated attribute, compositeattribute, and data structure.

154

• An entity typically has many instances; perhaps thousands ormillions and there exists a need to uniquely identify each instancebased on the data value of one or more attributes.

• Every entity must have an identifier or key.• An key is an attribute, or a group of attributes, which assumes

a unique value for each entity instance. It is sometimes called anidentifier.

• Sometimes more than one attribute is required to uniquelyidentify an instance of an entity.

• A group of attributes that uniquely identifies an instance of anentity is called a concatenated key. Synonyms include compositekey and compound key.

• Frequently, an entity may have more than one key.• Each of these attributes is called a candidate key.• A candidate key is a ‘candidate to become the primary identifier’

of instances of an entity. It is sometimes called a candidateidentifier. (Note: A candidate key may be a single attribute or aconcatenated key.)

• A primary key is that candidate key which will most commonlybe used to uniquely identify a single entity instance.

• Any candidate key that is not selected to become the primarykey is called an alternate key.

• Sometimes, it is also necessary to identify a subset of entityinstances as opposed to a single instance.

• For example, we may require a simple way to identify all malestudents, and all female students.

• A subsetting criteria is a attribute (or concatenated attribute)whose finite values divide all entity instances into useful subsets.Some methods call this an inversion entry.

Relationships• Conceptually, entities and attributes do not exist in isolation.• Entities interact with, and impact one another via relationships

to support the business mission.• A relationship is a natural business association that exists

between one or more entities. The relationship may representan event that links the entities, or merely a logical affinity thatexists between the entities.

• A connecting line between two entities on an ERD representsa relationship.

• A verb phrase describes the relationship.• All relationships are implicitly bidirectional, meaning that they

can interpreted in both directions.

Cardinality• Each relationship on an ERD also depicts the complexity or

degree of each relationship and this is called cardinality.• Cardinality defines the minimum and maximum number of

occurrences of one entity for a single occurrence of the relatedentity. Because all relationships are bi-directional, cardinalitymust be defined in both directions for every relationship.

Degree• The degree of a relationship is the number of entities that

participate in the relationship.

• A binary relationship has a degree = 2, because two differententities participated in the relationship.

• Relationships may also exist between different instances of thesame entity.

• This is called a recursive relationship (sometimes called a unaryrelationship; degree = 1).

• Relationships can also exist between more than two differententities.

• These are sometimes called N-ary relationships.• A relationship existing among three entities is called a 3-ary or

ternary relationship.• An N-ary relationship maybe associated with an associative

entity.• An associative entity is an entity that inherits its primary key

from more than one other entity (parents). Each part of thatconcatenated key points to one and only one instance of eachof the connecting entities.

Foreign Keys• A relationship implies that instances of one entity are related

to instances of another entity.• To be able to identify those instances for any given entity, the

primary key of one entity must be migrated into the otherentity as a foreign key.

• A foreign key is a primary key of one entity that is contributedto (duplicated in) another entity for the purpose of identifyinginstances of a relationship. A foreign key (always in a childentity) always matches the primary key (in a parent entity).

• When you have a relationship that you cannot differentiatebetween parent and child it is called a non-specific relationship.

• A non-specific relationship (or many-to-many relationship) isone in which many instances of one entity are associated withmany instances of another entity. Such relationships are suitableonly for preliminary data models, and should be resolved asquickly as possible.

• All non-specific relationships can be resolved into a pair ofone-to-many relationships by inserting an associative entitybetween the two original entities.

Generalization• Generalization is an approach that seeks to discover and exploit

the commonalties between entities.• Generalization is a technique wherein the attributes that are

common to several types of an entity are grouped into theirown entity, called a supertype.

• An entity supertype is an entity whose instances store attributesthat are common to one or more entity subtypes.

• The entity supertype will have one or more one-to-onerelationships to entity subtypes. These relationships aresometimes called IS A relationships (or WAS A, or COULDBE A) because each instance of the supertype ‘is also an’ instanceof one or more subtypes.

• An entity subtype is an entity whose instances inherit somecommon attributes from an entity supertype, and then addother attributes that are unique to an instances of the subtype.

155

• An entity can be both a supertype and subtype.• Through inheritance, the concept of generalization in data

models permits the the reduction of the number of attributesthrough the careful sharing of common attributes.

• The subtypes not only inherit the attributes, but also the datatypes, domains, and defaults of those attributes.

• In addition to inheriting attributes, subtypes also inheritrelationships to other entities.

The Process of Logical Data Modeling

Strategic Data Modeling

• Many organizations select application developmentprojects based on strategic information system plans.

• Strategic planning is a separate project.• This project produces an information systems strategy plan

that defines an overall vision and architecture for informationsystems.

• Almost always, the architecture includes an enterprise datamodel.• An enterprise data model typically identifies only the most

fundamental of entities.• The entities are typically defined (as in a dictionary) but they are

not described in terms of keys or attributes.• The enterprise data model may or may not include

relationships (depending on the planning methodology’sstandards and the level of detail desired by executivemanagement).

• If relationships are included, many of them will be non-specific.• The enterprise data model is usually stored in a corporate

repository.

Data Modeling During Systems Analysis• The data model for a single system or application is usually

called an application data model.• Logical data models have a Data focus and a System

User perspective.• Logical data models are typically constructed as

deliverables of the study and definition phases of aproject.

• Logical data models are not concerned withimplementation details or technology, they may beconstructed (through reverse engineering) from existingdatabases.

• Data models are rarely constructed during the survey phaseof systems analysis.

• Data modeling is rarely associated with the study phaseof systems analysis. Most analysts prefer to draw processmodels to document the current system.

• Many analysts report that data models are far superior for thefollowing reasons:

• Data models help analysts to quickly identify businessvocabulary more completely than process models.

• Data models are almost always built more quickly than processmodels.

• A complete data model can be fit on a single sheet of paper.Process models often require dozens of sheets of paper.

• Process modelers too easily get hung up on unnecessary detail.

Data Modeling During Systems Analysis• Many analysts report that data models are far superior for

the following reasons: (continued)• Data models for existing and proposed systems are far more

similar than process models for existing and proposed systems.Consequently, there is less work to throw away as you moveinto later phases.• A study phase model should include only entities

relationships, but no attributes – a context data model.• The intent is to refine the understanding of scope; not to get

into details about the entities and business rules.• The definition phase data model will be constructed in at

least two stages:• A key-based data model will be drawn.• This model will eliminate non-specific relationships, add

associative entities, include primary, alternate keys, and foreignkeys, plus precise cardinalities and any generalization hierarchies.

• A fully attributed data model will be constructed.• The fully attributed model includes all remaining descriptive

attributes and subsetting criteria.• Each attribute is defined in the repository with data types,

domains, and defaults.• The completed data model represents all of the business

requirements for a system’s database.Looking Ahead to Systems Configuration andDesign

• The logical data model from systems analysis describesbusiness data requirements, not technical solutions.

• The purpose of the configuration phase is to determinethe best way to implement those requirements withdatabase technology.

• During system design, the logical data model will betransformed into a physical data model (called a databaseschema) for the chosen database management system.

• This model will reflect the technical capabilities and limitationsof that database technology, as well as the performance tuningrequirements suggested by the database administrator.

• The physical data model will also be analyzed for adaptabilityand flexibility through a process called normalization.

Fact-Finding and Information Gathering for DataModeling

• Data models cannot be constructed without appropriatefacts and information as supplied by the user community.

• These facts can be collected by a number of techniques such assampling of existing forms and files; research of similar systems;surveys of users and management; and interviews of usersand management.

• The fastest method of collecting facts and information, andsimultaneously constructing and verifying the data models isJoint Application Development (JAD).

156

Computer-Aided Systems Engineering (CASE) forData Modeling

• Data models are stored in the repository.• In a sense, the data model is metadata – that is, data about the

business’ data.• Computer-aided systems engineering (CASE) technology,provides the repository for storing the data model and itsdetailed descriptions.• Using a CASE product, you can easily create professional,readable data models without the use of paper, pencil, erasers,and templates.

• The models can be easily modified to reflect corrections andchanges suggested by end-users.

• Most CASE products provide powerful analytical tools thatcan check your models for mechanical errors, completeness,and consistency• All Case products support not all data model

conventions.• It is very likely that any given CASE product may force the

company to adapt their methodology’s data modeling symbolsor approach so that it is workable within the limitations oftheir CASE tool.

Strengthening of information structure -relationship modelThis part discusses detailed analysis of system information toconfirm and develop the approach discussed earlier. This part willalso discuss techniques including normalization to create a well-structured model.In this methodology, relationship model is used as a data modelingprocess in order to test, improve and expand the constructed datamodel. Relationship model defines a list of all the attributes toevery table of entity of the data model. Depending on thesupporting tool that analysts use, the attributes form a uniquename of the table marked as a key attribute.The process of creating a relationship model and using it to testdata model, includes the following main steps:1. Define the necessary attributes in the to-be-built system;2. Define the type of entity suitable to attributes to limit copying

and data redundancy (normalization technique);3. Define the potential relationships within the lists of established

attributes for every entity by choosing linking attributes. Alllinking attributes express the multiple of the one - multiplerelationship;

4. With known attributes, types of entity and relationship, it ispossible to construct a scheme similar to intuition data model.Based on this, a model with the most suitable features isselected.

5. After the selection of a data model with the best form toperform system requirements, comes the estimation of thequantity of entity for every table via relationship normalizationand this is also done through model.

Despite the possibly time-consuming nature of theimplementation of the above steps, efficiency brought over by a

careful approach is more important. However, for simple systems,it is not necessary to go through all the listed steps. Experiencedanalysts need to have their own assessment of the complexity ofthe system in every specific case.

Identifying attributesIn order to identify all the details of attributes of entities necessaryfor the system, an analyst can rely on the following resources:· Interviewing users; (for example, what information the

system has to store to control magazines in a library);· Examining report forms and other documents frequently

used in the field under question;· Based on analysts’ experience and knowledge in the field

under question, estimation or intuitional identification ofattributes is formed.

As thus, for every type of entity in the data model, analysts willhave to provide a list of projected attributes. At first, a number ofattributes can be seen as belonging to many entities, but they needto be put in suitable lists. This issue will be studied at a later stageof the process with the help of normalization techniques.In the example of library management system, professional ruleanalysis gives the following outcomes:1. The library manages two main kinds of document books and

magazines.2. Each book has a distinct number (for example FV9550). In

case there are more than one book with the same book name,they still have distinct book numbers, because they may bereceived at different times, from different suppliers, and thelibrarian cannot be sure whether that book was in the library ornot.

The way of building distinct number for a book depends on itslanguage (exactly on 3 systems of language: Latin (F), Slav (S), andVietnamese (VN)); size of that book (divide into 3 sides: Large(L); Medium (V); and Small (N)), and on the number of bookson the library. For example: with number FV9550, if the book iswritten in English (Latin language), the size of the book is Medium(V), and there were 9549 books in the library.All information about books is stored in a book table, whichincludes a list of attributes:

157

List of attributes Type of attributes

Comment

BOOK_NOBOOK_NAMEBOOK_VOLSIZETIME_PUBLYEAR_PUBLPUB_HOUSECOSTAUTHORCHIEF_AUTHCOMP_AUTHREV_AUTHLANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMEKW_MASTERKW_SLAVECOMMENT

CharacterCharacterNumberCharacterNumberNumberCharacterNumberCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacter

Number of the book (must have) Name of the book (must have) Volume of book (may have) Size of the book (must have) Publish time (may have) Publish year (may have) Publish house (may have) Cost of the book (may have)Author(s) (must have) Chief author (may have) Compiler author (may have) Revise author (may have) Language number(ISO) (must have)Language name(ISO) (must have) Language name(in VN) (must have)Language system(ISO) (must have)National number(ISO) (must have)National name(ISO) (must have) National name(in VN) (must have)Speciality number (must have) Speciality name (must have) Collection number (must have) Collection name (must have) Master Keyword (may have) Slave Keyword (may have)Comment (may have)

3. The library lists the magazines regularly by volume, by numberor month, by quarter of year, or by year (it depends on publishcycle of each magazines). The library manages 3 kinds ofmagazines:

Information (TIN) magazines, Mathematics (TH) magazines, andtechnical (KT) magazines. Each magazine category has a distinctnumber, and each volume of one magazine category also has adistinct number. All information about magazine is stored in amagazine table which includes a list of attributes:


Comment

MAG_HEAD_NOMAG_DETL_NOMAG_NAMESTART_YEARMAG_SHEFLISSN_NOPUB_HOUSELANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMEYEARVOLUMENUMBERMONTHQUANTITYCOMMENT

CharacterCharacterCharacterNumberCharacterCharacterNumberCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterCharacterNumberNumberNumberNumberNumberCharacter

Magazine header number (must have) Magazine detail number (must have) Magazine name (must have) Having since (must have) Where put magazine in Lib(must have) ISSN number (may have) Publish house Language number(ISO) (must have) Language name(ISO) (must have) Language name(in VN) (must have) Language system(ISO) (must have) National number(ISO) (must have) National name(ISO) (must have) National name(in VN) (must have) Speciality number (must have) Speciality name (must have) Collection number (must have) Collection name (must have) Year of volume (may have) volume (may have) number of volume (may have) month of volume (may have) quantity of volume (may have) comment about volume (may have)

4. A new documents will be registered in the finding fields (forreaders to look up) in the library card.

5. The library manages readers as follows: In the Institute, thereare many departments, sub-departments, and in eachdepartment, there are also many staffs who are readers of thelibrary.

When a new staff wants to become a reader of the library, alibrarian will check if the department (which the staff is workingin) is in the list of institute departments or not. If it is not, firstly,the librarian has to register that new department, and then registerthe number of staff, this number will be the reader_number andwill be given back to the staff.6. When a reader wants to borrow a document, he (or she) has to

look up the number of that document on the library cards(depend on the finding fields), then he (or she) has to write thenumber of document if it is a book, or the number ofdocument and its volume (year, month, number), if it is amagazine, down in a Borrowing ticket. And then he (or she)asks the librarian for borrowing that document. All informationin the borrowing ticket is stored in a borrowing/returningticket table which includes a list of attributes:

If the document is a book


Comment

READER_NO

READER_NAME

BOOK_NO

BOOK_NAME

BORROW_DATE

RETURN_DATE

COMMENT

Character

Character

Character

Character

Date

Date

Character

Reader number (must have)

Reader name (may have)

Book number (must have)

Book number (may have)

Borrowing date (must have)

The date that has to return (may have)

Comment

158

If the document is a magazine


Comment

READER_NO

READER_NAME

MAG _NO

MAG _NAME

VOLUME

NO

YEAR

MONTH

BORROW_DATE

RETURN_DATE

COMMENT

Character

Character

Character

Character

Number

Number

Number

Number

Date

Date

Character

Reader number (must have)

Reader name (may have)

Magazine number (must have)

Magazine name (may have)

Magazine volume (may have)

Magazine no (may have)

Magazine year (may have)

Magazine month (may have)

Borrowing date (must have)

The date that has to return (may have)

Comment

With the Borrowing ticket: the librarian has to check whether thedocument is in the library or not. If it is still in, the librarian willfill information in all fields that has been enumerated in the tablesabove, otherwise, the librarian has to refuse to lend the requestedbook.With the Returning ticket: the librarian only has to receive documentand check the reader number, document number in theBorrowing/Returning ticket table and deletes it.7. At the end of each month, or each year, librarians have to

report the document situation in the library, the borrowing,returning documents of all departments in the institute andthe list of readers who have been keeping document overdue




Systems Analysis and Design methods




Bennett, SimonObject-Oriented systems Analysis andDesign using UML


Object-oriented Analysis andDesign : with Applications




Advanced computer Architecture :a systems Design Approch


Advanced computer Architectures :a Design space Approch








159

LESSON 34 :NORMALIZATION

Topics Covered• Normalization

ObjectivesUpon completion of this Lesson, you should be able to:• Explain about normalization

Determining types of entities(normalization)

Normalization is a process of surveying lists ofattributes and applying a range of analysisprinciples to the lists in order to make them meetthe following• Minimization of repetition;• Avoidance of redundancy;• Elimination of ambiguity.Repetition is the case when one attribute appears in many entitytables. It only occurs to identifying and connection attributes andis essential in expressing relationships.Redundancy can be a non-key attribute in many tables or it canpoint to inferred data. Attributes with values resulted from simplecalculation done with other attributes need to be eliminated fromthe model.Ambiguity can happen when meanings of attributes are notexpressed clearly to groups of users. Normalization process helpsanalysts study the meaning of every attribute and the relationshipmodel can only be built when a thorough understanding of everyattribute is achieved. This process is carried out with the help of“functional dependence” definition (or diagrams).Function Dependence defines a relationship between a pair offields in each record. In a relation including two attributes A andB, B is said to be functionally dependent on A if, for every validoccurrence, the value of A determines the value of B.In general, with every value of key at any point in time, a tableshould have only one value. If an attribute is not functionallydependent on key, it should be in another table. From all this, afully normalized model is the one in which every attribute in theentity table has a Function Dependence relationship to the table’skey attributes.To carry out normalization, the first task is to select a key for a listof all attributes of an entity. The key includes one or moreattributes capable of providing a unique name for every row in atable: no two entities in a type of entity have the same key.Let’s consider the list of attributes of an entity table put togetherby an analyst is non-standard (0NF) at the beginning stage. Thenext level of the list will be the first normal form (1NF).

The first normal formDictates that every attribute must have a single value for anyoccurrence of its entity at any one point in time. Also, a relation isin 1NF if, and only if, it contains no repeating groups.To be qualified for 2NF which only applies to composite primarykeys, every attribute of an entity must depends on the entireidentifier of its entity or its value. A relation is in 2NF if, and onlyif: it is in 1NF and every non-key attribute is dependent on allparts of the primary key.The solutions for both 1NF and 2NF are a non-lossdecomposition that involves removing the repeating group andtaking its determinant with it.The nature of the 1NF is to eliminate all repeating groups in a list.By doing this, the key of the table at a higher level will be passedover to the newly created table of the entity because there is one-many relationship between two types of entity and the key isconsidered as a linking attribute. The new entity then will be studiedto find a key to it.To go from 1NF to 2NF, the analyst must remove any partiallydependent attributes from their 1NF entity and create a new entity.After that, copy that part of the identifier of the original entity (onwhich the removed attributes are dependent) into the new entity.This will probably become part of the unique identifier of thenew entity.

The second normal form (2NF)Every attribute must depend on the entire identifier of its entityfor its value. 2NF only applies to composite primary keys: a relationis in 2NF if, and only if: it is in 1NF and every non_key attribute isdependent on all part s of the primary key. The solution is again anon-loss decomposition that removing the attribute involvedand taking its determinant with it.To move from 2NF to 3NF, the analyst must remove allindependent attributes and put them in an entity of their own.Note that this new entity will now need a unique identifier and issubject to the previous steps.

Third normal form (3NF)A relation is in 3NF if , and only if: it is in 2NF, and no non_keyattribute is functionally dependent on another non-key attribute.This means that, every attribute must not depend on anythingexcept the unique identifier of its entity for a value.

Once Again• Remove the offending attributes• Take the determinant along• The resulting relation is in 3NF• The initial objective has now been reached, each non-key

attribute depends only (and fully) upon the primary key.

160

3NF is often reached in practice by inspection, in a single step. Itsmeaning seems intuitively clear; it represents a formalization ofdesigner’s common sense. This level of normalization is widelyaccepted as the initial target for a design which eliminatesredundancy.The characteristic of 3NF is the removal of non-key attribute.This means that attributes dependent on non-key attribute willbe removed from the list of entities and make up a new key entitytype, which is the said, removed non-key attribute.In fact, there are cases where 2 or more 3NF tables of a list ofattributes of all entities are put together into one table, the mergedtable is still 2NF. This is not surprising because the merged tablemay contain a group of non-key attributes, which had never beenconsidered together, and they may contain one non-key dependency.Thus, after grouping the tables together, it’s necessary to take3NF.In fact, there are some other normal forms that are not widelyused. In system analysis, analysts often use a table in 3NF.To finish the normalization, analyst must double-check thefollowing points:• Is each entity in 0NF, 1NF, 2NF or 3NF?• Check optionality of relationships.• Make sure that no two entities have the same unique identifier

i.e., they are the same thing.• Remove “attributes” which are really M to 1 relationships. In

short, to normalize, analysts must finish the following steps:• Create a list of data items.• Identify derived items.• Choose a unique identifier (a “key”).• Remove repeating groups for that key (and copy across original

key).• Remove “part - key” dependencies (and copy across that part

of the original key).• Remove non-key dependencies.• Bring together data items with the same key.When a list of entities does not reach any of the above normalforms, it is necessary to remove one or more attributes inside it,and create more entities to replace. This means that analysts canstart with a list of planned attributes for an entity type, after goingthrough the 3 normal forms, (s)he can decide to give some of theattributes in the list to other types of entity.At the end of the normalization, the analyst has not only originalentity but also newly defined entity and they all have been fullynormalization.

In the example of library management system, thenormalization process is as followsIt is clear that any book or magazine must be published in alanguage but one language can be used in different documents,thus the relationship between book or magazine with language isa one – many relationship. The same one – many relationship isseen between a document and publishing country...Firstly, we start with the book table: As we see , the book table hasno repeating group and has only one primary key: Book_No, all

the other attributes are dependent on this key, so this table hasbeen in the second normal form. The Lang_Name (languagename), the Lang_Vn (language name in Vietnamese) and theLang_Sys (language system) are only dependent on one attribute:the Lang_No, so we have to normalize them to the third normalform. Similarly with the Nation_Name , the Nation_VN dependson only one attribute: the Nation_No; the Spec_Name dependson only one attribute: the Spec_No; the Coll _Name depends ononly one attribute: the Coll _No. We have the following table: (theattribute underlined is the primary key).

List of attributes 1NF 2NF 3NFBOOK_NOBOOK_NAMESIZETIME_PUBLYEAR_PUBLPUB_HOUSECOSTAUTHORCHIEF_AUTHCOMP_AUTHREV_AUTHLANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMEKW_MASTERKW_SLAVECOMMENT

BOOK_NOBOOK_NAMESIZETIME_PUBLYEAR_PUBLPUB_HOUSECOSTAUTHORCHIEF_AUTHCOMP_AUTHREV_AUTHLANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL _NAME KW_MASTERKW_SLAVECOMMENT

BOOK_NOBOOK_NAMESIZETIME_PUBLYEAR_PUBLPUB_HOUSECOSTAUTHORCHIEF_AUTHCOMP_AUTHREV_AUTHLANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL _NO COLL _NAME KW_MASTERKW_SLAVECOMMENT

BOOK_NOBOOK_NAMESIZETIME_PUBLYEAR_PUBLPUB_HOUSECOSTAUTHORCHIEF_AUTHCOMP_AUTHREV_AUTHLANG_NONATION_NOSPEC_NOCOLL _NO KW_MASTERKW_SLAVECOMMENT

LANG_NOLANG_NAMELANG_VNLANG_SYS

NATION_NONATION_NAMENATION_VN

SPEC_NOSPEC_NAME

COLL _NO COLL _NAME

161

Secondly, we normalize the reader table with itsattributes and have this table

List of attributes 1NF 2NF 3NFREADER_NO

READER_NAME

ADDRESS

BIRTH_DATE

DEPT_NO

DEPT_NAME

COMMENT

READER_NO

READER_NAME

ADDRESS

BIRTH_DATE

DEPT_NO

DEPT_NAME

COMMENT

READER_NO

READER_NAME

ADDRESS

BIRTH_DATE

DEPT_NO

DEPT_NAME

COMMENT

READER_NO

READER_NAME

DEPT_NO

ADDRESS

BIRTH_DATE

COMMENT

DEPT_NO

DEPT_NAME

Thirdly, we normalize the book ticket_L&GB tablewith its attributes


READER_NAME

BOOK_NO

BOOK_NAME

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

READER_NAME

BOOK_NO

BOOK_NAME

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

BOOK_NO

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

READER_NAME

BOOK_NO

BOOK_NAME

READER_NO

BOOK_NO

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

READER_NAME

BOOK_NO

BOOK_NAME

And then, the magazine table, we realize that, the list of attributeshas a repeating group, it includes these attributes: Mag_head_no,mag_name, start_year, mag_shefl, issn_no, pub_house, lang_no,lang_name, lang_vn, lang_sys, nation_no, nation_name,nation_vn, spec_no, spec_name, coll_no, coll_name, andcomment, so we decompose it into a new table with a primarykey: Mag_head_no without data loss. The remaining attributes(mag_head_no, mag_detl_no, year, volume, number, month,quantity) are put in another table with a primary key including 2attributes: Mag_head_no, mag_detl_no. And we have the belowtable

List of attributes 1NF 2NF 3NFMAG_HEAD_NOMAG_DETL_NOMAG_NAMESTART_YEARMAG_SHEFLISSN_NOPUB_HOUSELANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMEYEARVOLUMENUMBERMONTHQUANTITYCOMMENT

MAG_HEAD_NOMAG_NAMESTART_YEARMAG_SHEFLISSN_NOPUB_HOUSELANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMECOMMENT

MAG_HEAD_NOMAG_DETL_NOYEARVOLUMENUMBERMONTHQUANTITY

MAG_HEAD_NOMAG_NAMESTART_YEARMAG_SHEFLISSN_NOPUB_HOUSELANG_NOLANG_NAMELANG_VNLANG_SYSNATION_NONATION_NAMENATION_VNSPEC_NOSPEC_NAMECOLL_NOCOLL_NAMECOMMENT


MAG_HEAD_NOMAG_NAMESTART_YEARMAG_SHEFLISSN_NOPUB_HOUSELANG_NONATION_NOSPEC_NOCOLL_NOCOMMENT

LANG_NOLANG_NAMELANG_VNLANG_SYS

NATION_NONATION_NAMENATION_VN

SPEC_NOSPEC_NAME

COLL_NOCOLL_NAME


And the magazine ticket_L&GB table with itsattributes


READER_NAME

MAG_HEAD_NO

MAG_DETL_NO

MAG_NAME

YEAR

VOLUME

NUMBER

MONTH

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

READER_NAME

MAG_HEAD_NO

MAG_DETL_NO

MAG_NAME

YEAR

VOLUME

NUMBER

MONTH

BORROW_DATE

RETURN_DATE

COMMENT

READER_NOMAG_HEAD_NO

MAG_DETL_NO

BORROW_DATE

RETURN_DATE

COMMENT

READER_NO

READER_NAME

MAG_NAME

YEAR

VOLUME

NUMBER

MONTH

READER_NO

READER_NAME

MAG_HEAD_NO

MAG_DETL_NO

MAG_NAME

YEAR

VOLUME

NUMBER

MONTH

QUANTITY

BORROW_DATE

RETURN_DATE

COMMENT

162




Systems Analysis and Design methods


Systems Analysis and design


Object-oriented systems Analysis andDesign using UML


Object-Oriented Analysis andDesign : with applications




Advanced computer Architecture :

a systems Design Approch


Advanced computer Architectures :a Design space Approch


Systems Analysis, Data processing and

Quantitative Techniques






Notes

163

LESSON 35 :INFORMATION ANALYSIS

Topics Covered• Information analysis

ObjectivesUpon completion of this Lesson, you should be able to:• Discuss about information analysis

Completion of information analysisThis part concludes the description of information analysisdevelopment. The material on the system analysis process describein detail tools and techniques used in analysis completion andprovide a special description of system requirements that userscan evaluate and accept.This special description also serves as the main information sourcefor designers of the system because it explains not only thepurposes of the system but also its scope and requirements thatdesigners have to comply with. The main contents consist of:• Corporation of new requirements• Supporting tools and materials• Summary of analysis process

Corporation of new requirementsIn this lesson, we have discussed the approaches and supportingtools for the system analysis process, especially the function anddata analysis. By developing models, a system analyst defines thesystem’s requirements in most of the cases.However, in some cases, new ideas or requirements in constraint,control, improvements arise from knowledgeable users or therequirements which are found by analysts during the surveyingphase.Those requirements should be discussed and agreed in writtenbetween users and analyst and should be treated as part of thesurveying document and be presented in the system’s models.Normally, new requirements are added to the current model fromfunctional diagram and adjusted in other models if necessary.This adjustment must be done carefully to make sure that themodel is simply designed. It should be noted that one newrequirement can be put into the system in different ways. It is thenthe analyst’s duty to find the simplest and most suitable way fromthe users’ perspective.In fact, there are cases where the new system is not developed baseon any current system because the difference between the old andthe new system is so big that there is no need to model the oldsystem. The modeling of the new system is done with themethods discussed in the previous parts of this materialsWhile analyzing the system, we can see that there are 4 main modelsmaking up requirement specification, each model is concerned toone aspect of the system.• Functional diagram shows the functions that the system will

have to perform, not how to perform.

• Data flow diagram also concentrates on functions, but itconsiders the necessary information to perform the relatedduties.

• Data model and relationship model have hardly anything todo with functions, they concentrate to describe the system’sinformation in different levels and the relationship among them.

Although each model has its own characteristic and objective, theyactually have a very close relationship with each other: These modelsare the basis for designing other models. Therefore, changes inany model may result in changes or adjustments to secure theconformity among models.

Supporting tools and materialsThe major tools supporting the analysis processinclude

• Process Description• Data dictionary• Seminar (meeting)

Process DescriptionProcess description is actually detailize the system’s requirementsdisplayed in function diagram and data flow diagram.Some of the tools for process description are: block chart, decisiontable, structured language... Of those tools, structured language(structured English) is considered one of the most useful andpopular tools for process description because it is simple for usersand other members taking part in developing the system’s lifecycle. Structured language consists of:• Imperative verbs• Technical terms defined in Data dictionary, relationship model

or other models• Some logical words to make up sentences and structureThe process must be described by using one of the 3 maindeveloped structures in structured programming: Orderly, selectiveand repetitiveOrderly structure is simply description commands for a process tooccur following another process.Selective structure is used when a decision must be made duringthe process base on 2 or more selection possibilities. The basicstructure of the commands is: If ... Then ... Else;

CASE...

Repetitive structure is used when there is a need to repeat a seriesof actions in the process. The basic structure of the commands is:For...do While...Thus, process description is not only useful in the analysis processbut is also used to describe the designing process of the physicalsystem and the programming process afterwards

164

DictionaryWith the development of Information Technology and thegeneration of professional software, data dictionary is becomingmore popular and important to those who is interested in systemdevelopment.Data dictionaries differ due to the different defining standards,different software and hardware environments, or different users.However, regardless of different methodologies, data dictionariesmust present simple explanations, the manner to record process’snames, the storage manner and how to search for detailinformation of the system.This means a Data Diagram describes the data flows in a DataFlow Diagram, the structure of data packages in flowing motionas well as the data packages in storage. It also means the specificationof value and unit of information inside the data flow and datastorage, the specification of the information relationships betweenstorage inside the entity relationship diagramThe best way to develop a Data Diagram is to use automaticmeans (professional programs for data dictionary development)to enter the dictionary’s entries, and to check the accuracy andsuitability of the data put into the system. In case there is not anautomatic means, analysts should use the traditional wordprocessing system to develop a text file for the data dictionary’sentriesIn short, data dictionary development is very essential and timeconsuming in system analysis, without it, the analysis outcomesmay become meaninglessSeminarThe seminar technique is a meeting where analysts present theirwork in different phases. It gives discussion opportunities tousers and the system development team (including analysts,designer and programmer) to improve shortcomings in the systembefore it is really approved. Presenters must prepare theirpresentation very carefully and talk about it in a simple, clear andshort way.They also have to be aware that this is not a scientific seminar, andthat everything they present must be made easy to understand bythe users. The key to success of the seminar is the behavior ofseminar attendees themselves: any criticism, comments shouldn’tbe directed to any individual who owns the matter underdiscussion, they should be directed to the common work.Thus, seminar attendees are not expected to re-design the models(in their own opinions), they are expected to point out the weakpoints and irrelevant parts and give suggestions to analysts forthem to improve those parts.In case there are serious mistakes, analysts should be asked tosubmit it again after successfully correcting the mistakes. After allmodels have been tested and approved, system developmentteams should sign approve and consider the approved models asound foundation for the following development steps.In each seminar, attendees have to agree to the following roles:Coordinator: who is responsible for organizing the seminar;sending seminar invitations and hand-outs to attendees and givethem enough time to think of the issues that will be discussed inthe seminar. For the best outcome of the seminar, the coordinator

has, right in the first place, give clear objectives of the seminar, fixtime slot for presenters and direct all the comments to the setobjectives.Secretary: who is responsible for taking notes of all the commentsand may be asked to summarize the discussed points. All decisionsmade during the seminar must be noted down carefully.Presenters: who are responsible for making presentations asapproved by the coordinator. While presenting, make sure to giveeveryone discussion opportunities. Don’t try to protect what youhave done. Consider other people including users attending theseminar are those who help analysts make clear of their ownrequirements. Any interviewers are expected to give constructivecomments which can be a hint, a confirmation, an idea from theusers’ perspective or just a clarification of requirements.

Summary of analysis processThis material has described in detail the tools and techniques thatare used to complete system analysis and give a requirementspecification to users to review and approve. This specification isalso the main source of information for the new system designers.It not only explains the system’s objectives but also gives a scaleand limitations with which designers have to comply.Thus, at the end of the system analysis phase, analysts have togive adequate material of system requirement specification whichhas been approved by users. The material should the nameobjectives, supporting tools and methods to do the followingthings:Contents and scale of system analysisSummary of management workFunction diagramData flow diagramData modelRelationship modelProcess descriptionData dictionaryThe result of this phase is the 3 important diagrams: the FunctionHierarchy Diagram, the Data Flow Diagram, and the EntityRelationship Diagram. These diagrams are very important, wecannot continue without them during the system building process.They are inputs for the next phase: System Design.

QuestionsDescribe Structured Analysis. List certain tools of StructuredAnalysis.The Claremont school course catalog reads as follows: “ To enrollin CIS 288 which is an advanced course , a student must completetwo prerequisites –CIS 110 and CIS 286. A student who completeseither one of the prerequisites and obtains the instructor’spermission, however , will be allowed to take CIS 288.”(i) Create a decision table that describes the Claremont School

course regarding eligibility for CIS 288. Show all the possiblerules.

(ii) Draw a decision tree to represent the Claremont School catalog.Describe the results.

(iii) Why might you use a decision tree rather than a decision table?

City Bus Lines is developing an information system that willmonitor passenger traffic, peak travel hours and equipmentsrequirements. The IT manager wants you to document a processthat will determine if extra buses are needed on a route andautomatically assign them if all other routes are operating onschedule. During peak periods, however a dispatcher will beallowed to override the system and shift buses from one route toanother.(i) Create a decision table that describes the bus transfer process(ii) Draw a decision tree that describes bus transfer process.(iii) Name four attributes that u can use to define a data flow in the

bus information system(iv) Name four attributes that u can use to define a data store in

the bus information systemThe Claremont school course catalog reads as follows: “ To enrollin CIS 288 which is an advanced course , a student must completetwo prerequisites –CIS 110 and CIS 286. A student who completeseither one of the prerequisites and obtains the instructor’spermission, however , will be allowed to take CIS 288.”(i) Create a decision table that describes the Claremont School

course regarding eligibility for CIS 288. Show all the possiblerules.

(ii) Draw a decision tree to represent the Claremont School catalog.Describe the results.

(iii) Why might you use a decision tree rather than a decision table?

State the difference between System design andDetailed design.

1. What is structured design?2. How do system analysis and design relate to each other?3. What are the main phases of the design process?4. What are the main tools and design techniques?5. What is logical design and its main tasks?6. What is physical design and its main tasks?7. How do you distinguish between logical design and physical

design?8. Why do you need to identify the borderline of the computer

system in the system DFD? How do you present them in themodel?

9. What are the main components of computer-user interfacedesign?

10. Why is it necessary to design system monitoring?11. How do you organize the system’s components?12. What are the main modeling tool and techniques?13. What are the tools used in data usage analysis?14. What is navigation model and its purpose?15. What are the main components of a database and the role of

each component?




Systems analysis and Design Methods




Object-Oriented systems Analysis and

design using UML


Object-oriented analysis anddesign : with applications




Advanced computer architecture :a systems design approch


Advanced computer architectures :a design space approch







