THE INFORMATION SYSTEM ENVIRONMENT

The term system is derived from Greek word system, which means an organized
relationship among functioning units or components. A system exists because it is
designed to achieve one or n objectives.
The study of systems concepts, then, has three basic implications:
I. A system must be designed to achieve a predetermined objective.
2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have •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. pay-roll) available to the accounting division on bequest.

CHARACTERISTICS OF A SYSTEM

ORGANISATION: Organization implies structure and order. It is the fl of components

that helps to achieve objectives. In the design of a business system for example, the
hierarchical relationships starting with the president on top and leading downward to the
blue-collar workers represents the organization structure. Slouch an arrangement portrays
a system subsystem relationship, defines the authority structure, specifies the formal flow
of communication, and formalizes the chain of command. Like-wise, a coi system is
designed around an input device, a central processing unit, an output device, and one or
more storage units. When linked together they work as a whole system for producing
inform

INTERACTION : Interaction refers to the manner in which each component functions

with other components of the system. In an organization, for example, purchasing must
interact with production, advertising with sales, and payroll with personnel. In a compute
system, to solve a problem. In turn, the main memory holds programs and data that the
arithmetic unit uses for computation. This interrelationship between these components
enables the computer to perform.

1
INTERDEPENDENCE : Interdependence means that parts of the organization or
computer system depend on one another. They are coordinated and linked together
according to a plan. One subsystem depends on the input of another subsystem for proper
functioning, that is, the output of one subsystem is the required input for another sub
system.

INTEGRATION : Integration refers to the holism of system; synthesis follows analysis

to achieve the central objective of the organization. Integration is concerned with how a
sys is tied together. It is more than sharing a physical part of location. It means that parts
of the system work together within the system even though each part performs a unique
function, Successful integration will typically produce a synergistic effect and greater
total impact than if each component works separately.

CENTRAL OBJECTIVE : The last characteristics of a system are its central objective.
Objectives may be real or stated. Although a stated objective may be the real objective, it
is not uncommon for
• an organization to state one objective and operate to achieve another. The important
point is that users must know the central objective of a computer application early in the
analysis for a successful design and conversion. The political as well as organizational
considerations often could the real objective.
This means ‘that the analyst must work around such obstacles to identify,’ the real
objective of the proposed change

2
ELEMENTS OFA SYSTEM
In most cases, systems analysis operate in a dynamic environment where change is ‘a
way of life. The environment may be a business firm, a business application, or a
computer system. To reconstruct a system, the following key elements must be
considered: -
Environment

CONTROL

INPUT PROCESS OUTPUT

FEEDBACK
Boundary

1. Outputs and inputs

2. Processor(s)
3. Control
4. Feedback
5. Environment
6. Boundaries and interface.

OUTPUTS AND INPUTS : A major objective of a system is to produce an output that

has value to its user. Whatever the nature of the output (goods, services or information), it
must be in line with the expectations of the intended user. Inputs are the elements
(material, human resource, information) that enter the system for processing. Out is the
outcome of processing. A system fields on input to produce output in much the same way
that a business brings in human, financial and material resources to produce goods and
services. It is important to point out here that determining the output is a first step in
specifying the nature, amount, and- regularity of the input needed to prepare a system.

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

CONTRQL : The control element guides the - system. It is the decision making
subsystem that controls the- pattern of activities governing input, processing, and output.
In an organizational context, management as a decision making body controls the inflow,
handling and outflow of activities that affect the welfare of the business. In a computer
system, the operating system and accompanying software influence the behavior of the
system. Output specifications determine what and how much input is needed to keep the
system in balance.
In systems analysis, knowing the attitudes of the individual who controls the areas for
which a computer is being considered can make a difference between the success and
failure of the installation. Management support is required for securing control and
supporting the objective of the proposed change.

FEEDBACK : Control in a dynamic system is achieved by feedback. Feedback

measures output against a standard in some form of cybernetic procedure that includes
communication and control output information is fed back to the input and/or to
management (controller) for deliberation. After the ‘output is compared against
performance standards, changes can result in the input or processing and consequently
the output.
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. In systems analysis,
feedback is important in different ways. During analysis, the user may be told that the
problems in a given application verify his/her initial concerns and justify the need for
change. Another form of feedback comes after the system is implemented. The user

4
informs the analyst about the performance of the new installation. This feedback -often
results in enhancements to meet the user’s requirements.

ENVIRONMENT: The environment is the “suprasystem” within which an organization

operates. It is the source of external elements that impinge on the systemic. In fact it often
determines now a system must function.
BOUNDARIES AND INTERFACES : A system should be defined by its boundaries-
the limits that identify its components, processes, and interrelationships when it interfaces
with another system. For example, a teller system in -a commercial bank is restricted to
the deposits, withdrawals, and related activities of customers checking and savings
accounts. It may exclude mortgage foreclosures, trust activities and the like. Each system
has boundaries that determine its sphere of influence and control, although in an
integrated banking wide computer system design, a customer who has a mortgage and a
checking account with the same bank may write a check through the “teller system” to
pay the premium that is later processed by the “mortgage loan system”. Recently system
design has been successful in allowing the automatic transfer of funds from a bank
account to pay bills and other obligations to creditors, regardless of distance or location.
This means in system analysis, knowledge of the boundaries of a given system is crucial
in determining the nature of its interface with other systems for successful design.

TYPES OF SYSTEMS
The frame of reference within which one views a system is related to the use of the
systems approach for analysis. Systems have been classified in different ways. Common
classifications are (I) physical or abstract, (2) open or closed and “man-made”
information systems.

PHYSICAL OR ABSTRACT SYSTEMS: Physical systems are tangible entities that

may be static or dynamic in operation. For example, the physical parts of the computer
center are the offices, desks, and chairs that facilitate operation of the computer. They can
be seen and counted; they are static. In contrast, a programmed computer is a dynamic
system. Data, programs, output and applications change as the user’s demands or the

5
priority of the information requested changes. Abstract systems are conceptual or
nonphysical entities. They may be as straightforward as formulas of relationships among
sets of variables or models - the abstract conceptualization of physical situations. 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 under study.
The objective is to point out the significant elements and the key interrelationships of a
complex system.

OPEN OR CLOSED SYSTEMS : Another classification or systems is based on their

degree of independence. An open system has many interfaces with its environments, it
permits interaction action across its boundary; it receive an inputs from and delivers
outputs to the outside. An information system falls into this category, since it must adapt
to the changing demands of the user. In contrast, a closed system is isolated from
environmental influences. In reality, a completely closed system is rate. In systems
analysis, organizations, applications and computers are invariably open, dynamic systems
influenced by their environment.

MAN-MADE INFORMATION SYSTEMS : Ideally, information reduces uncertainty

about a state or event. For example, information that the wind is clam reduces the
uncertainty that the boat trip will be pleasant. An information system is the basis of
interaction between the user and the analyst. It provides instructions, commands and
feedback. It determines the nature of the relationships among decision makers. In fact, it
may be viewed as a decision centre for personnel at all levels. From this basis, an
information system may be defined as a set of devices, procedures, and operating
systems’ designed around user-based criteria to produce information and communicate it
to the user for planning, control and performance. In systems analysis, it is important to
mind the considering an alternative system means improving one or more of these
criteria.

FORMAL INFORMATION SYSTEMS : A formal information system is based on the

organization represented by the organization chart.

6
The chart is a map of positions and their authority relationships, indicated by boxes and
connected by straight lines, it is concerned with the pattern of authority, communication
and work flow. Information is formally disseminated in instructions, memory or reports
from top management to the intended user in the organization. This structure also allows
feedback up the chain of command for follow-up.

INFORMAL INFORMATION SYSTEMS : The formal information system is power -

structure designed to achieve company -goals. An organization emphasis on control to en
performance tends to restrict the communication flow among employees; however as a
result, an informal information system develops. It is an employee based system designed
to meet personnel and vocational needs- and to help solve work-related problems. - It
also tunnels information upward through indirect channels. In this respect, it is a useful
system because it works within the framework of business and its stated policies. –

7
 ROLE OF SYSTEM ANALYST
Definition: Analyst is a person who conducts a methodical study and evaluation of an
activity such as a business to identify its desired objectives in order to determine
procedures by which these objectives can be gained.

The interpersonal skills relevant to systems work include the following :-

1. Communication : having the ability to articulate and speak the language of the user a
“flare” for mediation, and a knack for working with virtually all managerial levels in the
organization. Communication is not just reports, telephone conversation and interviews.
It is people talking, listening, feeling and reacting to one another, their experience and
reactions. Some indicators of a climate of closed communication are defensive demos,
excessive correspondence, and a failure to speak up for fear of being identified. -
Therefore, opening communication channels are a must for system development.

2. - Understanding : identifying problems and assessing their ramifications, having a

grasp of company goals and objectives, and showing sensitivity to the impact of the
system on people at work.
3. Teaching: educating people in use of computer systems. Selling the system to the user,
and giving support when needed. ,-
4. Selling : selling ideas and promoting innovations in problems solving using computers.
The technical skills include:
1. - Creativity : helping users model ideas into concrete plans and developing - candidate
system to match user requirements. - -
2. Problem solving : reducing problems to their elemental levels, for analysis, developing
alternative solutions to a given problems, and delineating the pros and cons of candidate
systems.
3. Project Management : scheduling, performing well under time constraints,
coordinating team efforts, and- managing costs and expenditures. -
4. Dynamic interface-blending technical and non-technical considerations in functional
specifications and general designs.

8
5. Questioning attitude and inquiring mind-knowing the what, when, why, who and how
a system works.
6. Knowledge of the basics of the computer and the business function.

The background and experience of analysts include:

1. A background in systems theory and organization behavior.
2. Familiarity with the make up and inner working of major a such as financial
accounting, personnel administration marketing and sales, operations management,
model buildings, and production control.
3. Competence in system tools and methodologies and a practical knowledge of one or
more programming and database languages.
4. Experience in hardware and software specifications, which is important for selection.
Awed conducted a study to determine the personal attributes of analyst and what attracts
them to systems analysis.
The attributes are:
1. Authority : the confidence to “tell” people what to do, much for this quality shows in
project management and team work to meet deadlines.
2. Communication skills: ability to articulate and focus on a problem area for logical
solution.
3. Creativity : trying ones own ideas,. developing candidate systems using unique tools
or methods.
4. Responsibility: making decisions on one’s own and accepting consequences for these
decisions.
5. Varied skills: doing different projects and handling change.

ROLE OF ANALYST
CHANGE AGENT : In the role of a change agent, the systems analyst may select
various styles to introduce change to the user organization. The styles range from that of
persuader (the mildest form of intervention) to imposer (the most severe intervention) in
between; there are the catalyst and the confronter roles. What the user appears to have a
tolerance for change, the persuader or catalyst (helper) style is appropriate.

9
On the other hand, when drastic changes are required, it may be necessary to adopt the
confronter or even the imposer style. No matter what style is used, however, the goal is
the same; to achieve acceptance of the candidate system with a minimum of restriction.

INVESTIGATOR AND MONITOR : Related to the role of investigator is that of

monitor; to undertake and successfully complete a project, the analyst must monitor
programs in relation to them, cost and quality.

ARCHITECT : As architect, the analyst also creates a detailed physical design of

candidate systems. He/she aids users in formalizing abstract ideas and provides details to
build the product the candidate system.

PSYCHOLOGIST : In systems development, systems are built around people. This is

perhaps a bit exaggerated, but the analyst plays the role of a. psychologist in the way
he/she reaches people, interprets their thoughts, assesses their behavior and draws
conclusions from these interactions, understanding interventional relationship is
important.

SALES PERSON : Selling the system actually takes place at each step in the system life
cycle; however, sales skills and persuasiveness, then, are crucial to the success of the
system.

MOTIVATOR : The analyst’s role as a initiator becomes obvious during the first few.
weeks after implementation and during time when turnover results in which people being
trained to work with the candidate system. The amount of dedication it takes to motivate
users often taxes and analyst’s abilities to maintain the pace. What was once viewed as a
challenge can easily become a frustration if the user’s staff continues to resist the system.

POLITICIAN : Related to the role of motivator is that of politician. In implementing a

candidate system, the analyst tries to appease all parties involved. Diplomacy and
fineness in dealing with people can improve acceptance of the system, In as much as a

10
politician must have the support of his/her constituency, so is the analysts goal to have
the support of the users’ staff. He/she represents their thinking and tries to achieve their
goals through computerization.
Apart from the System Analyst others involve in the system development project are:

* Users
Operational Users: They are clerical, operational and administrative people most likely
to have the most day-to-day contact with the new system. They are human interface to the
system.
Supervisory Users: are one who will typically define the requirements and detailed
business polio that your system must implement. They may be passive members of the
time, fill-time member of team or a project manager.
Executive-level Users: are not directly involved in system developrnent project but they
may. provide the initiative for the project. They are concerned with global view of the
entire system and generally able to work with abstract models of system.
* Management
User Managers: in charge of several people in the operational area where the new
system will be used.
EDP/MIS Managers: the person in charge of the systems development project itself and
concerned with overall management and allocation of resources of all the technical staff
in the system development organization.
General Management: Top level managers who are not directly involved. in the project.
They focus more on the external information and interested in strategic laming system
and decision support systems.
* Auditors, quality assurance people and standard bearers: These are involved at the
very end. They are accustomed with documentation standards and system standards.
* Programmers
They are the people who develop the code according to the standards and procedures laid
down through system study by system analyst.

11
 SYSTEMS DEVELOPMENT LIFE CYCLE
Systems development is a process consisting of the two major steps of systems analysis
and design. It starts when management or sometimes systems development personnel
realize that a particular business system needs improvement.
The systems development life cycle (Figure 1.6) is the set of activities analysts,
designers, and users carry out to develop and implement an information system.
The systems development life cycle consists of the following activities:
1. Preliminary investigation
2. Determination of requirements
3. Development of prototype system
4. Design of system
5. Development of software
6. Systems testing and for
7. Implementation analysis.

Preliminary
Investigation

Determination Development
of of prototype
requirements system

Design of Development System Implementatio

system of system testing n

12
PRELIMINARY INVESTIGATION

When that request is made the first systems activity, the preliminary investigation,
begins. This activity has three parts request clarification, feasibility study, and request
approval. The result will be to approve the request further attention or reject it as not
feasible for further development.

REQUEST CLARIFICATION
Many requests from employees and users organizations are not clearly stated. Therefore,
before any systems investigation can be considered, the project request must be examined
to determine precisely what the originator wants) A simple telephone clip may suffice if
the requester has a clear idea but does not know how to state it. On the other hand, the
requester may merely be asking help without knowing what is wrong or why there is a
problem. Problem clarification in this case is much more difficult. In either case, before
any further steps can be taken, the project request must be clearly stated.

FEASIBILITY STUDY

An important outcome of the preliminary investigation is the determination that the

system requested is feasible. There are three aspects in the feasibility study portion of the
preliminary investigation:
1. Technical feasibility. Can the work for the project be done with current equipment?
Software technology and available personnel? If new technology is required, what is the
likelihood that it can be developed?
2. Economic feasibility. Are there sufficient benefits in creating the system to make the
costs acceptable? Or, inversely, are the costs of not creating the system so great that the
project must be undertaken?
3. Operational feasibility. Will the system be used if it is developed and implemented:
Will there be resistance from users that will undermine the possible application benefits?
The feasibility study is carried out by a small group of people (sometimes even one or
two), who are familiar with information systems techniques, understand the part of the

13
business or organization that will be involved or affected by the project, and are skilled in
the systems-analysis and design process. Typically people responsible for feasibility
assessments are experienced, not new, analysts or managers.

REQUEST APPROVAL

Not all requested projects are desirable or feasible. (In fact, some organizations receive so
many project requests from employees that only a few of them can be pursued.)
However, those that are both feasible and desirable should be put into a schedule. In
some cases, development can start immediately. But in most cases, systems staff
members are busy on other ongoing projects. When this happens, management decides
which projects are most important and schedules them. Many business organizations
develop information systems plans as carefully as they plan for new products, new
manufacturing programs, or plant expansion. After a project request is approved, its cost,
priority, completion time, and personnel requirements are estimated and used to
determine where to add it on any existing project list.
Later on, when other preceding projects are completed, the proposed application
development can be launched. At this time, the collection of data and determination of
requirements begin.
Determination of Requirements
The heart of systems analysis is aimed at acquiring a detailed understanding of all
important facts of the business area that is under investigation. (For this reason, this
activity is often termed the detailed investigation.) Analysts, working closely with
employees and managers, must study the business process to answer these key questions:
1. What is being done?
2. How is it being done?
3. How frequently does it occur?
4. How great is the volume of transactions or decisions?
5. How well is the task being performed?
6. Does a problem exist?
7. If a problem exists, how serious is it?

14
8. If a problem exists, what is the underlying cause?
To answer these questions, systems analysts will talk to a variety of person to gather
details about the business process and their opinions of why things happen as they do and
ideas about change. Questionnaires are used to collect this information from large groups
of people who cannot be interviewed individually. Detailed investigations also require the
study of manuals and reports, actual observation of work activities, and sometimes
collection of samples of forms and documents to fully understand the process.
As the details are gathered, the analysts study the requirements data to identify features
the new system should have, including other the information the system should produce
and such operational features as processing controls, response times, and input and output
methods.
Development of Prototype System

The prototype is a working system. However, it is designed to be easily changed.

Information gained through its use is applied to a modified design. The modified version
may again be sued as a prototype to reveal still more valuable design information. The
process is repeated as many times as necessary to reveal essential design requirements.
Prototype development often coincides with systems design.

Design of System

The design of an information system produces. the details .that state how a system will
meet the requirements identified during systems Often systems specialists refer to this
stage as logical design, in contrast to developing program software, which is referred to
as physical design.
Systems analysts start by Identifying reports and other outputs the system will produce.
Then the specific data on each is pinpointed, including its exact location on the paper,
display screen, or other medium. Usually designers sketch the form or display as they
expect it to appear when the system is completed. -
The systems design also describes the data to be input, calculated, or stored. Individual
data items and calculation procedures are written in detail. Designers select file structures

15
and storage devices, such as magnetic disk, magnetic tape, or even paper files. The
procedures they write tell how to process the data and produce the output.

The documents containing design the specific actions use m any different ways to portray
the design-charts, tables and special symbols-some of which you may have used and
others that they be tally new to you. The detailed design information is passed on to the
programming staff so that soft are developrnent can begin.
Designers are responsible for providing program mars with complete and clearly outlined
specifications that state what the software should do, As programming starts, designers
are available to answer questions, clarify fuzzy areas, and handle problems that confront
the programmers when using the design specifications.

Development of Software

Software developers’ m ay install or modify and then install purchased corn metrical
software, or they may write new, custom-designed programs. The decision about which
to’ do depends on the cost of each option, time available to write software, and
availability of programmers. Type in larger organizations, corn putter program mars (or
corn inaction analyst—program mars) are part of the permanent professional staff. In
smaller firms, where permanent programmers have, not been hired, outside programming
services may be retained on a contract basis. As we see in later chapters, there are several
approaches to developing the software,
Programmers are also responsible for documenting the program, including comments that
explain both how and why a certain procedure was coded in a ‘specific way.
Documentation is essential to test the program and carry on maintenance once the
application has been installed.

Systems Testing

During testing system is used experimentally to ensure that the software does not fail, i.e.
• that it will run according to its specifications and in the way users expect it to. Special

16
test data is input for processing, and the results are ‘examined to locate unexpected
results. A limited number of users’ may also be allowed to use the system so analysts can
see whether they try to use it in unexpected ways it is preferable to find these surprises
before the organization implements the system and depends on it.
In many organizations, testing is performed by persons other than those who wrote the
original programs. Using persons who do not know how certain parts were designed or
programmed ensures more complete and unbiased testing and more reliable software.

Implementation

When systems personnel check out and put new equipment into use, train user personnel,
install the new application, and construct, any files of data needed use it, we say it is
implemented.
Depending on the size of the organization that will be involved in using the application
and the risk associated with its use, systems developers may choose only to pilot (test) the
operation in one area of the firm, say in one department or with just one or two persons.
Sometimes they will run both the old and new systems together to compare the results of
both. In still other situations, developers will stop use of the old system one day and
begin use of the new one the next. As we will be seeing, each implementation strategy
has its merits, depending on the business situation in, which it is considered. Regardless
of the implementation strategy used, developers strive to ensure that the system’s initial
use is trouble-free.
Once installed, applications are often used, for many years. However, both the
organization and, the users will change. And the environment will be different over
weeks and months too. Therefore, the application will undoubtedly” be maintained. That
is, modifications and changes will be made to the software, files, or procedures to meet
emerging user requirements. Organization systems and the business environment are in
continual change. The inform action systems should keep pace. In this sense,
implementation is an ongoing process.

17
WHAT IS REQUIREMENT ANALYSIS:

A requirement is a feature that must be included in a system. These requirements can be

at various levels of the organization. These can be at the
• Operational level
• Decision-making level Individual level
• Organization level.

Analysis is the process of identifying what a system does. Requirement Analysis is the
process of identifying what the requirements of a system are and how they are being
catered to currently? The activities involved in this process have been exhibited in the
flow diagram of the following figure.
Project initiation is the first step which includes the preliminary investigations and a
formal approval to begin the project. Facts are then gathered in detail to identify the
business processes’ and data exchange. These facts are documented using standard tools
and notations. These documented facts are then analyzed and a set of alternative solutions
is suggested with the corresponding pros and cons. A formal approval of the cover each
of these steps is sufficient depth from a manager’s perspective. However, we shall here
omit a detailed study of the tools of systems analysis and design.
The outputs of requirements analysis are:
• Feasibility report
System requirements specifications.

FEASIBILITY STUDY:

A feasibility study must be carried out to analyze the cost benefit of the project. The
following aspects of feasibility should be studied,

Technical feasibility: rat is important to analyze whether the hardware and software
solution recommended by the user and the IT professional is technically perfect to fit the
scenario. The technical queries must be handled, e.g. is the technology to be used current

18
 and the latest? Is it compatible with the already existing technology base in the
organization? Is it compatible with the technical skills of the organization?

Economic Feasibility: This includes the study of all the expected costs and benefits of
the proposed software project. This is the most important part of the feasibility study
from a business perspective.
But since most of the benefits of IS are intangible, it is’ not quire straight forward to
study this aspect.
A list of tangible benefits is included in the table below:

TANGIBLE BENEFITS:
 Increased productivity Low operating cost.
 Reduced workforce
 Lower outside vendor costs
 Reduced expense growth rate.

INTANGIBLE BENEFITS:
 Improved asset utilization
• Improved resource control
• Improved organizational planning
• More timely information.
• Increased flexibility
• Enhanced goodwill
• Increased job satisfaction
 Improved decision-making
 Better image
 Improved operation.

For tangible cost-benefit analysis, various capital budgeting models like the Net Present
Value, Internal Rate of Return etc. can be applied.

19
For intangible benefits analysis, Portfolio analysis and scoring models are useful models
Portfolio contains a profile of the risks and benefits of an IS to a firm The risks can be
related to time or cost over-runs, low performance level, incompatibility of hardware and
software platform etc. For information intensive companies, a High-risk - High benefit
combination can also be accepted but, in non-information intensive companies, a Low-
risk - High benefit situation is preferred Scoring Model allocates a single score based on
the extent to which various alternatives meet the set objectives All the solution
alternatives are judged on the basis of certain set criteria, e g per cent user needs met,
initial purchase cost, chances of success etc the following steps are generally followed to
generate the scores and evaluate the feasibility of a proposal
• Identify alternative solutions to the problem
• Identify the criteria for decision-making
• Assign weights to each criterion
• Give the user judgment on a scale of 5 - 0 for low merit and 5 for high merit calculate
the weighted averages and compare to find out the most preferred solution alternative

Legal Feasibility: It must be made sure that the propose system abides by all the laws of
the land and business

Operational Feasibility: Many good software’s remain unused forever because they do
not get any effective users. Thus; it is imperative to study the system for operational
feasibility to find out if the proposed system can be used by the employees-or not? Does
it fit into the organization culture? Is it easy to use?

Schedule Feasibility: It is wise to verify that the project can be finished well before the
actual requirement of its usage. If a solution is provided after the significance of the
problem is reduced or lost, it is worthless to have the solution

WHAT IS SYSTEMS DESIGN

Design is a translation of the requirements into ways of meeting them it emphasizes How
to do? In more detail, we can say that Design is an iterative process of taking a logical

20
model of a system together with a strongly stated set of objectives for that system and
producing the specifications of a physical system that will meet those objectives.
Initially, a logical design is produced by modifying the already defined system models
then the physical implementation details are added to it which include the machine and
the interface parts

WHAT IS TO BE DESIGNED?

The exercise of design should generate a blue print of the new system. This includes
content requirements of the following system components
• Outputs, i.e., the reports, on-line displays. This is a sensitive issue as the ultimate
success of any software depends on the quality of the outputs it generates
• Inputs, i.e. the forms, screens Design of input is vital as it defines the quality of data
being entered into the machine. Unless correct data is entered, no useful output can be
generated.
• Procedures, i.e. structures of procedures to collect, transform and output data.
• Data base interactions, i.e. identifying the requirements of data storage and
management.
• Controls, i.e. the requirements for data integrity, security and procedures for recovery.
Sound logical design is important for the long-term effectiveness of the system. On an
average of the lifetime software cost of a system goes into maintenance consequently, it
is vital that the designer translates the requirements of the users into a physical design
which fulfills the system requirement, but in a way that imposes the least possible
maintenance burden.

WHAT IS IMPLEMENTATION?

Implementation refers to all of the or activities working towards the adoption, manage
mental and reutilization of an innovation It is the process of converting from an old to a
new system This new system can be a replacement of a manual system or a major

21
modification to an already existing Computer Based IS There are three major approaches
to the implementation process:

Actor’ Role: This approach believes that organizations should select actors with
appropriate social characteristics and systematically develop organizational roles, such as
product champions, bureaucratic entrepreneurs, gatekeepers in Order to innovate
successful this approach focuses on early adoption and management of innovations.
Strategic Approach A second school of thought focuses of strategies of
innovation the two extremes are:
Top-down Innovation For the success of a system the senior management support is
important as no innovation, leadership, encouragement and resources can flow down
unless the top facilitates them.
Grassroots innovations Without strong grass-roots and end-user participation, IS
projects may be doomed to failure.
For the success of any system, all the levels, specially the top and lower levels should be
wholly participative at every stage of systems development.

Organizational Change A Third approach to implementation focuses on general

organizational change factors as being decisive to the long-term rumination; innovations
the following list illustrates some of the key organizational actions required for long-
term, successful implementation:
• support by local funds.
stable supply and maintenance
• new personnel classification
• changes an organizational authority
• internalization of the training program
• continual updating of the system
• promotion of key personnel
• survival of the system after turnover of its originators attainment of widespread use

22
 FACT GATHERING

To solve any systems problem, it must be studies in detail to understand the information
Requirements in detail the system should be studied and facts be gathered for the
following aspects
• Business processes
• Data used or produced
• Limits of time and volume of work
• Performance controls suet
Different fact finding techniques can be used for this as
Observation it covers all the points missed by the above methods sometimes, sitting and
observing the daily dealings may bring out many undocumented facts which add to the
practicality of the solution.
This is not a specific technique which can be taught but is rather a subjective assessment
of those factors likely to pro of importance. Observation implies formally observing an
activity to identify problems, skill characteristics, time requirements, environmental
conditions, arrival of information etc. The key to successful observation is to take a
purely passive and patient role, not interfering in any way with the process itself which
must be allowed to take place as it normally would.

Interview: This technique is used to gather the unstructured facts, generally from the top
people in the organizational hierarchy. ‘It is. better to plan the structure of the interview
and the questions to be asked, before meeting the person to make sure that all the
important points are well addressed.
Interviews are by far the most common and most satisfactory way of obtaining
information, particularly to obtain information about objectives, constraints, allocation of
duties, problems and failures in the existing system.
Whom to interview this depends. On who has the required information? It may be
advisable, even though time consuming to go down through a hierarchy to arrive at the
person.

23
When to interview there may be a most desirable sequence based on the kinds of
information to be collected, so that one interview can build on information already
collected. No attempt should be made to dictate when the interview to be conducted.
Interview should take place at a time so that it causes the least disturbance to the work
and the personal arrangement of the person to be interviewed.
What to ask to make the best of the available time, it is important to obtain prior
knowledge of the duties and responsibilities from which a check list can be drawn up. . It
is an important to ask questions at the right level.
Where to hold the interview often the only available place is the normal work place of the
person. This an be an added advantage, since the interviewer will be more at home and
Additional information can be obtained from observation. Interruptions may tell a lot
more about the problem than the interview itself.
Before an interview
- Make an appointment
- Be prepared
- State the reason for the interview
During the interview
- Observe good manners
- Don’t interrupt
- Avoid Yes/No questions
- Don’t express your opinion
- Compliment when possible
- Distinguish between fact and opinion
- Distinguish between need and desire
- Don’t be asked to leave
After’ the interview
- Check information obtained.
- ‘Confirm results of discussion.

Questionnaires: If the facts to be gathered are structured and they have to be

accumulated from a large number of employees, this is a preferred technique over

24
interview. A questionnaire contains a well knit set of questions that cover the entire range
of business processes. It is normally used to gather data from the middle and lower levels
of management. This technique has the advantage that the user can fill it in one’s own
time, in the absence of the systems analyst also. However a lengthy and vague
questionnaire may affect the responses of the users.
This form of investigation must be used with great caution. Considerable skill and field
testing are required to avoid confusion, ill-will and misinformation. This method of
investigation will be most suitable method where -
- Staff are located over a widely spread geographical area
- A large number of staff is required -to furnish data .
- Verification of data collected, by other methods of investigation.
- 100 percent of coverage is not essential.
One of the major problems in questionnaires design is that it is difficult to frame
questions which are certain to obtain the exact data required. Also it is a feature of bulk
questionnaire surveys that not all forms will be returned, One advantage to be gained
when a questionnaire is planned to precede an interview is that the respondent is given
time to assemble the required information Thus saving his time and that of the system
analyst at the actual tweeting. The important considerations to bear in mind when
designing a questionnaire are
- It purpose (what specific information it is intended to gather)
- Its recipients (their level of understanding, intelligence and interest)
- Its timing
The questionnaire should normally b in three sections
- Heading section which will provide brief information about the questionnaire and will
allow the respondent to fill in data, name and title
- Classification section which will include data to be used for analyzing replies e g sex,
age, location etc
- Subject section which will contain the specific questions forming the main body of the
questionnaire

25
Record Review: Some of the facts remain untracked because the analyst cannot
anticipate all the factors and the user may also forget to bring out some points without an
analyst’s participation record review, e g studying a cash register gives an insight into the
actual working system of the organization.

Document searching: The main purpose of a record search to establish quantitative

information - volumes, frequencies, trends and ratios It will also help to establish how
must reliance can be put on the estimates given by the staff of the management of the
department It may also indicate whether departmental objectives are being achieved and
whether information needed for decision making is available when required It may also
disclose exceptions and additions to the information obtained by other methods e.g.
documents not mentioned, or received and filed without any actionist Among existing
documents one may find written procedures or job descriptions which can be vet useful
during investigations

Special purpose records Sometime the existing records do not supply the information
required and the only way of obtaining reel able information’ may be install special
purpose for a limited period The missing information is likely to 1e quantitative,
concerned with volumes, frequencies, trends or ratios or it may relate to management
information requirements The kind of information that one might wish to gather in this
way would include
- The time at which the documents arrive at the department
- The number of times flies have to be consulted
- The volume frequency of the telephone conversions
- The type of inquiry from the management
- The number of queries to the management
Maintenance of special purpose records v be in addition to the normal work, thus
increasing the workload, however slightly Special purpose records hence must be
installed only for a specific duration of time The records collected during this time will
provide with a representative sample of what is required to be known

26
Random sampling techniques Whether there is a high volume of documents or a
number of recurring activities it may not be necessary to practical to measure the total
number The economical way may be to take a sample: Random sampling techniques
consists of selecting a portion (sample) of the total (population) and based on the
assumption that the sample is representative of the population drawing inferences about
the whole

DOCUMENTING THE FACTS:

A document is a written description of the processes, data and system needs Documents
are
• To keep the notations standard across all the software projects; so that any one can
understand the system at any point of time.
To communicate across the teams related to the same project.
• To get verification and acknowledgement from the user about functionality and
requirements.
• To act as a written evidence of the limits of the contract.

27
THE CLASSICAL SOFTWARE DEVELOPMENT LIFE CYCLE APPROACH

It is the oldest and most widely used paradigm of software engineering. Sometimes called
the Waterfall Model, the life cycle model demands a systematic, sequential approach to
software development that begins at the systems level and progresses through analysis,
design, coding, testing and maintenance. The life cycle comprises of the following stages
(See figure):

Preliminary
Investigation
Requirement
Analysis
Systems
Design
Coding

Testing

Maintenance

Preliminary Investigation: The work begins by establishing requirements for all system
elements and taking an integrated view of the whole system and its subsystems. The
integrated (systems) view is essential to understanding the interface of the organization,
technology, people and databases. A feasibility study is carried out and presented in the
form of a feasibility report.

Requirements Analysis: Once the scope of the study has been identified in an overall
perspective, a detailed investigation is undertaken to understand the operations of the
current system and identify the domain of the information requirements. A requirement
specification document is prepared for a record of the customer expectations.

28
System Design: It is a multifaceted process which gives an on-paper design, focusing on
the data- structure, software architecture, procedures and interface. Design is document
for use by the development team.
Coding: This stage translates the designs into a machine compatible from using suitable
programming tools. If the design has been achieved with quality and engineering, coding
can be achieved mechanically.

Testing: Once the code has been written, it needs testing against a set of real-data to
ensure that the input produces results as per expectations. Testing is done at isolated level
for individual programs or at an integrated level for the whole set of programs to lidate
their mutual interaction.

Maintenance: Any software- needs modifications or updations due to errors

encountered, change of requirements or other factors. Software maintenance reapplies
each stage of the life cycle’ the existing system., rather than building the software afresh.
The life cycle paradigm has a definite place in software engineering. If offers a
procedural model for software development. However, its applicability is sometimes
questioned because of the problems encountered when using it. Some of the problems are
as under:
Real projects do not follow a sequential flow. Iteration always occurs and creates
problems in the application of the paradigms, e.g., it may be required to modify the
design documents as a result of some problems faced in the use of data entry screens.
It is often difficult for -the customer to state all requirements explicitly with only abstract
designs in front of them.
The customer must have patience to wait for the end product till the whole life cycle is
complete. These problems and criticisms lead us to some enhancements to this approach,
as discussed further.

29
 THE PROTOTYPE MODEL

Sometimes, a ‘user has clarity about the objectives of the software but has not decided
upon how it should actually function, or the developer is not sure about the efficiency of
the tools or algorithms used for problem solving. In all such cases of uncertainty, the
prototyping approach offers a better solution.
- Prototyping is a process that enables the developer to create a model of the software that
must be built. The model can be of any one of the following forms:
A PC based model to give the user an idea of the man-machine interface. -
A working model implementing a subset of the required functionality.
An existing program that has some features as per requirements but cannot exactly fit into
the requirement.
This model also follows a sequence of events as in SDLC (See Figure below)

Start Requirements Quick Building

Gathering and Design Prototype
Refinement

Stop
Engineer Refining Customer
Product Prototype Evaluation

Like all other approaches, prototyping also begins with requirements gathering. The
developer and the customer meet and define the overall objectives of the software,
identify whatever requirements are known .and where further definition is necessary. A
quick design is then prepared. The quick design generally focuses on the modi4es which
will be visible to the user, i.e., in the prototype the. main emphasis is given to the user
interface for input and output. This quick design is called the prototype. This prototype is
evaluated by the user and is used to refine further the requirements for the software to be

30
developed. The process of quick design and evaluation is iterated again till the user gets a
sufficiently working system.
Ideally, the prototyping model acts as a means to developing information requirements. It
c is a more secure way of establishing requirements and getting acknowledgment from
the user at small intervals than to keep holding till the complete life cycle is completed as
per the classical model. However, there are some limitations also attached to this
approach.
In most cases, the earl working models are thrown away as the new system is established.
Thus, the prototyping model results in an expensive solution.
The developer generally does not use efficient code or algorithms while preparing quick
designs, keeping the performance factors to be taken care of later in the project. As
prototypes are developed, he may forget to rewrite the inefficient algorithms in some
parts of the system.
The user may get impatient and request the developer to put some final patches in some
working version of the software, thus, forcing the developer to give half backed,
inefficient code.
Although problems can occur, prototyping is an effective paradigm for systems
development. The major style is to develop the rules of the game. The user and the
developer, both should agree that the prototype will be discarded later and the final
system should be built keeping quality and maintainability in view.

31
 THE SPIRAL MODEL

• This model encompasses the best features of both the classical life cycle as well as the
prototyping model with an added on feature of risk analysis. The model represented by a
spiral See the following figure) defines four major quadrants representing four activities
of the model:

Planning: It determines the objectives, alternatives and constraints of the system.

Risk Analysis: This activity analyses the alternatives and identifies / resolves the risks
associated with the system.
Engineering: This activity includes the actual development of the next level product.
This stage may apply either the classical or prototyping approach to development,
depending on the level of uncertainty estimated in the risk analysis stage.
Customer Evaluation: It involves the assessment of the results of engineering by the
customer or user.
It is an evolutionary model where we progress towards a more complete system with each
iteration At each loop around the spiral, the risk analysis results in a go—no go decision

32
If risks are too high , the project is terminated It enables the user to react to risks at each
evolutionary step. It uses prototyping as a risk reduction mechanism. However, it allows
the use of prototyping at any stage of development. The spiral model demands a high risk
analysis expertise, which may not be available in every team. Moreover, the movement
around the spirals may become uncontrollable, for which proper controls must be
established.
The spiral has many cycles .The radial dimension represents the cumulative cost incurred
in accomplishing the steps done so far, and the angular dimension represents the progress
made in completing each cycle of the spiral The model is shown in Figure 1.7.
Each cycle in the spiral begins with the identification of objectives for that cycle, the
different alternatives that are possible for achieving the objectives, and the imposed
constraints. The next step in the cycle is to evaluate these different alternatives based on
•the objectives and constraints. This will also involve identifying uncertainties and risks
involved. The next step is to develop strategies that resolve the uncertainties and risks.
This step may involve activities such as benchmarking, simulation, and prototyping Next,
the software is developed, keeping in mind the risks Finally the next stage is planned
The next step is determined by the remaining risks. For exarnple, if performance or user
—interface risks are considered more important than the program development risks, the
next step may be an evolutionary development that involves developing a more detailed
prototype for resolving the risks. On the other hand, if the program development risks
dominate and the previous prototypes have resolved all the user—interface and
performance risks, the next step will follow the basic waterfall approach.
The risk driven nature of the spiral model allows it to accommodate any mixture of
specification—oriented, prototype-oriented ,simulation-oriented ,or some other approach
An important feature of the model is that each cycle of the spiral is completed by a
review which covers all the products developed during that cycle,
• including plans for the next cycle. The spiral model works ‘for development as well as
enhancement projects
In a typical application of the spiral model, one might start with an extra round zero, in
which the feasibility of the basic project objectives is studied. These project objectives
may or may not lead to a development/enhancement project. Such “high—level”

33
objectives include increasing the efficiency of code generation of a compiler, producing a
new full screen text editor, and developing an environment for improving productivity
The alternatives considered in this round are also typically very high-level, such as,
should the organization go for in-house development, or should they contract
development, or should they buy an existing product In round one, a concept of operation
might be developed. The objectives are stated more precisely and quantitatively and the
cost and other constraints are defined precisely The risks here are typically whether or not
the goals can be met within the constraints The plan for the next phase will be developed
which will involve
FOURTH GENERATION TECHNIQUES (4 GT)

This technique encompasses an array of software development tools that enable the
developer to specify some characteristics of the software at a high level. The tool then
automatically generates the code for the specifications. The emphasis in this paradigm is
to use a specification technique that is closer to ‘natural language. The four step 4 GT is
shown in the following figure. Like all other paradigm, it begins with requirements
gathering. If the project is of small size, the specifications are directly implemented using
a 4GL. If the project is large, the design specifications may. be prepared before switching
on to the implementations.
This approach provides a very quick, way to develop s But its success is limited by the
capacity of the available 4GLs, The current $G tools are not sophisticated enough to
incorporate complex logic and truly natural languages. This approach has proved more
useful for small and medium sized projects. For large projects, the 4GT tools available do
not provide a very reliable solution.

Requirements
Gathering
Design
Strategy
Implementation
using 4GL
Testing

34
This paradigms discussed so far are used as supplementary rather than complementary
approaches to software development. In some cases, however, these paradigms need to be
and can be, combined to get the strengths of each one into a single project. Any one of
the paradigms can serve as the base into which others are integrated. The following figure
exhibits how these can be combined.
In every case, the work begins with preliminary requirements gathering. From this point,
any path can be followed as in the figure. If the uncertainty is low and the requirements
can be specified at the beginning, the classical model can be applied. Otherwise,
prototypes can be evolved. For testing, again the life cycle approach can be followed.
4GT can also be used to get the prototype models or to work in conjunction with the
spiral model. The guiding note is that no single approach to Systems development can
ensure the success of the project. The nature of the application, can define the required
mix of all the approaches.

35
 STRUCTURED ANALYSIS AND DESIGN METHODS AND SOFTWARE
ENGINEERING TECHNIQUES, TOOLS AND METHODOLOGIES IN SYSTEM
DEVELOPMENT

APPLICATION SYSTEM MODELING

ENTITY RELATIONSHIP DIAGRAM

Entity relationship diagram depict data at rest, data being stored They also do not imply
how data is implemented, created, modified, used or deleted Data relationship is called a
relationship - is a association between entities All relationship are further described by
words or symbols that indicate the number of occurrences of one entity that can exist for
a single occurrence of the related entity and vice versa
There are three general possibilities

* ONE-TO-ONE (1:1) - for one occurrence of the first entity there can exist only one
related occurrence of the second entity and vice-versa
* ONE-TO-MANY (1: M) - for one occurrence of one entity there can exist many
related occurrence of a second entity it doesn’t matter which is first or second
* MANY-TO-MANY (M: M) - for one occurrence of the first entity there can exist
many related occurrence of the second entity and for one occurrence of the second entity
there can exist many occurrence of the first entity.

Symbols used

Entity Relationship Attribute

36
HOW TO PERFORM DATA MODELLING WITH ENTITY RELATIONSHIP
DIAGRAM
- Identify entities
- Identify or define keys for each entity
- Draw a rough draft of the entity relationship data model
- Identify data elements
Map data elements to entities
- Normalize Data
- Redraw ERD
e.g. In order processing system the entities are customer, order and item. The ERD is as
follows

Customer Order
places

for

Item

STRONG AND WEAK ENTITIES:

Objects are represented by their attributes and, as objects are inter-distinguishable, a

subset of these attributes forms a primary key or key for uniquely identify an instance of
an entity. Entity types that have primary keys are called strong entities.
Entities may not be distinguished by their attributes by their relationship to another entity.
In this case the instances of the entity from the set are distinguishable only by their
relationship with an instance of an entity from the entity set. Such entity is called as weak
entity.

37
 Product Customer

M 1

Compromis
Place
e
1 M

Order

Is Is
M M
Consigned Posted
to to

1 1
Shipper Receivable

ILLUSTRATION OF ENTITY RELATIONSHIP DIAGRAM

38
DATA FLOW DIAGRAM (DFD):

Organizations are made up of divisions, departments and people, who coordinate to

perform work. But these boundaries are not rigid, they are seamless boundaries where
people and functions might flow from one place to another. In such a situation, it makes
more sense to study the logical essence of each activity rather than the physical media
involved in between, e.g., it makes more sense to understand that an invoice gets
generated before the dispatch of material to a destination; but it may not be emphasized,
whether the dispatch section, marketing, or finance department generates the invoice. It is
important to know that the outstanding statement should reach the Vice President of
Finance daily, it is not important to know who prepares and delivers this report. Thus, the
analyst needs to concentrate more on the logical aspects of the system, which relatively
static as compared to the physical aspects.
A Data Flow Diagram (DFD) is a tool that models the physical as well as the logical flow
of data across an organization. The undermine nature of this model is depicted in the
following figure:

Current Physical Planned Physical

Model Model

Logical Model

Figure: The Representation of DFD

Thus, two fundamental forms of the model are suggested. The first gives a logical view
of the company’s information needs in independent of the physical operation. The second
is an actual implementation of those requirements against the new hardware, software
and the people.

39
DFDs show the passage of data through a system irrespective of the current departmental
and administrative structure.

NOTATION AND CONSTRUCTION:

It depicts the passage of data in a system by using basic symbols as given below:

Symbol Meaning Symbol Meaning

Process of Function Data Flow

External Entity as File Storage

Source / Destination

40
LEVELING THE DFD

A good modeling technique should have an easy to use hierarchy. The DFD also needs
such a hierarchy The data flow diagram has a simple and consistent way of representing
different levels Each process is exploded into a lower level DFD until the specifications
of the process can be presented on an A sized sheet. Thus, it is possible to present a series
of DFDs representing increasing levels of detail. These may be used with different levels
of user staff. The high level overview charts are the focus of discussions with appropriate
line managers. The convention of calling the highest level diagram level 0 has been
adopted with the subsequent levels being designated as lever, etc. Normally, DFDs are
exploded upto level or. The numbering system of each level of the model is done in such
a manner that it is easy to refer back to its parent process in the upper level of the model.
Thus, the processes 2.1, 2.2, 2.3 etc. refer to the explosions of the process 2 at the higher
level. Processes 2.1.1, 2.1.2 etc. refer to the details of the process 2.1 in the upper level of
the model.
It is important to check that all the flows and stores accessed by the process in the higher
level box are actually used in the lower level decomposition. DFDs should be balanced so
that data flows in and out of a process must appear in the explosions of that process also.
If any discrepancies exist, reasons for that must be closely studies.

HOW TO DRAW A DFD:

Identify the sources and sinks of data. Sources are the external entities which originate
the data. Sinks are the external entities which receive the final output. This identification
will provide a boundary to the work and also give a set of flows.
Identify the processes as the activities of the system under study.
Join the processes and sources / sinks via data flows. If you need to store the data
permanently, or for later use, make a data store.
Most of the processes would be joined through data stores.

41
• generate the first rough draft, modify its data flows to design a concise and neat diagram
without any crossing of arrows. If the crossing cannot be avoided, represent one of the
flows with a curb. See the following figures (a) and (b).

Process 1 Process 2

Process 1 Process 2

Process 3
Process 3

Figure (a) Data flows crossing each other Figure (b) Data flows crossing resolved

RULES FOR DRAWING A DFD:

A set of guidelines and rules should be followed to ensure the consistency and accuracy
of the model. These rules are listed below:

• Sources cannot leak data directly to a data store.

• A data store cannot pass the data directly to a destination. A data flow out of a data
store in read-only.
• Data cannot flow directly from one data store to another.
• Any process producing output by itself should be a source.
• Any process with only input should be a data destination. Each subsystem must be a
process on the next higher level diagram.
DFD is a useful and quick modeling tool, which is unambiguous and easy to use.
However, it fails to represent data manipulation and passage to sufficient detail for the

42
subsequent design stages. Thus, it is generally supplemented by a supporting tool such as
a decision table, decision tree, or structured English.

ADVANTAGES OF DFD

* These simple notations are easily understood by user

* Data flow analysis permit analyst to isolate areas of interest and study them by
examining the data that enter the process and seeing how it changed while leaving
process. While drawing DFD first a context diagram is drawn (which is Level 0) diagram
then the main process is split in detail processes and as Level 1 diagram. Then further
splitting is done to draw Level 2 diagram. Normally Level 2 diagram gives the detail flow
of the individual sub-processes mentioned in Level 1.

CONTEXT DIAGRAM

Top level Data flow diagram is often called a context diagram. It contains a single
process. Context diagram define the system that will be studied in the sense it determine
the boundaries.

43
A sample DFD for a student admission system is shown in the figure below

44
`

45
DESCRIBING DATA STRUCTURES

46
Data structures are built on four relationships of components that may be either data
items or other data structures.
* Sequence relationship: includes a definite set of components
E.g. NAME = FIRST + MIDDLE + LAST

* Selection Relationship: represents alternatives and indicates either/or.

* Iteration Relationship: means that data elements composing the structure are repeated.
E.g. ITEM OCCURS 10 TIMES.

* Optional Relationship: some data elements may be optional. Rather than showing them
as a special case of iteration, that is, zero or one iterations of a component, it is more
effective to indicate that these elements may or may not be included.
Data structures are described by connecting individual data items with (+), [ ] for
iteration, { / } for either/or relationship, and () for optional.
e.g. ORDER DATA = ORDER NO + ORDER DATE + CUSTOMER NO + [ DESC,
QTY, RATE] + (CST / MST}+ (EXCISE)

OBJECT ORIENTED MODELING

Object oriented modeling is designing software as. a collection of discrete objects that
incorporate both data structure and behaviour. The characteristics are
IDENTIFY: Data is quantized into distinguishable entities called object.

CLASSIFICATION: Objects with the same data structure (attributes) and behaviour
(operations) are grouped into a class.

POLYMORPHISM: Same operation may behave differently on different classes.

INHERITANCE: Sharing of attributes and operations among classes based on
hierarchical relationship.

47
In OBJECT-ORIENTED MODELING TECHNIQUES (OMT) the stages are

ANALYSIS: which include definition of statement of problem.

SYSTEM DESIGN: in which system overall architecture is build.

OBJECT DESIGN: the model is designed using CLASS DIAGRAM, STATE

TRANSITION DIAGRAM and FUNCTIONAL DIAGRAM.

IMPLEMENTATION: Object, class and relationship is translated into programming.

OBJECT-ORIENTED MODELLING TECHNIQUE (OMT) uses three models:

OBJECT MODEL: which describes the static structure of the object in a system. A
object diagram is a graph whose nodes are object class and arcs are relationship among
classes.

STATE: A state is an abstraction of the attribute values and links of an object. A state
specifies the response of the object to input event. A state corresponds to the interval
between two, events. A state corresponds to the interval between two events received by
an object.
- The state has duration.
- The state often associated with the value of an object satisfy some conditions.
- The state has a suggestive name and natural-language description of its purpose.

THE STATE TRANSITION DIAGRAM is relates events and states. The change of
state caused by an event is called transition. It is a graph whose nodes are states and arcs
are transitions. State diagrams can represent one-shot life cycle or’ continuous loops.
Conditions can be used as guards on transitions. A guarded transition fires when an event
occurs, but only if the guard condition is true. An action is an instantaneous operation.

48
TEMPORAL MODELING: STATE TRANSITION DIAGRAM

STATE: A state is an abstraction of the attribute values and links of an object. A state
specifies the response of the object to input event. A state corresponds to the interval
between two events. A state corresponds to the interval between two events received by
an object.
- The state has duration.
- The state is often associated with the value of an object satisfying some conditions.
- The state has a suggestive name and natural description of its purpose.

THE STATE TRANSITION DIAGRAM relates events and states. The changes of state
caused by an event are called transition. It is a graph whose nodes are states and arcs are
transitions. State diagrams can represent one-shot life cycle or continuous loops.
Conditions can be used as guards on transitions. A guarded transition fires when an event
occurs, but only if the guard condition is true. An action is an instantaneous operation.

STATE 1

Condition

Action

STATE 2

REDUCING E-R DIAGRAMS TO TABLES

A database which conforms to an E-R diagram can be represented by a collection of table
For each entity set and for each relationship set in the database, there is a unique table

49
 which is assigned the name of the corresponding entity set, or relationship set Each table
has a number of corresponding entity set, or relationship set Each table has a number of
columns which, again, have unique names We shall present these concepts by
considering a tabular representation of the E-R diagram of the following figure:

Social security
number Account balanc
number e
Customer
city

Name street

date

CUSTOMER CustAc ACCOUNT

ct

Account
Balance
Number
259 1000
630 2000

50
 401 1500
700 1500
199 500
467 900
115 1200
183 1300
118 2000
225 2500
210 2200

THE ACCOUNT TABLE

Customer Social Security

Street Customer City
Name Number
Oliver 654-32-1098 Main Harrison
Harris 890-12-3456 North Rye
Marsh 456-78-9012 Main Harrison
Pepper 369-12-1518 North Rye
Ratliff 246-80-1214 Park Pittlfld
Brill 121-21-2121 Puntam Stanford
Evers 135-79-1357 Nassau Princeton

THE CUSTOMER TABLE

NORMALIZATION:

The normalization was defined by E.F.Codd as a mathematical basis for deriving tables
( rows and columns of data ) using relational calculus and a set of transformations that
could be applied to data structures to ensure that they met the requirements for a
relational DBMS.
The five normalization rules are
1NF: Each row or column must have a single value with no repeating values.
2NF: Every nonkey column must depend on the primary, key.
3NF: No nonkey column can depend on another nonkey column.

51
4NF: An entity cannot have a 1:N relationship between primary key columns and nonkey
columns.
5NF : Break all tables into the smallest possible pieces to eliminate all redundancy within
a table.
We will restrict out discussion upto 3NF. -
Codd identified three primary levels or forms of normalization that could be applied to
data structures to help eliminate possible anomalies when they are implemented as• a
physical database.

FIRST NORMAL FORM: A table is said to be in first normal form if it has no

repeating groups of attributes. In other words, if there is a group of attributes that is
repeated, remove it to a separate table.

SECOND NORMAL FORM: A fable is said to be in second normal form if it is in first

normal form and every non-key attributes is fully dependent on the primary key. Each
non-key attribute within a table with a multiple-attribute key is examined to transform a
set of tables into second normal form.

THIRD NORMAL FORM: A table is said to be in third normal form if it is in second

normal form and every non-key attribute is dependent on the entire primary key.
Following is the example of normalization:
UnNormalized Student Table

STUDENT TABLE
Roll Number
Name
year
College code
college Name
course number 1
course name 1

52
marks l
course number2
course name2
marks2
course number n
course name n
marks n
The course number is repeating group of attributes thus it is separated out to have first
Normal Form.

Tables in First Normal Form

STUDENT TABLE ADMISSION TABLE

Roll Number# Roll Number
Name Course Number
year Course Name
College code Marks
College name
Course name which is dependent on course number is combined to form a separate table
course is created to convert data of first normal form into second normal form.

Tables in Second Normal Form

STUDENT TABLE ADMISSION TABLE COURSE TABLE

Roll Number# Roll Number# Course Number
Name - Course Number# Course Name
Year Marks
College code
College name

53
The attribute College Name is dependent only upon college code, so it is removed to a
separate College table to reach third normal form,

Tables in Third Normal Form

STUDENT TABLE ADMISSION TABLE

Roll Number# Roll Number#
Name Course Number#
Year Marks

COLLEGE TABLE COURSE TABLE

College code# Course Number#
College name Course

DENORMALIZATION

When migrating ‘a normalized data model to a physical database structure, the DBA
takes into account various design tradeoffs to support the functionality of the application
in the most efficient manner possible. Implementation consideration leads 10 design
tradeoffs that can help or hinder the performance of the application when it is finished.
Once a set of database structures or tables has been normalized in analysis, a process of
denormalization usually occurs in design.. Denormalization is the process of structuring
the set of tables so that its performance is most efficient in the production environment, a
normalized set of tables is in the most efficient configuration logically, while a
denormalized set of tables is in the most efficient form .physically. There’ are several
performance considerations that affect database design. These include table access or
update frequency, table size, index requirements, and security requirements.

SYSTEM DOCUMENTATION TECHNIQUES

PROCESS CHART

54
A system consists of many different activities of process. It contains independent but
interactive Modules. Process hierarchy chart shows hierarchy or levels of process in the
system. Any activity that generates modifies or uses information should be included in
process chart.

Bicycle
Assembly

Open Remove Group Assemble Finish

Container Parts Parts Wheels Assembly

Bolt Bolt
Front Wheel Rear Wheel

FUNCTIONAL DECOMPOSITION DIAGRAM:

Fundamental to structured methodology is dividing system into tasks. This process is

often called Functional decomposition or leveling because the system is divided into
tasks that each perform a particular function. A top-down concept is used for
decomposition. We use functional decomposition to divide system ,into its parts or
modules. A module is a unit with a single specific function of a large system. Some
modules relate to one another as “children” of “parents”. So according to level or
hierarchy of the module in the system a numbering is done.

55
Following figure shows functional decomposition of the system

3.0
Print Check

3.1 3.2
Print Print
Remittance Check Stub
Advice

3.1.1 3.1.2 3.2.1 3.2.2 3.2.3

Print Print Print Print Print
Detail Line Detail Line Detail Line Detail Line Detail Line

SYSTEM FLOW CHART:

It is a diagrammatic representation of information expressed in time sequence. This chart
gives the total of information and stepwise indication of process and input in
transformation of data into information. This chart is useful in - understanding present
system
- designing or evaluating a new system
- to illustrate proposed system for information of other persons.
Symbols used:

56
 Process
Card

Termination
Predefined
Document links

Input
/
Connector
Paper Tape Outp
ut

Decisio
n Off page
Hard Disk Connector

Sort
Online
Storage Magnetic
Tape
Manual
Operation
s

Manual Input

HIERARCHICAL INPUT PROCESS OUTPUT (HIPO) CHART

This methods used for developing software (developed by IBM). HIPO diagrams are
graphical rather than prose or narrative description of system. They assist the analyst in
answering three guiding questions.
1. WHAT does the system module do? (Asked when designing the system)
2: HOW does it do? (Asked when reviewing the code for testing)

57
3. WHAT are the inputs & outputs? (Asked when reviewing the code for testing or
maintenance) A Hipo description for a system consisted of the Visual Table of content
and the Functional

VISUAL TABLE OF CONTENT (VTOC)

This shows the relation between each of module making up a package. It consists of
hierarchy chart that identifies the modules in a system by number and in relation to each
other and gives brief description of each module.

1.0
Order
Processing
System

3.0
2.0 4.0
Monthly
Transaction Report
Invoice
Entry preparation
process

2.1 3.1 3.2

2.0
Data Invoice Invoice
Data Edit
entry Preparation Register

3.1.3 3.14
3.1.1 3.1.2
Credit Debit
Purchase Payment
Adjustment Adjustment
Transaction Transaction

58
PROGRAM STRUCTURE CHARTS
Well structured designs improve the maintainability of a system. A structured system is
one that is developed from the top down and modular, that is, broken down into
manageable components, The modules should be designed so that they have minimal
effect on other modules in the system. The connections between modules are limited and
the interaction of data is minimal. Such design objectives are intended to improve system
quality while easing maintenance tasks.
Structure charts show the relation of processing modules in computer software.

PURPOSE OF STRUCTURE CHARTS

A structure chart is a design tool that visually displays the relationship interacts and also
graphic depicts the data that are communicated between various modules.
Structure charts are developed prior to the writing of program code. They are not
intended to express procedural logic, a task left to flowcharts and pseudo-code Nor do
they describe the actual physical interface between processing functions. They identify
the data passes existing between individual modules that interact with another.

Name of module Rectangle denotes module

Calling Module

Arrow indicates that one

Module calls another.
Direction indicates
Called Module which module is calling.

STRUCTURED FLOWCHARTS (Nassi - Shneiderman Diagram):

Structured flowcharts -use no arrows or, continuations on separate page. Each structured
flowchart is shown on a single sheet of paper. When designing a structured, flowchart,

59
the logic is specified in a top-down fashion. The first consideration in a process or
decision is the top element. The second in sequence is the next one shown, and so forth.

Similarly, there is a single exit from the process. Each process is named. The structure
chart reads from top to bottom and left to right. Each activity is nested within the iteration
and alternative process of which it is part. In addition, each condition is clearly shown.

Get master record

Get transaction record
DO WHILE there are more transactions OR
There are more records

true Master = transaction ? false

update master master < trans ?

write master true false

get new master write master print error

get new transaction get master get trans.

Close master file

Close transaction file

LOGIC REPRESENTATION TEC11NIQUES

DECISION MAK1NG
CONDITION ACTIONS
Possible states of an entity Alternatives, steps, activities or procedures
Person, place, thing, event that can be taken when a specific decision is made.

60
DECISION TABLE:
It is usçd for more complex circumstances where several criteria (conditions)
determine an action. Let us consider a discount policy for customers with the following
details:
If a customer places an worth Rs. 20,000 or more, the company offers him a discount of
15% on the purchase amount. However, if the customer is old to the company, the lower
limit of purchase amount is reduced to Rs. 10,000. In all other cases, a 10% discount is
offered for any purchase of Rs. 10,000 or more.
This statement involves complex decision-making, which can become even more
complex as more clauses are added for discount provisions. DFD is not a suitable tool for
such a level of detail. A decision table or decision tree is particularly used for such
decision rules.
A decision table is a matrix of rows and columns. The table is divided into 4 parts as
shown in the following figure. The left hand parts denote possible conditions and actions.
The right hand parts define the rules. Condition is a possible state of an entity. As
conditions vary, they are also called decision variables. An alternative step or procedure
that an individual takes or follows when confronted with a condition is called an action.
A rule defines an action to be, taken corresponding to a defined combination of
conditions.
Decision table for the above stated discount policy statement is given in the following
figure:

Condition Condition Entries

Statements

Action
Action Entries
Statements

Layout of a Decision Table

STEPS FOR DRAWING A DECISION TABLE:

61
 • Identify all the conditions and the actions.
• Identify the possible entries for each condition statement.
• Workout the total number of decision rules by multiplying the number of
possibilities.
• Create the conditions and actions stub.
• Fill up all the condition entries to ensure that all possible combinations of
conditions have been filled up.
• Identify the actions corresponding to each combination of the conditions.
• Check the rule table to remove contradictory rules, if any.
• Remove redundant rules, if any.
Applying these rules, the decision table for the discount policy can be created as in
figure below. The rules have been given serial numbers 1 to 8. Rules 1 and 5 have been
marked with C to indicate contradictions as the purchase amounts cannot be in the two
ranges simultaneously. To further refine this table, rule 4 and 8 can be combined, as the
action is determined irrespective of the entry values of old customer condition. In this
case, we call the rule as indifferent to the condition and show it with the symbol of
indifference (-). The modified table is shown in the following figure.

1 2 3 4 5 6 7 8

Old Customer Y Y Y Y N N N N
Purchases > = 2000 Y Y N N Y Y N N
Purchases between
10000 - 20000 Y N Y N Y N Y N

15% Discount X X X

10% Discount X

No Discount X X

62
 The table represented above contains only limited values of condition values, i.e.
Y and N indicating Yes and No situations. X in the action entry stub indicates the
corresponding action to be taken. Such a table is called Limited Entry Form. Another
form of the table, widely used, is the Extended Entity Form, which allows the descriptive
values in the condition or action entry stubs, e.g. the above figure could have a decision
variable as ‘ Purchase amount’ and the entry values as “ > = 20000, ‘ between 10000 and
20000’ and Less that 10000’. Similarly, action entries could have complete descriptions
rather than the symbol ‘ X’.
1 2 3 4 5

Old Customer Y Y - N N
Purchases > = 2000 Y N N Y N
Purchases between
10000 - 20000 Y Y N N Y

15% Discount X X X

10% Discount X

No Discount X

Modified decision table for the discount policy

A decision table gives a compact format of decision rules. It is particularly helpful

the number of decision and action variables is quite large. It is particularly true in the
case of DSS and ES, involving complex decision-making. However, a simpler tool to
represent smaller set of decisions is also available in the form of Decision Trees.

EXTENDED ENTRY TABLE

63
The difference between this type of a table and a limited entry table is that the stub part of
the table are not complete in themselves It is necessary to consider together both the stub
and the entry parts to determine whether a condition or action is relevant to a specific rule

DECISION TREE

A decision tree is a diagram that presents conditions and actions sequentially and thus,
shows which conditions to consider first, which second and so on. It resembles the
branches of a tree and hence the name. A decision tree corresponding to the decision
policy mentioned in the previous section is given m the following figure:

action
condition
action

condition
action

condition
action
root

condition action

action
condition

action
condition
action

64
The nodes of the tree represents condition and indicates that a determination must be
made about which condition exists before the path to be chosen The right side indicates
actions to be taken
A decision tree gives a clear picture and a pathway to reach from a set of decision
variables represented as branches of a tree and traces down to the ultimate point of action,
also called the leaf or node of the tree. This representation becomes clumsy and unwieldy
as conditions increase in number.

Old
Purchases 15%
customer
Purchases < 20000
>=10000
New
10%
customer
Start
Purchases
> = 20000 15%
Purchases
< 10000 Nil

STRUCTURED ENGLISH

Structured English is another tool to deal with the ambiguity of language It states the
decision rather than showing them It is quite close to the natural English language with
some standard conventions to eliminate vague expressions and enhance the clarity of
documentation It is used to express the complete logic of the process, which includes the
representations given by the DFD and decision models However, the DFD and Decision
models give a comprehensive pictorial view of their own specified areas and thus,
structured English should not be confused as an alternative to these

65
A sample notation of structured English is shown in the following figure explaining the
generic order processing system

CONVENTIONS:

• All process log is expressed as a combination of sequence, decision arid

repetition.
• Keywords used in this tool are - IF, THEN, ELSE, SO, REPEAT, UNTIL ( all
capitals).
• Comparison operators used are LT, LE, GT, GE, EQ, NE to stand for Less than,
Less than/equal to, Greater than, Greater than/,equal to, Equal to, Not equal to
respectively.
• Blocks of instructions may be grouped together and given a meaningful name.
• Where a word or phrase is used, which has a special meaning in the system in
question, it should be underlined. This indicates the vocabulary of the system.
• It is not a computer program.
• No physical file specification is done.

PROCESS ORDER
DO ACCEPT-ORDER-DETAILS
DO CHECK-INVENTORY
DO COMPUTE-ORDER-TOTAL
DO .COMPUTE-DISCOUNT
DO PLAN-DISPATCH
ACCEPT-ORDER-DETAILS
REPEAT ORDER-LINE-ENTRY UNTIL ALL ITEMS DONE.
ORDER-LINE-ENTRY
REPEAT INPUT UNTIL ALL ITEMS DONE
CHECK -INVENTORY
REPEAT CHECK-ITEM-INVENTORY UNTIL ALL ITEMS DONE.
IF ALL ORDER-ITEM ARE VALID THEN

66
 INVENTORY STATUS IS OK
CHECK-ITEM-INVENTORY
IF QTY-IN-HAND IS LT ITEM-OTY THEN
DO REJECT ORDER
ELSE
ORDER-ITEM IS VALID
COMUTE-ORDER-TOTAL.
MULTIPLY WITH ITEM-PRICE TO GIVE ITEM-TOTAL
ADD ALL ITEM-TOTAL TO GIVE ORDER-TOTAL
COMPUTE-DISCOUJNT
IF ORDER-TOTAL IS -GE 20000 THEN
DISCOUNT IS 15%
ELSE
IF ORDER-TOTAL IS GE 10000 THEN
IF CUSTOMER IS OLD THEN
DISCOUNT 1S I5%
ELSE
DISCOUNT IS 10%
. ELSE
DISCOUNT IS NIL
PLAN-DISPATCH
IF INVENTORY-STATUS IS OK THEN
DISPATCH IS ALLOWED
ELSE
ORDER IS PENDING.

Structured English for-a generic order processing system

67
 USER INTERFACE DESIGN

OUTPUT DESIGN

The output of a computer system is primary contact between the system and most
users. The quality of this output and its usefulness determines whether the system will be
used or note.

OUTPUT CONSIDERATIONS:

1) FLEXIBILITY: Summaries detail reports, exceptional reports are required by users

hence the data must be preserved at the lowest level on detail desired for reporting.

2) GENERAL CONSIDERATIONS:
a) Clarify in format and heading for output
b) User clear descriptive titles for different fields on the report
c) Avoid the use of obscure or little known codes
d) Use foot-note where necessary
e) Output only as much as is required.
f) Saving of historical data.

TYPES OF OUTPUTS:

68
1) EXTERNAL outputs whose destination is outside the organization and which require
special attention because they project the image of the organization.
2) INTERNAL outputs whose destination is within the organization and which require
careful design because they are the users main interface with the computer.
3) OPERATIONAL outputs whose use is purely with the computer department.
4) INTERACTIVE outputs which involve the user in communicating directly with the
computer.
5) TURNAROUND outputs re-entract documents to which data will be added before
they are returned to the computer for further processing.

TYPES OF REPORTS:

1) QUERY REPORTS: allows user to get immediate answers to their questions, served
primarily on terminals.
2) DETAIL REPORT: gives all the pertinent facts about situation. Such reports create
handy information file for manual reference.
3) SUMMARY REPORT: tabulated overall results, thus facilitating historical review or
comparison of current to past activity.
4) EXCEPTION REPORT: allows a user to specify criteria for isolating a certain set of
data.
5) PERIOD REPORT: gives users data at regular time interval.

OUTPUT DEFINITIONS:
The outputs should be defined in terms of
- type of output
- content (heading, total etc.)
- format (hardcopy, screen etc.) -
- location (local, remote, transmitted etc.)
- frequency ( daily, weekly, monthly, half yearly etc)
- response (immediate within a period)

69
- volume ( no. of documents, growth)
- sequence
- action required (in case of errors etc.)

The contents of the output must now be defined in detail

1) data-items : AlphalNum, ranges, no. of character, position of decimal points,

arithmatical signs.
2) data-totals : levels, column totals, sub. What will cause them to occur how, will they
be recognized, units of representation accuracy.
3) data-editing: decimal point insertion, suppression of leading zeros, alignment
requirements.

OUTPUT MEDIA:
The choice of output media will be affected by the following considerations.
I ) The suitability of the device to the particular application.
2) The need for hard copy (number of copies required).
3) The response time required
4) The location of the user
5) The software / hardware available

OUTPUT SPECIFICATION:
Once the system analyst reaches to an understanding of the user requirements an outline
of the outputs can be prepared. These outlines will help the analyst in
-- To interpret and communicate the result of the computer part of a system to users in a
form which they can understand and which meet their requirements.

70
- To communicate the output design specifications to programmers in a way which is
unambiguous, comprehensive and capable of being translated into a programming
language.

OUTPUT DESIGN SPECIFICATIONS:

The output designs should be properly documented so that any developer can take it and
write code for it. The design layout for an output is shown in the following figure. Maj6r
points to be highlighted in design specifications are as follows:
Size of Paper: Specify the width of the paper to be used for printing e.g. A size, A3 size
etc. The size of the paper will vary with the contents to be printed.
Pre-printed Forms: For routine office reports, where standard print headings are
required, can be designed on a pre-printed from and then used for printing the output. For
example, all the print stationery of a company can have the company name and logo
printed at the top, to give a professional look to the output document. The railway tickets
that we receive after reservation are also printed on a pre-printed form containing all the
column headings and general rules for reservation and cancellation.

Multiple Copies: Many outputs are required simultaneously by more than one user. This
can be facilitated by using multi-part stationery. Printing stationery is available in carbon
parts and carbon less parts variety.

Design Layout: Develop the output layout as shown in the following figure The layout
should have the following:
• A heading and date
• Data and details
• Breakups and sub-totals
• Summaries
• Page title, number and date
• Conventions for-highlighting important events.
• Column headings and data type. For numeric, use N(n) and for alphas, use X(n), n
specifying the length of the column value.

71
• Sort criteria.
XYZ & CO.
SALES ANALYSIS REPORT FOR THE MONTH…………………..
Total pages: Print Date:

CITY DEALER MODEL SALE QTY. DISCOUNT AMOUNT

X(20) X(25) X(3) N(5) N(3) N(10)

Design Layout
INPUT DESIGN:

Though, outputs are the main determinant of any system performance, the quality
of output is determined by the input made to the system. Thus, it is important for the
designer to take care of the input design. A trash input will result in trash. Carefully
accepted data will give accurate and purposeful analysis.

OBJECTIVES OF INPUT DESIGN:

Some specific points must be considered while designing the input forms of a
system. These points are as below:
• Keeps controls on the volume of data being entered. Avoid unnecessary data
capturing. Don’t capture any constant or computable data.
• Avoid processing details during data entry so as to speed up the entry process.
Thus, try to keep the side computations limited and use fast algorithms and
procedures to do the same so that the user entering the data does not perceive any
gap.
• Avoid data entry errors. Check all the data entered for validity and consistency.
Any wrong input should be immediately rejected

INPUT DESIGN GENERAL CONSIDERATIONS:

1) Reduce the input to the minimum for cost and error purposes

72
2) Ensure that the input is acceptable to and understand by the user staff
3) Simplify input clerical procedures
4) Natural order of the data should be maintained.
5) Reduce the number of step between data generation and data capture.

BATCH INPUT: Suffers from rigidity since the information is required in a particular
format. There is also a lack of immediate feed back on errors. It is however very
economical and several advantages in backup and in processing error control.

ONLINE INPUT:
a) Data entry process is usually faster owing to dialogues with the computer
b) Frequently fewer data have to be entered sine the computer can supply some of the
data from its access to files
c) Incorrect keying can be detected on and often corrected immediately this online
checking contributes greatly to improve accuracy and reliability of data
d) Existing staff can be used to input the data.

INPUT STAGES:
- Data recording i.e. collection of data at its source
- Data transcription i.e. transfer of data to an input form
- Data conversion i.e. conversion of the input data to a computer acceptable media
- Data verification (checking the conversion)
- Data control (checking the accuracy and controlling and transporting the data to the
computer)
- Data validation (checking the input data by program when it enters the computer
system)
- Data correction ( correcting the errors that are found at any early stage).

INPUT TYPES:
1) EXTERNAL to the organization e.g. purchase invoice etc.
2) INTERNAL which are user communications with the system e.g. file amendments,

73
 adjustments.
3) OPERATIONAL computer departments communication with the system e.g. job
control parameters
4) COMPUTERISED which are inputs in computer media coming from other
internal system or external systems
5) INTERACTIVE inputs entered during a dialogue with the computer.

INPUT MEDIA:
I) Source document conversion devices and key to tape, key to disk and key to diskette
2) By product data capture devices billing machine, accounting machines, cash registers
3) Direct data capture devices optical mark reader, optical character reader, magnetic ink
character reader, these devices are directly linked, to a computer and receive the
source document directly without any, conversion or verification process.
4) On-line data entry devices, teletypewriters, terminals, audio response terminals, light
pens, optical wands which collect data directly from source document into the
computer one transaction at a time.

LAYOUT OF INPUT FORM:

The in form should be carefully designed, giving proper space for each of the data
to be entered. The input form design should contain the following:
• The heading and date of data entry
• The data columns: heading and value
• The data type and length of each data column.
• The initials of the data entry operator.

74
INPUT VALIDATION:
A proper scheme needs to be devised for the validation of input. There are many
ways to validate the data at various check points. The following text contains some of
those procedures:
Check the Transaction Data: The user may commit errors while typing data. Thus, each
data value must be checked for correctness as soon as they are entered. The following
major tests can be performed on each data value entered:

Existence Test: This test checks the data entered for null value entry, e.g. if customer
code is not entered in a new order data entry form, then this data value should be rejected
in the existence test as the complete order entry without a known customer is futile.

Limit or Range Test: Each data value should be checked for the range of valid inputs. For
example, a date value with the month 13” should be trapped as it is out of the permitted
limit of values for a month. The limits and range are defined for every data field at the
time of data base design.

Combination test: Sometimes, a data value is valid when tested in isolation but becomes
invalid when tested in combination with some other fields. For example, a date entry of
31 is a valid entry as it can have any value in the range between 1 to 31, but it becomes
invalid as soon as the month is entered as 2 i.e. February.

75
 INPUT CODIFICATION SCHEME

Since the main objectives of any input design are to speed up the process and
avoid errors, it is preferred to use codes rather than lengthy names for data entry, e.g.
entering a 5 digit customer code is far preferable to entering the complete name and
address of the customer while entering routine’ orders. These codes need to be easy to u
interpret and memorize.
A code is an ordered collection of symbols designed to provide unique identification of
an entity or attribute. The function of a code is to make it possible to identify, or retrieve
the coded item as efficiently as possible. The need for designing a major code tends to
arise when
1) a new system is superimposed in an organization
2) when an existing code is got grown and cannot be sensibly extended
3) When two organizations with different coding systems merge and a single code is
needed for both.

Codes are broadly classified into two major types

* NON SIGNIFICANT CODES
* SIGNIFICANT CODES

76
Non Significant Codes: is one in which the individual values are meaningless. There is
no defined relationship between the code value and the attribute being coded. It is
designed only to provide a unique identification.

Sequential Codes: This method of coding is merely the arbitrary assignment of

consecutive numbers to a list of items as they occur. The advantage of the sequence code
is that it can cover a large number of items by the fewest possible code digits as new
items occur they are assigned the next higher number.

Block Codes: Block codes are special type of’ sequential codes in which the sequences
are grouped within sections or blocks. Block codes are often used where the code
numbers are issued at several different locations and first digit indicates the location of
issue.

Random Codes: The random code is drawn from a number list which is not detectable in
order or sequence. The code is produced by using random, number tables.

Significant Codes: is one which apart from providing unique identification is designed to
furnish additional meaning which can yield logical collating or mnemonic significance.

Significant Digit-Subset Codes: This scheme divides the complete code into various
subsets, each one of them signifying some separate meaning, e.g. the phone number
0575-622 137 is a code where 0575 indicates the code of the city, .62 identifies the local
exchange within the city and 2137 is. the sequence code within that exchange.

Logical Code: in a logical code the individual values are derived ‘in conjunction with a
Consistent well defined logical rule or procedure e.g. MATRIX and SELF CHECKING
code.

Matrix Code: is useful in coding two component relationships. The code values can be
formed by assigning sequence numbers.

77
Self Checking Code: When an additional character is appended to a base code to check
its consistency the character is called as a check character. The check character is derived
by using some mathematical algorithm. ‘The check character feature provides the
capability of detecting most random or clerical errors. Generally the modulus method is
used to generate the check character.

METHOD OF CALCULATING THE CHECK DIGIT

E.g. module 97 method

Let the base code be 2385

1. Multiply the digit of the base code by their respective weights & find the sum. The
weights chosen are corresponding to their position starting from the right.
2*4+3*3+8*2+5*1=8+9+16+5=38.
2. Divide the sum by 97 and find the remainder
38 / 97 remainder 38
3. Subtract the remainder from 97 i.e. the check digit.
97-38= 59
If you wish to use module II then substitute 97 by II rest of the method remains same

Collating Code: are the most frequently used codes. The collating structure is designed
so that when sorted by the code numbers the items are placed in predetermined order e.g.
is alphabetic, hierarchical, classification, chronological codes.

Alphabetic Code: assigning alphabetical code the items are placed in the alphabetical
sequence then the items are assigned a code of ever increasing value. Normally spaces
are left between each item for future expansion.

78
Hierarchical Code: a collating code which ranks entities or attributes by relative levels.

Classification Code : is the establishment of categories of entities types and attributes in

a way that bring like or similar items together according to a predetermined relationship.
The design of a classification structure must, satisfy two basic requirements
comprehensiveness and mutual exclusiveness of its categories.
The classification schemes. are based on the view point of particular people called
upon to do a certain task at a specific point in time.
One of the most widely known classification codes is the Dewey Decimal System
used primarily for indexing libraries or classifying written correspondence by subject
matter.

Faceted Codes: This kind of code represents the different facets of the coded items.

Chronological Code: is assigned in order of events so that each code has a higher value
than the last code assigned.

Abbreviation Codes: This method uses the abbreviation of the name of. the entity or
attribute. There are two types of abbreviation.

Mnemonic Codes: mnemonic code construction is characterized by the use of either

letters or numbers or letter number combinations which describe the items coded.
Mnemonic codes produce fewer errors than other type of codes.

Acronyms: is a particular type of mnemonic representation formed from the first letter or
letters of several words: The acronyms often form a world in itself. e.g. RADAR -
RADIO Detecting and Ranging.

CHARACTERISTICS OF A GOOD CODE :

79
1) UNIQUENESS: The code structure must ensure that only one value of the code with a
single meaning may be applied to a given entity or attribute although the attribute or
entity may be described in various ways i.e. there should be one to one correspondence
between the codes and
entities. .

2) EXPANDABILITY: The code structure must allow for growth of its set of entities or
attributes.
3) CONCISENESS: The code should require the fewest possible number of positions to
include and define each item.

4) UNIFORM SIZE AND FORMAT: This is highly desirable in mechanized data

processing systems.

5) SIMPLICITY: The code must be simple to apply and easily understood by each user
particularly workers with little experience.

6) VERSATILITY: The code should be easy to modify, to reflect necessary changes in

conditions, characteristics and relationships of the encoded entities.

7) SORTABILITY: the codes should be easily sortable.

8) STABILITY: Coding structure should not be changed frequently as frequent changes

are costly, laborious, causes errors and can also degrade the system.

9) MEANINGFULNESS: The code values should reflect the characteristics of the

encoded entities.

10) OPERATABILITY: The code should be adequate for present and anticipated data
processing both for machine and human use.

80
PROCEDURE DESIGN:

Procedures, like forms, are designed during the development of an information

system. Some relate to the development activities themselves, such as, the procedures
that tell the programmers how to document the software they write. Others concern
operations, telling computer users how to interact with the computer for input and output
e.g. a procedure may give instructions for input preparation, the detection and correction
of errors, or hardware maintenance. The procedures:
• Are the ready reckoners for the designer and the user, recording how a job should
be done.
• Serve as a supervisor over operators. -
• Can be used as a training tool for the end users and operators.
• assist the management in assessing manpower needs.
The procedures are meant to increase the efficiency and effectiveness of the
system. The proper following of procedures can lead to cost reduction of the
company, e.g. following the procedure for maintenance can reduce maintenance
costs.

PROCEDURE DOCUMENTATION:

A well designed procedure is clear, unambiguous, complete and concise. This means
that the vocabulary to describe the procedures should be simple. Generally, structured
English is used to express the procedures. These documents may be kept in the form of a
printed manual or on the screen. The procedures manual should have:
• A table of contents for easy reference to specific pages of procedures,
illustrations etc.
• An explanation of the purpose of each procedure.
• Step by step directions for each task.
• A description of expected results of each procedure and who will benefit. Quality
standards for each procedure.

81
 • What action to take up if a procedure is not followed and recovery is required. A
procedure for feedback of users.

DATABASE DESIGN:

A data base is an orderly arrangement of all the records related to each other. It is
important to design a database with care, to ensure Optimum performance, storage and
fast retrieval of data. If the database design is not efficient, the input and output quality
can remain poor. The following needs to be done for data base design:
• Identify all the tables or record types.
• Identify the columns or fields for each table.
• Identify the relations between various tables.
• Identify the data type and length for each field of the tables.
• Identify the key fields for each table.
• Normalize the database to ensure simples, smaller, consistent data structures
without redundancy.
• Document the database dictionary.

DESIGN DOCUMENTATION:

The importance of documentation is not well understood by people involved in

systems design, till they suffer due to lack of it. There is a tendency to treat
documentation as an activity to be carried out if time permits. As a result, the quality of
documentation goes down.
At the starting point in design, the designers use the document on requirement
specifications generated after the stage of analysis. During design, the documents prepare
are:
Design Document:
It contains comprehensive details of all the phases of design. It may be in the form of
a report, or as separate reports and documents. It contains the following information:

82
 • brief introduction to the system.
• design factors
• design constraints
• list of programs list of data files
• list of input forms
• list of outputs
• manual procedures
• program specifications
• input / output specifications
• system test conditions
• cross reference between the design and the requirement specifications document,
indicating the solution for .the requirement specifies in the requirement
specification.

User Manual:
It is written so that the users of the system have a comprehensive text to refer to.
The manual should contain all the information the user needs to use a system, The
manual should be simple, easy to read without any technical jargon that the users cannot
understand. It should contain:
• an overview of the system in terms of a flow chart
• clear formats and instructions to fill in the input form
• the outputs of the system with report and screen layouts and also with the
procedures to retrieve them.
• anticipated exceptions that are to be handled by the users.
• the role of various users within the same or different departments.

Operations Manual:
It is written for the computer operators. It contains the descriptions and
instructions operators need to operate the system. It should contain:
• a scheme of execution of programs

83
 • an overview of the system from the operator’s point of view. This should specify
the start, stop and restart sequences.
• a scheme for system maintenance.
• various procedures to ensure the security, privacy and integrity of data.
Implementation planning include
1) Selection plan for qualified personnel
2) System test plan
3) Personnel Training plan
4) Equipment Installation plan

5) System conversion plan

6) Overall implementation plan

STAFF SELECTION: Trained personnel will be needed as soon as the implementation

activities begin, so training must begin before that stage.
The managers of the departments concerned, both users and operations, define the
type and quality of people required. It is usually advisable and in some cases essential for
the personnel manager and trade union officials to be consulted about re-employment and
especially about any redundancies. (This should be done through proper channel).

Training of the Personnel:

Proper training needs to be provided to all the users at various levels and with
various roles, related to the system in any form The training should cover:
• a working knowledge. of the hardware and software environment
• the operating knowledge of information system
• procedures to use input/output forms related to the specific roles of the users.
• procedures to handle exception and routing maintenance.

The training maybe organized internally or by an outside agent, generally parallel to the
process of system development.

84
TRAINING: User manager must be informed of the whole system work, its objectives,
new documentation files and procedures. User staff must be instructed to how to perform
their new tasks.
Training sessions must aim to teach user staff the specific skills required in their
new jobs. Thus they should contain large elements of practical activity (people learn far
more by doing that by watching or listening). Ideally they should consist of short and
regular sessions rather than a long, once off period, and they should be conducted with
small groups rather than a full number of staff, this facilitates learning from peers.
The training will be most successful if conducted by the supervisor with the
systems analyst in attendance to sort out any queries; view methods will gain acceptance
more quickly in this way. This also applies to user manuals; if the users write their own
manuals they will be more intelligible and
more acceptable. ..
Plenty of job aids should be provided to assist in the 1éarthng process these will
include visual presentation of procedures (e.g. flow form) , on machines, wall charts (e.g.
time scales) and use of different colours. Above all the training sessions should be
tailored to the learning process, allowing assimilation over a period before more new
information is fed in; and providing feedback on progress.

SYSTEM TESTING: Areas of Testing are

1) clerical preparation fo specimen forms of all type which will be used.
2) transmission of the data
3) data input control
4) data preparation and verification
5) validation of input
6) Error routines
7) File creating
8) file updating .
9) Output control
I 0) output handling & distribution
11) output usage by the recipient

85
CLERICAL PROCEDURE TESTING:
1) the procedures are fully understood or not
2) whenever error occur correct action is taken or not
3) timings are realistic
4) volume of work predicted can be handled or not
5) maximum possible peak load

CONVERSION PROCEDURES:
This is the actual phase of putting all the data from the old to the new system
format and starting the actual usage of the system. The conversion should be well
managed under the control of a conversion manager. The conversion manager should
prepare a plan for conversion keeping the following factors in view:

• Describe all the activities to be converted, e.g. the modules of order acceptance,
dispatch, sales analysis etc.
• identify persons responsible for each activity. They should be the people
responsible for providing necessary inputs to start up the new system and control
the related progress.
• Schedule activities: A Gantt Chart can be prepared to indicate the predecessor
and successor activities.
• anticipate problems in the hardware, software, data or organization and plan for
their solutions.
• prepare the site for installing the required equipment.
• prepare all the data and files to be entered before the system usage can take place.
e.g. establishing all the master data records.
• keep a count of all the records to be entered.
• handle all situations involving data transmission.

86
FILE CONVERSION
File conversion normally, develops into the following sequence of events.
1) Record of the old file data on specially designed input documents by clerical efforts
2) Transcribe, the completed documents to suitable media and verify.
3) use a tailor made program to read transcribe data and then output the required files in
the format needed by the user program.

PROBLEMS IN FILE CONVERSION: Most source document contains historical data

which is not relevant for new computer file and thus give rise to clerical activities and
clerk needs technical knowledge. So senior experienced staffs from user department are
required and can be available for short period only. In such case system analyst may take
help of outside bureau, or data preparation services to assist.
Another greatest problem in concerning live files such as a stock master file. It
must be converted at a specific data or series of dates and therefore an amendment
correction designed. All these involves additional clerical work and a decision has to be
made as to when updating will take place, either creation stage or as completion of the
new file. Once files are converted, files are to be verified and validated. Controlling of
rejection is to be done.

Parallel System Approach:

This approach is used when the user and the developer are not sure about the
immediate success of the system. In such as case, they apply the new system in parallel to
the old system. This gives sufficient time for the new system to’ be tested. However, this
approach may turn out to be risk, if the parallel systems continue for a long period as the
users will never be able to develop confidence in the new system. Moreover, double the
efforts would be required to maintain two systems simultaneously. This may lead to
users’ resistance. Simple, small size systems like finance, payroll etc. are the suitable
candidates for this.
It means processing current data simultaneously by both old and new system in
order to crosscheck results. (This will be useful if the old and new outputs are strictly
comparable).

87
Direct Conversion Approach:
This approach applies to systems, which require a large set of resources for their
operations and it is not feasible to run the old and the new in parallel. A fixed date is
allotted for the start of the new system and change-over from the old system on the same
date and time. This approach brings the new system immediately in to use. But for this,
the system must have been thoroughly tested before change-over. If the system fails after
the change-over, there can be huge losses to the organization.
This implies the introduction of a completely new system without any reference to any
previous similar system which may exists. (used only when there is insufficient similarity
between OLD and NEW system.

Pilot Approach:
This approach advocates the implementation of the new system on a pilot basis,
e.g. introducing a reservation system at one of the reservation counters and after ensuring
its success, introducing it to all the others. This way, the risk of failure at every location
simultaneously is reduced. Moreover, if the system succeeds at one location, the word
spreads across all locations in favour of the system. This brings about a change of
attitudes also. However, the reverse is a very costly affair, as the failure at one location
may elicit a negative response from other places also.
The new system is run using input data from previous period so that the results
are known and can be checked. Then now system is running taking current data.

Phase-In Approach:
This approach suggests breaking down the complete system into various sub-
parts, which can be arranged in sequence according to priorities and allocates time slots
for its implementation accordingly. For example, if the complete information system is to
be implemented in an organization, it may be divided according to various functions such
as finance and marketing in the first phase; inventory and purchase in the second phase;
production, planning etc. in the third phase and so on. This approach is beneficial as the

88
independent parts of the system can be tested and implemented successfully one after the
other. This makes the implementation manageable.
This is a method in which the new system is introduced in a piecemeal fashion by
phasing in different areas of work gradually. This makes personnel transfer easier.

SYSTEM CONTROLS
The general considerations may be identified as follows :-
i) control should be exercised as soon as possible
ii) controls must be defined
iii) Adequacy of control

ERROR STATISTICS : Any major system should include provision for statistics of
errors to be maintained. This will enable the effectiveness of each control to be
ascertained & allowed analysis to show which errors could have been identified &
corrected earlier in the system. Not only this will enable sequent improvements to be
made to the system but will also enable more effective controls to be incorporated in
other system.

SYSTEM CONTROLS IN COMMON USE:

1. CONTROL TOTALS: - The principal of control totals is that the value of a particular
data is summed as a separate clerical process & when the input documents containing the
same data elements are processed by computer a machine-generated total is created &
reconciled to the control total. This system is mainly used to control input for batch
process system.
2. HASH TOTAL: - Hash totals are basically the same as control totals except that the
total itself has no intrinsic value. This the total of the data element ‘Gross Pay’ on a batch
of input document for a wage application should be a control total.

SYSTEM SECURITY

89
 Considerable publicity has been given in recent years to damages to computer
equipment and computer related crimes and therefore this had made organizations more
conscious of the need to make the computer systems secure. A. computer based system is
a combination of many assets such as hardware, software, data, combination of many
assets such as hardware, software, data etc.
The computer systems must be made secure against all of this. The possible reasons for
damages are:
1) Fire, flood, riots and dust etc.
2) usage by unauthorized persons. -
3) Incorrect usage by authorized persons
4) Intentional damages by employee etc.
5) System fault (hardware)
6) software faults
7) Human errors/omissions.

Because of these reasons if the damage is done to the computer system the result of the
same maybe:
1) loss of availability
2) loss of accuracy
3) disclosure of information
4) Loss of money
5) loss of time.

To avoid above mentioned losses, the system analyst must take maximum possible care
to avoid the occurrence of such events. While designing the computer based systems he
should consider the following points: -

I) distribution of responsibilities
2) fire alarm system
3) restricted ehtry
4) dust free and air conditioned room

90
5) keeping equipments under lock and key
6) designing menu driven computer systems
7) using password security
8) using system control / system lock files
9) backup procedures
10) prevention of access to other area such as software/programs/utilities, data files etc.
11) controlling job operations by writing macros.
12) user training
13) user documentation
14) assigning terminal oriented jobs.

By taking help of above prevention measures the system analyst, can reduce the
possibilities of the damages that would be there though he cannot stop them completely.

SYSTEM EVALUATION REVIEW AND MAINTENANCE

Just after system is installed we should review the tangible and intangible benefits
of the system. The system performance or realization of objectives set is experienced or
not is evaluated.

SYSTEM PERFORMANCE :-
To do system audit check
- whether user is satisfied with the performance of system.
- whether outputs are Accurate/timely whether it contain insufficient or unwanted
information.
- operational aspects: whether procedures are causing problems
- effectiveness in terms of error / inaccurate data / turnaround / response time / reliability
- changes in volume of data information and paper handling and clerical and computer
timings.
- data volume and growth rate
- staffing level

91
- error rate

Cost and benefits: Here actual cost/benefits are compared with those planned. The
deviation in cost occurs due to
- unplanned pay increases
- extra staffing / retention of initial staff
- changed methods of computer charging
- inaccurate estimation of data volume timing
- authorized / unauthorized changes to procedures and documents.
Deviation may be there due to environmental arising from operational, trading and
statutory changes.
- pay method, accounting policy, new equipment or techniques
- staffing policy.

SYSTEM MAINTENANCE

Most changes arises

- as a part a failure or normal system running and user asks for improvement or external
requirement changes.
- as a result of a specific investigation and review of the system performance.

Direct amendment many course damages to the system links. Unless each amendment
well documented and analyzed is not done.
Before doing amendment consider following points -
- effect of amendment on objectives of system
- effect on present state of system development / operations
- cost of amendments .
- timescale for the change

POST IMPLEMENTATION REVIEW:

92
 This is important for the success of a system. It refers to the proper, periodic
feedback system of the users in order to measure the success of a system. This is not an
easy parameter to measure. Different people with different styles of decision-making and
problem solving, will have different responses to the same system. Nevertheless, a formal
set of measures has been identified. The most important of these success measures are as
below:
High levels of system use as measured by polling users, employing questionnaires, or
monitoring parameters such as the volume of on-line transactions.
User satisfaction as measured by questionnaires or interviews. This might include users’
opinion on the accuracy, timelines, relevance and quality of information. The enhanced
job performance, employee satisfaction can also be asked for.

Favorable attitude of users about IS and the IS staff.

Achieved objectives the e to which the system meets its specified goals; as reflected by
improved organizational performance and decision-making resulting from use of the
system.

Financial Payoff to the organization, either by reducing costs, or by raising sales or

profits.

CAUSES OF IMPLEMENTATION FAILURE:

The following problems are considered typical of each stage of the development
cycle for poorly managed implementation, which often leads to failure:

Analysis:

• Time, money and resources have not been properly allocated to researching the
problem. The problem is poorly defined. Thus, objectives of the implementation
will be vague and ambiguous.

93
 • Little time is spent in preliminary planning. No standards have been used in the
time and cost estimation.
• The project team is not properly staffed. User groups are not involved and
technical people are included on the basis of availability, not skills.
• The development team promises results which are not achievable.
• Analysts lack good communication skills. They cannot ask users the right
questions..
• Requirements are derived from an inadequate systems study or documentation of
the existing system.
• Requirement specifications are poorly documented.

Design:

• Users are not involved in the design. Thus, the technical team makes the design
with their own biases, It does not mesh well with the real structures, work and
culture of the- staff.
• The system is rigid and caters to current needs only.
• Drastic changes in the roles and procedures are made.
• Documentation are poorly done.

Coding:

• The amount of time and cost of development is underestimated.

• Programmers are not given complete specifications.
• Enough time is not given to the process logic development.
• The programs written do not follow proper software engineering concepts. They
are tough to modify and maintain.
• Documentation of programs is not adequate.
• Computer time and other resources are not scheduled.

94
Testing:

• The amount of time and cost for testing is under estimated.

• The development teams don’t prepare test plans.
• Users are not involved in testing.
• Proper acceptance tests for management review are not developed.

Conversion:

• Insufficient time and cost are allocated to data conversion.

• Not all the anticipated users of the system are involved. Training is provided to
them after the system has been brought into use.
• To compensate for the time and cost overruns, the system is made operational
before it is actually ready.
• System and user documentation are incomplete.
• No performance standards are established for weighing the results against the
objectives.
• Provisions for system maintenance are inadequate.

USE CASE DIAGRAM

95
USING SYSTEM BOUNDARY BOXES TO INDICATE RELEASES

SEQUENCE DIAGRAM

96
 CASE: COMPUTER ASSISTED SOFTWARE (SYSTEM) ENGINEERING

Computer Assisted Software Engineering or CASE is the latest technique. But it

is not so much a technique as it is an enabling technology for the structure techniques. In
other words, CASE provides computer automated support for the structured techniques.
Synonyms for CASEI include computer assisted design computer assisted programming
(CAD/CAP) and the analyst/programmer workbench. CASE helps analysts overcome of
the key disadvantage of the structured technique lower productivity. The very required by
the structured techniques usually slow project progress. CASE increases the productivity
through computer tools. At the same time, it improves quality in both system and
documentation.

97
CASE products are built around the concept of a project dictionary (or encyclopedia) that
stores all facts of the system specifications. The dictionary is complemented by a host of
facilities that support various methodologies and techniques.
These facilities typically include.
• GRAPHICS TOOLS for various structured and classic techniques for example,
data flow diagram, flowcharts, data models, structure charts, state-transition
diagram and the likewise.
• DICTIONARY TOOLS to record, maintain and report on system details — for
example, Contents of files, inputs, and output, properties of data elements, and
logic rule for process.
• PROTOTYPING TOOLS for external designs of inputs, screens, forms, and
outputs. Some CASE tools can be interfaced to fourth-generation languages and
applications generators.
• AUTOMATIC QUALITY CHECKING for graphics and dictionary
specifications. The Computer can proof models and applications for consistency
errors.
• CODE GENERATORS to eliminate or reduce programming efforts required to
transform the specifications into working systems.
• COST-BENEFIT ANALYSIS TOOL and interfaces to spreadsheet.
• PROJECT MANAGEMENT TOOLS for planning and controlling the activities
of the System development life cycle.
• DOCUMENTATION TOOL assemblers to combine various specifications into
reports for various audiences, technical and non-technical. This facility
frequently interfaces to popular word processors.

CASE Components

CASE tools generally include five components: diagramming tools, an information

repository, interface generators, code generators, and management tools. Most of the
emphasis has been on high-level activities, although low-level code generators are now
emerging.

98
Diagramming Tools

Diagramming tools support analysis and documentation of application requirements.

Typically, they include the capabilities to produce data flow diagrams, data structure
diagrams, and program structure charts. As you already know, these high-level tools are
essential for support of the structured analysis methodology. And CASE tools incorporate
structured analysis methods extensively.
They support the capability to draw diagrams and charts, and to store the details
internally. When changes must be made, the nature of the change is described to the
system, which can then redraw the entire diagram automatically. The ability to change
and redraw eliminates an activity that analysts find both redious and undesirable.

Centralized Information Repository

The capture, analysis, processing, and distribution of all systems information is
aided by a centralized information repository or data dictionary, (We will use the terms
information repository and data dictionary interchangeably, although vendors may use
one or the other when publicizing their products.) The dictionary contains the details of
system components, such as data items, data flows and processes and also includes
information describing the volume and frequency of each activity.
While dictionaries are designed so that the information is easily accessible, they
also include built-in controls and safeguards that preserve the accuracy and consistency
of system details. The use of (1) authorization levels, (2) process validation, and (3)
procedures for testing consistency of descriptions ensures that access to definitions and
the revisions made to them in the information repository occur properly according to
prescribe procedures.

Interface Generators

System interfaces are the means by which users interact with an application, both to enter
information and data or to receive information, Interface generators provide the capability

99
to prepare mockups and prototypes of user interfaces Typically, they support the rapid
creation of demonstration system menus, presentations screens, and report layouts.
Interface generators are an important element for applications prototyping,
although they are useful with all development methods

Code Generators

Code generators automate the preparation of computer software. They incorporate

methods that allow the conversion of system specifications into executable source code.
Code generation is not yet perfected. Thus, the best generators will produce
approximately 75 percent of the source code for an application. The rest must be written
by hand. Hand coding, as this process is termed, is still necessary.
Because CASE tools are general-purpose tools, i e, not limited to any specific
application area such as manufacturing control, investment portfolio analysis, or accounts
management, the challenge of fully automating the software generation process is
substantial.
The greatest benefits accrue when code generators are ihtegrated with a central
information repository Such a combination achieves the objective of creating reusable
computer code. When specifications change, code can be regenerated by feeding d from
the data dictionary through the code generator. The dictionary contents can be reused to
prepare executable code.

Management Tools

CASE systems also assist project managers in maintaining efficiency and effectiveness
throughout the application development process. This CASE component assists
development managers in the scheduling of analysis and design activities and the
allocation of resources to different project activities For example, some CASE systems
support the monitoring of project development schedules against actual progress, as well
as the assignment of specific tasks to individuals. Schedules and reports can be prepared
using details stored in the data dictionary.

100
Data Dictionary:

A data dictionary is a catalog - repository• of the elements in a system. These

elements enter around data and the way they are structured to meet user requirements and
organizational needs. The major elements of data flow, data stores and process. The data
dictionary stores details and description of these elements.

Analyst use data dictionaries for five important reasons:

1. To manage the detail in large system
2. To communicate a common meaning for all system elements
3. To document the features of the system
4. To facilitate analysis of these details in order to evaluate characteristics and determine
where system changes should be made.
5. To locate efforts and omissions in the system.
The dictionary contains two types of description for data flowing through the system :
data elements and data structures. Data elements are grouped together to make up a data
structures.
DATA ELEMENTS: The most fundamental data level is the data element (field ). They
are the building blocks of all other data in the system. By themselves they do not convey
enough meaning to user.
DATA STRUCTURES: A data structure is a set of data items that are related to one
another and that collectively describe a component in the system.

The data dictionary is written as follows:

APPLICATION: ORDER PROCESSING DICTIONARY NAME: ORD.DCT

Entity/Attribute Entity type Description Type Width

Remar
k

101
CUSTOMER DETAILS RECORD
Customer
Customer No. ELEMENT N 4
Number

PROTOTYPING :

The term prototype refers to a working model of an information system

application. The prototype does not contain all the features or perform all the necessary
functions of the final system. Prototype has five characteristics:
* The prototype is a live, working application
* The purpose of prototyping is to test out assumptions made by analyst and user about
require system features.
* prototypes are created quickly.
* prototypes evolve through an interaction process.
* Prototypes are relatively inexpensive to build.

STEPS IN PROTOTYPE METHOD:

- identify known requirements

- develop working model (components are: a. command language dialogue or
conversation between user system. b. input screens and formats c. essential processing
modules d. system outputs).
- review prototype
- repeat as needed
- implement prototype
- redevelop application

TOOLS FOR PROTOTYPING:

- fourth generation languages
- Non-procedural languages

102
- query and retrieval languages
- report generators
- application generators
- screen generators.

The advantages and disadvantages are as follows : -

* Prototyping encourages and requires active end-user participation. This increases end-
user morale and support for the project. End-user morale is enhanced because the system
appears real to them.
* Iteration and changes are a natural consequence of systems development-that is, end-
users tend to change their minds. Prototyping better fits this natural situation since it
assumes that a prototype evolves, through iteration, into the required system.
Maintenance problems that have plagued systems developed in language like Cobol.
* Prototyping does not negate the need for survey and study phases. A prototype can just
as easily solve the wrong problems and opportunities as a conventionally developed
system.
* You cannot completely substitute any prototype for a proper specification. No engineer
would prototype an engine without some paper design. Yet many information systems
professional try to prototype without a specification. Prototyping should be used to
complete, not replace, other methodologies. The level of detail required of the paper
design may be reduced, but it is most certainly not eliminated.
There are numerous design issues not addressed by prototyping. There issues can
advertently be forgotten if you are not careful.
* Prototyping often leads to premature commitment to a physical system. • In other
words, the selection phase gets shortened.
* When prototyping, the scope and, complexity of the system can quickly expand beyond
original plans. This can easily get out of control.
Prototyping can reduce creativity in physical design. The very nature of any
physical implementation - for instance a prototype of a report - can prevent analysts and
end-users from looking for better solutions.

103
Prototypes often suffer from slower performance than their third generation language
counterparts.

4GL AND CASE : ADVANTAGES AND DISADVANTAGES

Productivity tools such as 4GL’s and CASE offer analyst, user, programmer, and
management an attractive alternative .to the traditional life cycle approach to systems
analysis, design and development.

The Advantages are

- Increase productivity of analysts and programmers
- Improved communication between user and analyst
- Higher quality software with fewer errors
- More satisfied users
- User involvement through the entire process
- Reduced maintenance
- Reduced time spans for development and maintenance
- Complete and consistent user and technical docun
- Enforced standards for design, program document for all applications.
- Ability to evaluate application changes before imp -
- Decreased testing time, -
- Increased flexibility and quicker response to rapidly changing business needs.
- Improved organizational effectiveness.
- Common interface and documentation for all systems.

The disadvantages are:

- Additional expenses of CASE/4GL software
- No standardization among different CASE/4GL software as products (3GL languages
do enjoy a higher degree of standardization)
- Retraining of staff and associated expense, plus lost time.
- Difficulty of matching new CASe/4GL software development to existing software

104
- Less efficient use of hardware with 4GLs versus 3GLs.

CONCEPT OF REVERSE ENGINEERING:

Reverse Engineering is the process in which the operational system is deduced for
system’s database design and data element. It also examines which pr use specific data
elements. The advantages of reverse engineering on existing software are found in
maintenance. The reverse engineering facility is available in many of the CASE tools.
These CASE t6ols can reverse engineer database and file structures to data models,
design recovery, typically in the form of control flow or module hierarchy. it provide
facility for extracting design information from existing legacy system. This design
recovery will allow organization that have significant investments in 3GL systems
without adequate documentation to capture the architecture, logic and ultimately business
rules and models that are buried within the older system that are outdated and must be
replaced. Once system is analyzed, the software can be modified for new look.

TYPES OF DATA PROCESSING TECHNIQUES:

1. BATCH PROCESSING: The technique of batch processing is very widely applied in

clerical, mechanical and electronic data processing system. It is concerned with
processing batches of collected data for a defined period of time is the basis for obtaining
processing efficiency. Many businesses have high volume of routine data processing
requirements & have installed batch processing computer configurations to obtain the
benefit of high speed accurate data processing. The main features of a batch processing
configuration are automatic input and output devices, which operate with a minimum of
manual intervention under the control of a stored program after the device have been
loaded with transaction data and appropriate print-out stationary.

Applications - Batch processing applications relate to specific applications such as

payroll, stock control, invoicing & sales ledger, purchases, purchase ledger, etc. Each

105
application consists of a number of computer runs each of which is designed to
accomplish a defined stage of processing in respect of each transaction.

2. ON-LINE PROCESSING : The technique of processing data by computer by means

of terminals connected to and controlled by a central processor. In this way various
departments in the company can be connected to the processor by cables. If operating
companies are a number of Km away from the processor they are linked by means of
telegraph or telephone lines.
This type of processing provides multi-access to information files by terminal
users & also enables them to update files with transaction data. Such systems are often
used as a more efficient alternative to batch processing. In this case, instead of preparing
data in a machine sensible form for processing in batches at predefined period of time,
input of transaction data is affected by any terminals at random time intervals.

Applications :-
1) Banking : It is possible to inform bank customers of the status of their
• account in response to an inquiry.
2) Tour Operators: Reservation offices accept telephone inquiries from travel agents
regarding availability of room for a particular day for some person. If available the room
can be booked.
3) Stock Exchange: Terminals located in major stock exchanges throughout the country
& the offices of participating brokerage firms enable speedy processing of share dealings.
4) Stock Control: Terminal located in warehouses provide the means for automatic
reordering of stocks, updating of stocks rè reservations, follow up of outstanding orders.

3. REAL-TIME PROCESSING: Some businesses are depend for efficient’ operation

On up- to-date information being immediately available on request. This is particularly
the case of respect of business with geographically dispersed operating units, such as
airlines with dispread booking offices and tour operations.

106
 The term “Real Time” refers to the technique of. updating files with transaction
data immediately the even to which it relates occurs. This is in• distinction to “batch
processing” which ‘processes related data in batches at pre-defined periods of time.
A real-time computer system is communications-oriented and provides for random
inquiries from remote locations with instantaneous responses because of this
characteristic this type of operations is referred- to also on line of conversational
processing.
Real time processing is suitable when it is necessary to have the latest possible
information in the following types of business operations (a) Meteorological data (b)
Defence Data (c) Airlines - flight seat availability etc.

QUESTIONS

1. XYZ Telecom Ltd. has launched its mobile services in Ahmednagar. Subscription
Or membership for its services will open for customers from June the following
procedure is proposed by sales dept.:
- There are 3 schemes for subscription.
- AhmednagaR region is divided into 6 area sales office.
- Customer can collect subscription forms at any sales office.
- Customer submits filled form and payment by DD/Cheque at any sales office.
- Forms are verified, subject to realization of payment customer is informed about
Mobile number by a letter.
- Customer pick ups equipment from Sales Office.

107
The Regional Office wants to generate MIS, you are expected to design the following:
(1) Entity Relationship Diagram.
(2) File Design upto 3NF 8.
(3) Routine Reports and Analytical Reports (at least 3).

2. Managing director of ABC Hotels Pvt. Ltd. has decided to open E-Dhaba for the
people of Pune. The actual site for Dhaba is proposed at 20 km on Pune-Murnbai
highway. The site will provide the following information:
- Information of menu card.
- Order booking form.
- Payment process.
Based on above information people can place orders on net which are confirmed with you
using fax or phone. Orders are executed at site or Home delivery as per the request
customer. Bill is prepared based upon order against which customer can make payment
using E-Credit card in advance or by cash.
You are expected to draw level-one Data Flow Diagram.

3. Preet has decided to sale Vegetables/Fruits on net people can place order on Net. Bill is
prepared as soon as order is placed. Customer can pay bill in advance by credit card or by
cash after home delivery.
For the above case:
(1) Draw structure chart.
(2) Draw order booking form.
4. Regional Transport Office (R.T.O) is related with registration of the new vehicle and
insurance of the vehicle. For the new vehicles the registration is done according to the
type of vehicle (2/3/4 wheeler) and also according to (Light/Medium/Heavy).
The registration of vehicle is done according to the following rules:
- if the vehicle type is any one and the weight is light then registration charges are
Rs.100.
- If the vehicle type is 3 wheeler and the weight is medium then the registration charges
are Rs.1 50 and if weight is heavy then the registration charges are Rs,200.
- If the vehicle is .4 wheeler and the weight is medium then the registration charges are
Rs.200 and if weight is heavy the registration charges Rs.300.
Carry out the decision analysis, using Decision Tree and Decision Table.

108
5. Draw a layout of telephone booking form along with required validations. .

6. (a) Discuss the need of prototyping model in software development.

(b) Explain the concept of Reverse Engineering in the field of Software Engineering.

7. Write short notes on

1. Principles of Good Report Designing
2, On-line Processing.
3. Feasibility Study
4. CASE Tools.
5. Software Quality Assurance.

8. Ramesh Company is a wholesale and retail distributor of commercial cleaning

products. It buys supplies in la quantities and sells them to its customer in smaller lots,
depending upon type of at item The firm is well managed and profitable, and has been in
business in its current location for. 20 years. The ms owner is considering, developing a
computer based system for managing the Inventory, on hand in the
Warehouse which has the following business transactions:.
— Items in bulk are from supplier. along with DC cum Invoice.
—. Verification of items is done with purchase Order.
— Rejected items are sent back to supplier along with’ Rejection Note
-— Customers are informed about their orders are. ready for dispatch using packing list
which is prepared based upon sales order
— Material is dispatched along with DC cum Invoice after customer has given
confir4lation on packing ‘li8t. .
— Customer sends Replacement note along with the material which is to be replaced.
You are expected to draw level one, Data Flow Diagram.

9. Kiran Kulkarni, a newly hired system’s Analyst with your system’s group, has come to
you with an idea. that he assures you will save team time, and hence the business you are
cons will save money. Kiran proposes that rather than doing time consuming interviews,

109
or collecting current quantitative and qualitative. Documents;, the team rely primarily on
what it discovers in archival data. They even have their old reports from earlier systems
projects. We don’t have to talk with any one we can access to material all day without
seeing a .soul.
(a) List the merits of what Kiran is proposing.
(b) List the problems with what Kiran is proposing.
(c) Explain tactfully to Kiran why the systems team uses many different approaches for
data gathering.

11. Design a data entry screen for data creation of marks obtained by students in MCM
admission procedure including entrance, group discussion and personal interview marks.
Also write logic to print the merit list of first 60 students.

11. What importance do the following gem systems concepts have for the systems
Analyst who is working on. the development of computer based information system?
Give examples of each as they apply to information systems ?.
(a) System Boundary
(b) System
(c) Feedbacks
(d) Open system
(e) closed system
(/) Sub-system
(g) Performance Standard .

12 Solve the following.

(a) What are the objectives of Input Design?

(b) Identify the symbols used in Data Flow Diagrams and explain how each is used.

(c) What is a data dictionary? Why is it important in systems analysis and design?

110
13. A management of a supermarket proposes to computerize its sales & purchase
activities. Customer selects items with required quantity. All such items are collectively
presented to the counter clerk for billing. The clerk records the item code and the He also
enters the unit price of an item selected. The final bill contains item description, unit of
measure, unit rate, quantity and value. The total payable amount is displayed at the foot
of the bill. Necessary taxes are also included in bill. After the payment of the bill the
stocks of various items are updated.
The stocks of items are also updated when the purchases are made from time to time.
Suggest a suitable system design to cover following:
1) Current stock position of an item
2) Item wise total quantity sold.
3) Total sale -by value.

Draw:
1)1st level DFD.
2) Normalized file layouts.
3) Screen layout for bill entry.

14. Design input form layout to collect the information about depositor. The organization
collects deposits from public for the period of 3 years with minimum amount of
Rs. 3000 Maximum amount is Rs. 15,000. The rate of interest is 10% and for senior
citizen it is 1% extra, income tax is recovered wherever necessary at @ 1%.

15. Draw decision tree for the following income tax is calculated and deducted from the
salary of an employee, as follows: .
1) If monthly salary is less than Rs. 10,000 no tax deducted.
2) Salary between Rs. 10,000 & Rs. 15,000 tax @ 0.5% deducted.
3) Salary between Rs. 15,000 & 20,000 tax @ 1.5% deducted.
4) Salary above Rs. 20,000 tax @ 2% deducted.
5) No tax deducted, if employee is physically disabled.

111
6) In addition to the tax above security tax charged as Rs. 100 for salary more than
Rs. 25,000.

16. A city Co-operative bank has computerized its branch activities. The head office
requires certain summary & detailed reports from the branches, Suggest the report
layouts to print
1) Summary of type wise loan disbursed in the month.
2) List of pre-matured deposits.

17. Explain the characteristics of relevant information

18. Discuss the purpose of E-R diagram and its use in SDLC.

19. Write short notes .

1) Waterfall method.
2) N-S diagram.
3) System maintenance.

20. Customer sends the list of items, along with the quantity to the organization The
organization buys the items asked by the customers, packs as-per quantity required and
gets them bundled for dispatch. Before items are bundled, the list is checked fir any
missing items. Based on amount of goods ordered, service charge is added to the invoice.
A service is completed; when paining is received from the customer payment can be
through cash or cherub. The objective of organization is to provide better service to the
customer. As a Systems Analyst you are required to design following.
1) E.R. Diagram
2) File layouts .
3) Report layouts- (minimum 3)

21. Draw Decision tree and table for the following.

Eligibility criteria for university examination for post graduate course i

112
1) Maharashtra domicile student should acquire minimum 45 % marks in Basic
graduation..
2) Non-Maharashtra domicile student should acquire minimum 55% marks in Basic
graduation.
3) Concession of 5 % considered, if student has, represented university at national level
in any sports event.

22 Design a suitable form to collect the viewers opinion on various T.V. serials
transmitted by various T.V. channels.

23. Draw the complete menu tree for inventory system of Raw material and Finished
Goods.

24. The police department wants to maintain a database of crimes. Following are the data
structures available in computerized system
1) Crime Type Master 2) Criminal Master
3) Police Station Master
Give data dictionary for above data structures assuming important attributes. Justify
layout of the dictionary.
25. A computer company has distributed numeric pagers to its maintenance engineers.
The pager can receive only ten digits message, but of which 6 digits are used for phone
number of the customer.
The company would like to use additional 4 digits also for sending meaningful
information the pager.
There are around 53 customers who make complaint calls to company frequently. There
arc three types of equipments such as computers, printers, stabilizers, supplied by the
company to the customer.
Whenever the customer lodges the complaint to the company, they ‘convey the nature of
the equipment. When company receives such a complaint call, it in turn decides the Ivel
of urgency and gives page call to the specific engineer.

113
Design the suitable coding structure for 4 digits so that meaningful information / message
codicil he conveyed to the engineer.

26. Draw the complete menu tree for inventory system of Raw material and Finished
Goods.
27. a) Explain Waterfall Model in detail.
b) What is Reverse Engineering?

28. Write short notes on

i) Types of system ii) Batch v/s Realities Processing
ii) 4 GL iii) State Transition Diagram

29. Management of Sanjeevan Hospital proposes cornputerization, patient register and

billing visiting doctors visit the hospital as per the schedule declared. The aid on monthly
bask.
Against the charge-slips us A detailed register is maintained For patients admitted in Tim
hospital Room charges and laboratory charges are recorded if the register against each pat
lent At the time of discharge, patient is given the bill showing the above details. As a
systems analyst.
1) Prepare normalized file layouts.
2) Draw E.R. diagram
3) Design data entry screen for patient admission details.
4) Program plan
5) Report layouts

30. A television manufacturing company has assigned a responsibility to M/s Shriram

advertisers t conducting market survey. It is expected that survey reveals — sale of T.V.
sets, rnodelwise performance of the various models; pricing structure etc, for different
manufactures.
The survey conducted in major cities, nation-wide.
You are requested to design a questionnaire to cover above requirements. l()

114
Draw context and jest level physical DFD, ABC auto Ltd. Procures material against a
purchase requisition received from stores. The material is supplied against a purchase
order prepared by purchase department. Received material is recorded in GRN and sent
to inspection dept. for accep1anct report: Based on the report the stocks are updated.
GRN is further sent to purchase dept. For processing supplier bill.
- To record fixed deposit details, design a suitable screen layout with following details
- Name and address of depositor
- Amount of deposit
- Rate and period of deposit
Mode payment -
State various validations and checks to be provided.

31.A garment dealer declares pricing policy. The reduction declared is as under
- Qty. ordered in a single style,
a) Qty. between 50 and 100 — reduction of Rs. 5 per piece
b) Qty, between 101 and 150 — Rs. & per piece
c) Qty. 150 and more .4ff per piece
- Qty. ordered iii unit styles
d) Qty. between 10 and 20 - Rs. 2% per piece.
e) Qty. between 21 and 40 — Rs. 4 per piece.
f) Qty. 41 and more — Rs. 4.5 per piece
If customer is associated, for more than 10 years, he is granted further discount of 10 %
on the total value.
Draw decision tree for the above.

32. Compare the following approaches of software development:

33. Write short notes:

a) System maintenance
b) FDD
c) Reverse engineering

115
d) State transition diagram

33. “The primary goal of Software Engineering is to improve the quality of software”
Elaborate the need of Software Engineering for software projects.

34. Explain the method of estimating software maintenance cost and elaborate types of
maintenance.

35. Explain classical life cycle and prototyping approach to SDLL in detail.

36. Explain feasibility study and elaborate on cost benefit analysis.

37. Explain the importance of Documentation in System design.

38. Explain the stages involved in SDLC.

39. Explain in detail the skills required by a systems analyst.

40. Explain the different types of Processing Techniques.

116