UNIT 12 SYSTEM ANALYSIS AND DESIGN:

AN OVERVIEW
Structure

12.0 Objectives
12.1 Introduction
12.2 Systems Concept
12.3 Systems Analysis – What and Why?
12.4 System Life Cycle
12.4.1 Objectives and Feasibility
12.4.2 System Analysis
12.4.3 System Design (Logical)
12.4.4 System Design (Physical)
12.4.5 Implementation
12.4.6 Maintenance
12.5 Let Us Sum Up
12.6 Clues to Answers

12.0 OBJECTIVES

After going through this Unit, you should be able to:

• understand the concept of system,

• understand what and why of Systems Analysis,

• develop a broad appreciation of the design and development of Computer Based Information
System (CBIS),

• know about the various aspects and components of System Life Cycle in a CBIS, and

• appreciate the efforts involved in each of the stages of the system life cycle.

12.1 INTRODUCTION

You already have a fairly good idea about system from Unit 8. As you know, “a system is an
organised, interacting, interdependent and integrated set of components/variables/ parts. A system
has objectives or goals” (Lucas, 1985, p-5)

This Unit, apart from briefly repeating some of the earlier discussed ideas, further builds upon
them.

System analysis and design provides a structured approach to the design and development of
Computer Based Information System (CBIS). A CBIS is a set of software packages which
when executed, provides information for decision-making, i.e., it is a help and a part of MIS.
Designing and developing of CBIS is one of the most important activities in any organisation, as
it involves people at different levels in the organisation. Like any living organism, a CBIS also
has a life cycle.

175
Regardless of where the data or information processing system has been implemented, what
functional area it addresses, what level of management it caters to and who has designed,
developed and implemented it, the growth of an information system passes through various
identifiable stages and all these stages put together are referred to as the System Development
Life Cycle.

The system size, complexity and coverage do not affect these stages, any system designed for
processing of information revolves around a life cycle that begins with the recognition of the
problems and ends up with development and implementation of the system.

To appreciate the stage involved in design and development of an information system and the
efforts required to build up these systems it is a must that managers should be familiar with the
distinct stages of this cycle. The various stages and related issues have been discussed in this
Unit.

12.2 SYSTEMS CONCEPT

A couple of other definitions of systems are –

• Webster unabridged dictionary describes system as a set or arrangement of things so

related or connected to form a unity or organisation.

• A system is a set of elements forming an activity or a processing procedure/or a scheme,

seeking a common goal or goals by operating on data/and/or energy and/or matter (inputs) in
a time reference to yield information and/or energy and/or matter (output) (Murdic Ross and
Claggett, 1990, p.15)

There are also several ways of classifying systems. Three such classifications are: (1) Natural or
man-made (2) Closed or open (3) Conceptual or physical.

Natural systems occur in nature, like the solar system, On the other hand man-made systems
are deliberately created for specific objectives. For example, Communication System, Transport
System, Organisations, etc.

Closed systems theoretically, are self-sufficient and have no interaction with their environment.
In practice, those, which are relatively cut off from the environment are termed as closed.
Whereas open systems exchange information and/or energy and/or material with their
environments. As members (parts) of a system they receive from the environment as inputs and
give to the environment as output.

Conceptual systems are theoretical in nature and deal with concepts which may or may not
physically exist. Sometimes it may be possible to convert a conceptual system to a physical
system, for example, Social System, Economic Theory, etc. In contrast physical systems
physically exist in real world. They are generally man made, e.g., Production System, Power
Generating System, Fire Control System, etc. However, these classifications are not necessarily
exclusive of each other. For example, there can be a system which is man made, open and
physical.

The information systems are considered to be evolved through three different levels of systems.
These are:

a) Conceptual System: Every information processing system is evolved by way of a concept

when somebody imagines that the organisation should have such and such a system to

176
 accomplish such and such an objective. A system so conceived may or may not be attained in
reality. A conceptual model is no more than an idea.

b) Logical System: When the conceived system model is further worked out to design new
ways to accomplish the objective set out in the conceptual system, it becomes the logical
system design. A logical system design necessarily includes understanding of the flow of
information, logic of processing and input-output relationships. The Data Flow Diagrams,
Flow Charts, etc. are the basic components of the logical models.

c) Physical System: When the logical models are developed to actually deliver the desired
results, it is referred to as a physical system model. The physical system model can be tested
and implemented. It consists of programmess, data files and documentation.

In subsequent sections, we will be particularly discussing the in open, physical man made systems
such as Organisations and Computer Based Information System which is used in MIS.

Check Your Progress – 1

1) What do you understand by system? How can we classify systems?

………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...

2) What are the three different levels of information system?

………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...

12.3 SYSTEMS ANALYSIS – WHAT AND WHY?

What is Systems Analysis? Well Harry Coode and Robert Machol mentioned that:

For more than a decade, engineers and administrators have witnessed the emergence of a
broadening approach to the problem of designing equipment. This phenomenon has been
poorly understood and loosely described. It has been called Systems design, Systems
analysis and often the Systems approach. Rarely does the speaker using these terms intend
to convey those concepts which are brought to the minds of his or her hearers, nor for that
matter are any two hearers likely to be in agreement.

Analysis of the system means identification, understanding and critically examining the system
and its parts (sub-systems) for the purpose of achieving the goals (objectives) set for the system
as a whole, through modifications, changed interrelationships of components, deleting or merging
or separating, or break up of components. It may also involve upgrading the system as a whole.
The methodology of systems analysis involves:

177
1) identification of the system (setting system boundary), the system objectives, the system
elements (components), and
2) understanding the role and interrelationship of elements with other elements of the same
system.

This identification and understanding process generates:

1) the capability (or background), the system objectives, the system elements (components), and
2) system functioning vis-à-vis the system objectives.

Outcome of the systems analysis job is a set of recommendations towards creating a system
which best meet its objectives giving due regard to cost-effectiveness and the risks.

Systems analysis, thus, emerges as a means through which the total system is conceived,
designed, implemented and made operational to achieve the desired objectives. The basic
objective of systems analysis is to understand and modify the system in some way to improve its
functioning. The modification may require one or more of the following: change the outputs,
change the goals of the system, make it more efficient, have different set of inputs or improve in
some other way or even create a new system.

Why Systems Analysis?

The understanding of what systems analysis is, itself provides an insight into its importance and
why it is needed. Systems analysis basically is an approach towards viewing the processes,
activities, and complex problems in their totality. Thus, specifically it:
• offers a means to greater understanding of the complex structures,
• is a means to trade off between functional requirements of a subsystem (component) and its
immediately related subsystems,
• helps in understanding and comparing functional impacts of subsystems to the total system,
• helps in achieving inter-compatibility and unity of the purpose of subsystems,
• helps in discovering means to design systems where subsystems may have apparently
conflicting objectives, and
• helps in placing each subsystem in its proper perspective and context, so that the system as a
whole may best achieve its objectives with minimum available resources. It thus creates
synchronisation between systems and objectives.

Thus, systems analysis is one of the important techniques that provides a systematic and broader
outlook to understanding, examining and creating or modifying systems to meet specific
objectives. Systems analysis and design is an interactive and creative process.

12.4 SYSTEM LIFE CYCLE

The various stages in the life cycle of a CBIS are described in detail in the following Sub-
sections.

178
12.4.1 Objectives and Feasibility

The first and the most important step is to provide a broad statement of organisational objectives,
for the proposed CBIS. This is primarily a responsibility of the top management, since this
Information System is expected to help the organisation and the management in the discharge of
their function. The Information Systems development effort begins by understanding the
organisations objectives, for these are required to be translated to constitute the objectives of the
Information System.

The next step is to examine the feasibility of the proposed system. This involves considering
various broad alternatives, such as, valuating the costs and benefits of the system. Initially a
rough cost-benefit analysis will be sufficient for the top management to take a decision either in
favour of or against the proposed CBIS.

Costs include costs of design, development, implementation and maintenance of the system.
Benefits will be realised from the timely and accurate generation of required information to meet
the stated objectives of the organisation. It is to be realised that a database created for a particular
CBIS application usually serves other applications as well to a certain extent. For example, a data
base for pay roll accounting can be used for applications such as Provident Fund (PF) accounting,
Retirement Benefits Accounting, Personnel Information Systems, etc. Such indirect benefits also
should be considered in the feasibility analysis. Also, even though system objectives in relation to
management/ organisation objectives have already been discussed, they are again reviewed and
made more specific with respect to peak level processing loads, complexity of processing, time
frame for various types and categories of output, frequencies of occurrences, communication
needs, etc. On the other side, assessment is also made of the restrictions or constraints on the
system. These restrictions may be external or internal and may be with respect to content,
processing requirements, procedures, input/output formats, data frequency; data accuracy, units of
measurement, etc.

External constraints may be due to government regulations, customers, suppliers, unions, social
groups, etc. Internal constraints can be due to the areas of operations of the organisation, its
policies, attitude and support of top management, the prevalent work culture within the
organisation, cost and resources for the proposed system, willingness of the user employees,
availability of required skilled manpower, internally and externally, etc.

Identification, recognition and understanding of both internal and external constraints is crucial
to designing a viable system. As part of the design effort, the designer provides for these
restrictions and knows to some extent what he or she can do and what he or she cannot do to
attain the stipulated objectives of the system. In the process, sometimes one may have to
review/or prune the system objectives or he or she may try to overcome some of the restrictions.
This exercise is also a basic part of feasibility analysis at a general level.

The systems objectives are transformed into specific information needs of the organisation or, for
that matter, of the manager users. A clear understanding and aggregative view of management’s
information needs is the base on which the whole design is erected. Special efforts are needed for
assessment of organisation as well as user manager’s information needs. So, information needs
which can really help the management in discharge of their functions are identified. An easy way
to judge the feasibility of a system is to ask a few questions, like:
a) Is the proposed system worth developing?

179
b) Will the proposed system contribute by way of improved efficiency, productivity or
organisational effectiveness?
c) Will the system improve information availability and be cost-effective?
d) What will be the system development costs and will these be justifiable?
e) How will the user departments take this system and what will be the overall impact of this
system on the organisation?

The key considerations involved in the feasibility analysis are:

• Economic,
• Technical, and
• Behavioural

As discussed earlier, the economic feasibility will only consider the cost/ benefit analysis of the
proposed project. The benefits are always expected to be overweighing the costs.

The technical feasibility always focuses on the existing computer hardware and software. This
also includes the need for more hardware or software and the possibility of procuring/installing/
maintaining such facility.

The behavioural feasibility includes a study of the organisational behaviour. An estimate of how
strong the user reaction will be to the new system will have to be made at this stage.

The final output of this step is a Feasibility Report having discussions on Financial Feasibility,
Economic Viability, Technical Feasibility and Social Acceptability of the proposed system.
Feasibility study is a part of Systems Analysis. Experience has shown that delaying or neglecting
feasibility study is one of the major reasons for the failure of a CBIS.

12.4.2 System Analysis

Systems Analysis is the next stage in the life cycle of a CBIS. The system analysis includes
review of the existing procedures and information flow. Decision-making and individual
information needs at various levels in different functional areas are also reviewed. The system
analysis phase primarily focuses on isolation of deficiencies from the existing system.

The fundamental activities involved in the system analysis are:

• Definition of the overall system,
• Separation of the system into smaller and manageable parts, and
• Understanding the nature, functions and interrelationships of various subsystems.

The analysis of the information systems could be done with the help of various tools of system
analysis. Some of the tools which are available with the system analysts are:

i) Review of Documentation: Documentation on the existing system could be reviewed and

analysed to study the objectives, reports, procedures being followed and equipment being
used. The only limitation with this technique is that the documentation on any existing system
is never complete and up-to-date.

180
ii) Observation of the Situation: The system under study can always be observed by getting
involved in the system. The system analyst can work in the system or can be a mere observer.
The exercise is time consuming and costly. Also it has an inherent limitation of the fact that
the analyst may never be able to observe the intricacies of the system.

iii) Conducting Interviews: The system analyst can conduct interviews with the user managers
and ask questions related to their job responsibilities. The interviews could be formal or
informal ones and may span over a period of time. The limitation of this tool is that the user
manager may not be able to explain the problem in detail.

iv) Questionnaire Administration: A printed structured or unstructured questionnaire may be

administered to find out the information needs of individual managers. The questionnaire
survey does help in saving time as compared to interviews as well as gets more committed
data, but it is impossible to design an exhaustive questionnaire to cover various aspects of the
system under study.

The analysts use a combination of all these tools to analyse an existing system. The analysis
phase is a time consuming phase and yet a very crucial phase. In brief the steps involve the
following:
• understanding the organisation to identify the flow of information between different levels in
the organisation,
• a detailed examination of the proposed system (application area) for CBIS,
• identifying alternative approaches to meet the stated objectives on the system,
• evaluating the costs and benefits of each alternative in detail, and finally,
• choosing the ‘most appropriate’ alternative.

Systems Analysis involves teamwork and a considerable amount of time. A clearer picture of
costs and benefits of alternative approaches will emerge from a detailed study of the proposed
system. Involvement of ultimate users of CBIS is very crucial at this stage itself, so that the
acceptance of CBIS upon implementation will be relatively easy.

12.4.3 System Design (Logical)

If the system analysts phase defines the way things are, the Logical System Design phase defines
the way things should be for the same problem.

The system development phase includes mapping of the business requirements of the managers
on to the proposed system. The conceptual design for the model which has been developed in the
problem definition stage is enlarged to understand the actual flow of data and the logical model is
developed. The logical model is worked out to finally develop and test the physical system in the
system development phase.

Providing a Logical System Design for the chosen alternative involves:

• understand user requirements,
• identifying data requirements,

181
• suggesting a logical organisation of data, and

• suggesting a logical procedure to produce the desired outputs from available inputs.

It is very important that we understand the requirements of various users in the organisation.
Users at different levels in an organisation have different information requirements for decision-
making. Information requirement can be broadly classified into three groups as follows:

• monitoring and control decisions,

• planning decisions, and

• policy and strategy decisions.

Detailed discussion between designers and ultimate user is very essential to estimate users’
requirements clearly. This includes identifying report contents, frequency of reporting, formatting
of reports and presentation of reports (tabular vs. pictorial), for each user.

After estimating users’ requirements, a system designer works backwards to identify data
requirements. This includes identifying data sources, the nature and type of data that is available,
and data gaps.

The next step is to establish a processing logic to produce the desired outputs from the available
inputs. This step involves a data flow analysis and a data processing analysis. Data flow
analysis helps us to arrive at a logical organisation of data into computer files. A file is a
collection of similar records, each record has a number of data items (fields) of information of a
particular entity. For example, a payroll file will contain many payroll records, each record
carrying the necessary data items (fields) of information of an employee, like name, designation,
basic salary, etc.

A logical representation of data flow analysis and data processing analysis in a CBIS can be
effectively provided through structured system design tools. These are:

a) Data Flow Diagram

A Data Flow Diagram (DFD) is a graphical representation to depict the flow of data in a CBIS. It
should be realised that a DFD provides only a logical data flow and not a physical data flow.

A logical data flow in a CBIS can be explained as follows: Data originates from a Source,
undergoes some Processing and terminates in a Sink. The processing step may require data
stored elsewhere in Data Stores, over and above what is supplied by the source. Similarly the
output of processing may be an intermediate data store which is used for subsequent processing.

These components of a DFD are presented graphically, using the following conventions:

• a closed square box to denote source/sink,

• an open rectangular box to denote intermediate data store,

• a circle to denote processing, and

• an arrow to denote the directional flow of data.

182
For example, consider the case of a ‘pay roll accounting’ system, to prepare salary statements for
each employee of an organisation. Data flow for such a system can be represented as shown
below in Figure I.

SALARY
STATEMENTS
EMPLOYEE

data on
ACCOUNTS employees PAYROLL
OFFICE PROCESSING

UPDATED
UPDATED DATA DATA ON
EMPLOYEES

Figure I: A DFD for Payroll Processing

In Figure I, data on employees originates from accounts office (source), gets processed, salary
statements go to employees (sink), and updated data on employees (e.g., total tax deducted, total
contributions to provident fund, etc.) is stored in an intermediate computer file (data store) which
is needed for subsequent processing next month.

A DFD displays data flow in a top-down approach. Therefore, we start with a macro DFD and
‘explode it’ into micro DFDs. Care has to be exercised to provide clarity for each level of DFD.
Towards this, a standard practice is:
i) not to use more than one page for one DFD, and
ii) not to show more than 6 or 7 circles (processing steps) in each DFD.

Figure II illustrates this practice.

updated data updated data

on employees

salary statements
EMPLOYEES

data on gross salary on

ACCOUNTS employees Computing employees Computing
OFFICE Gross Salary 1 Net Salary 2

deductions

deductions
on various
categories

Figure II: A DFD Payroll Accounting

While exploding a DFD into lower levels, it is very essential to maintain a continuity and linkage
between a DFD and its member DFDs. This is achieved by numbering each circle (processing

183
step) by adopting the numbering system used in text books. In a text book, chapters are numbered
1, 2, 3, …, sections within a chapter have numbers as extensions of the chapter number, e.g., 1.1,
1.2, 1.3, … and sub-sections within each section numbered as 1.1.1, 1.1.2, 1.1.3, etc. Similarly
circles in DFDs are numbered as 1,2,3…, 1.1, 1.2, 1.3,…, 1.1.1, 1.1.2, 1.1.3, ….

The following Figure III illustrates this numbering convention.

PROCESSING 1 PROCESSING 2

1.1 1.2 2.1 2.2

1.1.1 1.1.2

Figure III : Numbering Convention

Such a hierarchical approach to drawing DFDs provides a clear logic for system design, a proper
documentation of processing steps and an estimate of processing requirement.

b) Data Dictionary for Data Flow Analysis

A Data Dictionary (DD) is intended to provide a complete documentation of all the elements of a
Data Flow Diagram, namely data items, data stores, and data flows. Data described in a DD
carries the following details:
Data type Data item/data store/data flow
Data name Name of data item/data store/data flow
Data aliases Alternate names used for convenience by multiple users
Data description A short description of data, explained in simple terms
Data characteristics Characteristics of each data type.
A data item is characterised by its type (numeric/ alphanumeric),
width, etc.
A data store is characterised by its composition (set of data items),
organisation (sequential, random), etc.
A data flow is characterised by its origin, destination, etc.

Below we describe the contents of a DD for a sample data item, data store and data flow for a
CBIS on payroll accounting.

i) DATA ITEM
• Data type Data item

184
 • Data name G-SALARY

• Data aliases Wages

• Data description Monthly gross salary of an employee

Data characteristics

Type Numerical

Width 7.2
4 digits for the rupee component
1 digit for the decimal point
2 digits for the paise component

Associated data stores Payroll file

Personnel file

Associated data processes Payroll file

PF accounting
Personnel information systems

ments Gross salary is based on employees designation, and hence falls within a specified range.

ii) DATA STORE

• Data type Data store

• Data name Payroll file

• Data aliases Salary file

• Data description Master file on employees for payroll accounting

Data characteristics

Composition EMP-NAME
Designation
B-salary
Department
:
G-Salary
:

Organisation Sequential file

Volume 1000 records (approximately)

Size 350 K bytes (approximately) per record

Associated data processes Payroll accounting

PF accounting

Inbound data flow

Outbound data flow

185
 Comments This file gets updated every month at the time of payroll
processing. On an average, in a large organisation, about
5 records are deleted per month ( retiring/leaving the
organisation) and about 10 records are added per month
(new appointments).

iii) DATA FLOW

• Data type Data flow

• Data name DATA ON EMPLOYEES

• Data aliases

• Data description data on employees required for payroll processing

Data characteristics

Origin Accounts office

Destination Process 1 in payroll accounting

Contents EMP-NAME
Designation
B-Salary
Department

Associated data processes Payroll accounting

Associated data stores

Comments

c) Decision Tables

A decision table displays and documents clearly the processing logic for each processing step
identified in a DFD.

A decision table has the following structure.

Combination of conditions

Condition 1 Y
Condition 2 ····
Condition 3 Y

Action 1
Action 2 Y ····

This table is to be read from top to bottom, one column at a time. For example, interpret column 1
as follows: If conditions 1 and 3 are satisfied, then take action 2.

186
For illustration, consider an ‘accounts receivable’ application in ABC Corporation. Customers are
prioritised based on how much they owe to ABC Corporation and for what length of time. The
following procedure is used to classify customers into A, B, C categories. A customer is a A type
customer if the amount due from him is not for more than one month. A customer is a C type
customer if he owes at least Rs.6,000 for a period exceeding 2 months or if he owes less than
Rs.6,000 for a period exceeding 3 months. All other customers are classified as B type customers.

This logic can be represented in a decision table as shown below:

C
o Period due: less than 1 month Y Y
n 1-2 months Y Y
d 2-3 months Y Y
i more than 3 months Y Y
t Amount due: less than Rs.6,000 Y Y Y Y
i At least Rs.6,000 Y Y Y Y
o
n
s
A
c Actions: Type A Customer Y Y
t Type B Customer Y Y Y
i Type C Customer Y Y Y
o
n
s

d) Decision Trees

A decision tree is another way to document processing logic, specially when the number of
alternatives is not too many.

Combination of conditions are represented along the branches of a decision tree. The outcome of
each of these combinations is given at the end of the final branch. For illustration, the processing
logic followed by ABC Corporation for prioritising its customers (mentioned in section 4) can be
explained in a decision tree as follows (Figure IV):
Customer

Period due less than 1 month Type A

Period due 1-2 months Type B

Amount less than Rs.6000/- Type B

Period due 2-3 months

Amount at least Rs.6000/- Type C

Period due more than 3 months Type C

Figure IV : Decision Tree

187
e) Structured English for Data Processing Analysis

Processing logic can also be explained clearly in a structural English language. For illustration,
the processing logic for ABC Corporation can be explained as follows:

IF period due is less than 1 month, then customer = A Type.

ELSE
IF period due is less than 2 months, then customer = B Type
ELSE
IF period due is less than 3 months, then
IF amount due is less than Rs.6000 then the customer = B Type.
ELSE Customer = C Type.
ELSE Customer = C Type.

Structured English statements should be properly indented and aligned for readability. It is also
advisable to avoid long statements; if necessary break up a long statement into many short
statements.

Programming, the processing logic in a higher level language, is very easy if the logic already
explained in structured English. Structured programming languages like PASCAL are based on
structured English statements.

These tools are highly recommended to present a well documented and self explained logical
system design.

12.4.4 System Design (Physical)

While a logical design provides an estimate of processing requirements, a physical design

involves mapping the logical design onto the physical hardware of a computer system. Upgrading
the existing hardware and/or acquiring a new computer system if required to meet the processing
requirements is also undertaken at this stage.

The system analysts assign specific responsibilities to the programmers who develop and test the
progranmmes. The development and testing of the systems take place in a phased manner:
• Development and testing of the individual programmes,
• Development and testing of the individual programmes as a part of the system modules,
• Development and testing of the system modules as a part of the major subsystems, and
• Development and testing of the major subsystems as a part of the proposed system.

The development of the system includes writing of the actual programmes to handle data.

Subsequently, file organisation details are worked out and appropriate file organisation methods
established for processing and storing data. File organisation methods can be broadly classified
into two types – serial access organisation and random access organisation.

Excellent programming skills and experience are required for this phase of the system. The basic
activities involved in this phase are:
• Checking of the programme specifications received from the system development stage and
expanding these specifications,

188
• Breaking the system modules into smaller programmes and allocating these programmes to
the members of the system development team,
• Producing the programme code in the chosen computer programming language,
• Defining the interfaces between various programmes and designing tests for checking their
interfaces,
• Ensuring the data availability for individual and integragted testing,
• Checking the quality of the code and its adherence to the established standards,
• Prepare the documentation for each one of the programmes,
• Receiving the user data for acceptance testing, and
• Getting the user sing-off after the acceptance testing

For development of the proposed system, it is important that all possible support should be
provided to the development team. This support includes availability of:
• Office Space,
• Relevant Data,
• Secretarial Assistance, and
• Access to key functionaries throughout the system development effort.

The final output of this phase is a fully developed and tested software system along with complete
documentation and testing results.

12.4.5 Implementation
Once the system has been declared fully developed and tested by the development team, it is
ready for implementation. Actual programming is undertaken at this stage to implement the
proposed CBIS in the available hardware. The involvement of the user is necessary throughout
the project duration, but the user involvement is critical during this phase.

The implementation includes the following activities:

• Programme development and planning for implementation,
• Preparing the schedule for implementation,
• Procurement of hardware,
• Installation of software,
• Operation and testing of software on hardware,
• Getting acceptance of the CBIS from its users,
• Recruitment of operating personnel,
• Motivation and training of the selected personnel and users,
• Preparing user manual and documentations,
• Conversion of data files from old system,
• Final changeover, and
• Operation and production.

189
Once the system has been implemented, the systems group provides outside support to the user
group and trains the user group to handle production and operations of the system.

This is the most time consuming activity in the life cycle of a CBIS; and is also the costliest
activity. Systems Analysts have a tendency to lose interest once all the programmes are
developed and tested to their own satisfaction, and not necessarily to the satisfaction of the users.
This tendency is dangerous and should be avoided at all cost. It is the responsibility of systems
analysts to properly document their programmes, prepare user manuals, provide user training and
getting acceptance for the CBIS from its users.

12.4.6 Maintenance
Though the system is thoroughly tested before the implementation, yet the system is never
foolproof and errors always continue to exist. Therefore, there is a need to have a systems person
to look after the system and maintain it even during the operation and production.

As users develop faith in a CBIS, their demands on the system will grow. The system design
should be flexible enough to accommodate future requests, refinements, modifications, and
changes to suit users’ requirements. Well documented logical and physical designs of a CBIS will
facilitate its maintenance considerably.

The system maintenance could be because of any of the following reasons:

• Minor changes in the processing logic,
• Errors detected during the processing,
• Revision of the formats of the reports, and
• Revision of the formats for data inputs.

Also the management is keen to know the quality of the system developed and the standards
which have been followed. There is usually a review team which evaluates the implemented
systems and suggests changes, if required. It also leads to integrated and standardised system
development.

Table–1 summarises the various activities in the development of a CBIS.

Table 1: System Life Cycle

Stage Description
Objectives Broad statement of objectives
Feasibility Rough cost/benefit analysis
System Analysis Evaluating alternatives and choosing the most appropriate
alternative to meet the objectives
Systems Design (Logical) A broad logical design using structured tools like DFD (Data
Flow Diagram involved in Data Flow Analysis), Data
Dictionary, Decision Tree, Decision Table, Structured
English, etc. and arrive at system requirements
System Design (Physical) Detailed system design, taking into account available and
proposed hardware – use of system flow chart
Implementation Programming, implementing and user documentations
Maintenance Modifications and revision for user needs.

190
Check Your Progress – 2

1) Explain why System Analysis is important.

………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...

2) What do you understand by System Design (Logical)? Describe the System Design (Logical)
stage in the life cycle of a CBIS.
………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...
………………………………………………………………………………………………...

12.5 LET US SUM UP

In this Unit, you have been introduced to the three types of systems: (1) Natural or man-made; (2)
closed or open; and (3) conceptual or physical. We have explained in detail the open; physical
man made system such as CBIS. After examining the ‘why’ and ‘what’ of system analysis, it was
seen that analysis of the system involves identification, understanding and critically examining
the system, and its set for the system as a whole, through suitable modification of its
components.

Every system either developed as an improvement over the existing system or developed for the
first time has to undergo various identifiable stages. The Unit has discussed these stages as
objective, feasibility study, system analysis, system design (logical), system design (physical),
implementation and maintenance of CBIS. The birth of system takes place when the conceptual
model is developed by way of expressing a need. This need is converted into a logic for fulfilling
of this need. It ultimately gets converted into data files, programmes and documentation at the
stage of physical mode. The total development cycle needs more than one full-time individual.
Generally a project team consists of members from user group as well as systems group.

12.6 CLUES TO ANSWERS

Check Your Progress – 1

1) A system is an organised, interacting, interdependent and integrated set of components/

variables/parts. A system has objectives or goals. Three classification of system are:
i) Natural or man-made,
ii) Closed or open, and
iii) Conceptual or physical

Read Sec. 12.1 and 12.2 to expand the above answer.

191
2) The information systems are considered to be evolved through three different levels of
systems. These are:
i) Conceptual System,
ii) Logical System, and
iii) Physical System.

Read carefully Sec. 12.2 and answer.

Check Your Progress – 2

1) The understanding of what system analysis is, itself provides an insight into its importance
and why it is needed. System Analysis specifically:
i) offers a means to greater understanding of the complex structures,
ii) is a means to trade off between functional requirements of a subsystem (component) and
its immediately related subsystems, and
iii) helps in understanding and comparing functional impacts of subsystems to the total
system.

Read Sec. 12.3 to answer it better.

2) The Logical System Design is a phase in CBIS which defines the way things should be for a
given problem or situation.

Study carefully Sub-sec. 12.4.3 and answer.

192