CH 01

CHAPTER 1
SYSTEM ANALYSIS AND DESIGN
Learning Objectives:
• Concept and definition of ‘System’; elements of System.
• Interaction between a system and its environment; types of system. System as a value
addition process. Quality aspects of a system.
• ‘Systems Approach’ to problem solving, its applications and personal factors involved in
it.
• Grasping the concept of ‘System life cycle’, to realize the need of structured system
development.
• Different tools and techniques of SDLC and their application.
1.0 System Study
1.1 Introduction
We live on the planet Earth, which is a part of the larger system known as the solar system. Earth has several
independent and interacting systems, such as: Weather system, Life system, etc. The creation, continuation,
maintenance and destruction of these systems are taken care of by this planet, naturally. These systems are called
‘Natural systems’.
The life system of Earth has several species. Humans are one of these several species (or subsystems of life
system). Like other species, humans also need food to survive. Food comes from food cycle or ‘Food system’
(which is itself a part of the life system).
Apart from natural systems, there are other systems also. Necessity has led to the invention and continuation of
these systems. The creation, continuation, maintenance and re-structuring/destruction of these systems are taken
care of artificially, i.e., only by human involvement and hence known as ‘artificial system’ or ‘man-made system’.
Artificial system includes: education system, water supply system, electric supply system, health system (doctor,
nursing homes, medicines, etc.), communication system, transport system, Government system, etc. Artificial
systems attempts to continuously produce consistent results. The results are so consistent that the presence of such
systems are even forgotten, until and unless these systems fail to produce desired results — for example, water
supply system, electricity supply system, etc.
.2 MANAGEMENT INFORMATION SYSTEMS IN MODERN BUSINESS
In our day to day life, we come across several systems (natural and/or artificial). Business organizations also are
examples of a system. In a business organization, there are several divisions, functions or departments that are
subsystems of the main business system. Each of these subsystems is complex and in turn has component modules
or subsystems. Marketing, manufacturing materials, finance are some examples of component modules of a
business system. The modules or subsystems that are present in a business system would be governed by the nature
of business, the type of operations, and the environment in which the business operates and so on.
Hence we observe that, irrespective of natural or artificial, every ‘system’ has certain common identifiable features
and common working procedures. Necessity determines the need for a system, the continuance/discontinuance of a
system and its relevant updating and other requirements.
This chapter is dedicated to the study of what a ‘system’ is, in general terms; steps involved in analysing, designing,
implementing, maintaining of artificial system; and related topics.
1.2 Definition of ‘System’

In absence of a standard definition of system, let us observe a few definitions of systems to conclude upon its
characteristic features.
 “A system is a group of at least two inter-related and interacting components forming a
unified whole, working together to achieve a common goal by accepting inputs to produce
outputs in organized transformation.”
 “System is an orderly arrangement of a set of inter-related and integrated components or

elements that collectively operate to accomplish a common goal.”
 “A set of interacting elements responding to inputs to produce outputs.”
 “System is an ‘organised or complex whole’ and ‘organised complexity’.” — Bertanalaffy

(theorist).
Thus, we observe that:

(i) One system consists of more than one part, known as component or element or module.
(ii) A system is an ‘organised complexity’ — i.e., each individual component with its individual objective and
procedures, works independently as well as interactively in harmony and synchronisation (that is to say, as
a unified whole), such that the objective of the main system can be achieved by combined effort.
(iii) A system may be a part of a larger system and at the same time may have its own sub-systems — i.e. a
system is a ‘complex whole’
(iv) Each system has a model or an abstraction, which states the inputs, processes and outputs.
1.3 Elements of a System

Input resources flow from the input element through the transformation element to the output element to produce
the output resources as per the objectives of the system.
There is also a control mechanism. A control mechanism monitors the transformation process to ensure that the
system objectives are confined to.
Chapter .3
S u p e r S ys te m
IN P U T P R O CE SS O U TP U T
feed b a ck &
co n tr o l m ech a n is m
S y s te m
e n v ir o n m e n t
Fig. 1.1 — Elements of a System

The control mechanism is connected to the resource flow by means of a feedback loop. The feedback loop obtains
information from the system output and makes it available to the control mechanism which compares these signals
with the system objective and takes appropriate actions whenever necessary.
1.4 System Environment

Environment may be defined as “everything that isn’t me” or “every thing that surrounds the object under review”.
System environment is “the collection of elements which surrounds the system, which may interact with it”.
Thus, system environment is outside the system, of which the system under study, is a part. The environment of a
system may consist of people, organization and other systems/sub-systems from which the system under study
receives inputs, derives process to convert these inputs to outputs and provides output.
Not only the environment of a system varies from system to system and time to time, systems also always don’t
interact with the environment in the same manner.
During the design phase of a artificial system, there is control over the system, but little or no control over the
system’s environment. A feedback loop is connected to the control mechanism of a system in order to monitor and
control the workings of the system being developed. Accordingly, the control system must be able to absorb the
feedback in the shortest time and keep the system stable and proper.
It is clear that a system can be monitored and controlled, but the environment of the system cannot be controlled.
Question may arise as to whether the environment of a system remains static or it is dynamic. In fact, the
environment consists of elements and systems which are outside the system under review. Since the system under
review interacts with the environment, it has some influence on the environment — howsoever significant or
ignorant it may be. Similar is the case for other systems/components of the environment. Hence the environment of
a system is dynamic and the rate of dynamism depends on the influence of the systems/components of that
environment.
1.5 System Boundary

‘System boundary’ is expressed in terms of constraints that separate the system from its environment”.
All systems have to have a boundary, which depicts the scope of activities. The system is within the boundary and
the environment is outside the boundary.
The system analyst defines the boundary of a system to suit the purposes of a particular study.
Sub-systems are part of a larger system. Each system is composed of sub-systems which in turn are made up of
other sub-systems; each sub-system being delineated by its boundaries. Thus, we get the concept of system as an
‘organised whole’ and ‘organised complexity’, as has been stated by Theorist Bertanalffy, earlier.
1.6 System Interface

The interconnections for interactions between systems/sub-systems are termed as ‘System interfaces’. System
interfaces occur at the system boundary and takes the form of inputs and outputs, in which the system
analyst/designer has almost complete control.
Thus, system interface represents the flow of data from one sub-system to the other.
n( n − 1)
The maximum number of interfaces within one system with a given number of sub-systems is:
2
As the number of interfaces goes on increasing, it creates additional problem during system integration (i.e.
combination/assimilation of systems to function as one whole). The objective must be to have minimum number of
interfaces. This can be achieved with the help of creating functional data base. One data base helps us to combine
all the related data at one common place which can be simultaneously accessed by different sub-systems. It avoids
the flow of data therefore eliminate the need for system interfaces.
1.7 Sub-system
When a complex system is comprehended as a whole, it becomes very difficult and cumbersome and hence,
decomposition becomes extremely essential.
‘Sub-system’ is a part of a larger system. The system is factored into sub-systems, so that sum of sub-systems
constitutes the entire system.
A system is broken or decomposed into sub-system(s), in order to help analyse an existing system; design and
implement the new system.
This process of decomposition is continued within the sub-system until the smallest sub-systems are of manageable
size.
‘Supra-system’ refers to the entity formed by a system and other equivalent systems with which it interacts.
Illustration: A town’s Government is a system, but it is also a part of a larger system: the Government of State or
Province. The State or Provincial Government is a super system of the town Government and is also a sub-system of the
National Government. The National Government and State/Provincial Government is the supra system for the town’s
Government.
Sub-system performs specialised tasks related to the overall objectives of the total system. Some of the Sub-
systems can be differentiated from each other by:
(i) Function (e.g. – production, sales, purchase, etc.)
(ii) Space (e.g. – region, geographical locations, etc.)
(iii) Time (e.g. – 1st, 2nd, 3rd, etc.)
(iv) Formality (e.g. – relationship amongst each other, etc.)
(v) People (e.g. – Top/Middle/Lower level, etc.)
Chapter .5
Illustration:
F e e d b a c k & C o n tr o l M e c h a n i s m
In p u t s O u tp u ts
S a le s
B u s ine s s F ina n cial

S ystem M a r k e t in g P r o d u c tio n S ystem
F in a n c ia l
A c c o u n ti n g
P e rso n n e l A c c o u n ts
F in a n c ia l
M anagem ent
in - h o u s e
Tr
R e c r u itm e n t T r a in i n g a
P ersonnel S y in in
o u ts i d e o th e r s ste g
S ystem m
P e rform a nc e
P la c e m e n t
e v a lu a ti o n
Legen ds:
E lem en t/M o d u le/C o m p o n en t
S y s t e m I n t e r fa c e s
» e v e ry th in g o u ts id e s y s te m b o u n d a ry is s y s te m e n v iro n m e n t
» b ig g e r s y s te m is S u p ra S y s te m
Fig. 1.2 — Components, interfaces, boundaries of a system and its sub-systems.
1.8 Categories of Systems

Two broad categories of systems are —
(i) Natural Systems: Systems developed, implemented and maintained by nature. Humans are part of natural
systems. Examples: Solar System, Weather System, Life cycle, etc.
(ii) Artificial (or Man-made) Systems: Systems defined, designed, implemented and maintained by human
efforts and knowledge, where nature may or may not play any part. Examples: Education System, Transport
System, Communication System, Government & Administration System, etc.
1.9 Types of Systems

SYSTEM S
a cco r d in g to elem en ts : a cco r d in g to in ter a ctive b eh a vio u r : a cco r d in g to o u tp u t/w o rkin g :

A b str a c t S yste m O p e n Sy ste m D e t e r m in is t ic S y s t e m
P h y s ic a l S y s t e m C lo s e S y s t e m P r o b a b ilis t ic S y s t e m
Fig. 1.3 —Types of Systems

Following are the types of systems:
1. According to elements:
(i) Abstract System: an orderly arrangement of interdependent ideas or constructs, also known as
‘conceptual System’ (e.g.: religion, superstition, etc.).
(ii) Physical System: a set of tangible elements which operate together to accomplish an objective (e.g.
transport system, production system, etc.)
2. According to interactive behaviour:
(i) Open System: actively interact with other systems and establish exchange relationship.
(ii) Close System: does not interact with outside environment and is self-contained and independent, are of
two types – fully closed (e.g. clock, etc.), relatively closed (e.g. Inland security policy, Examinations
department of an education University, etc.).
3. According to output working:
(i) Deterministic System: Operates in a predictable manner, where there is certainty of operation among
the parts (e.g. correct computer program which performs exactly according to a set of instructions).
(ii) Probabilistic System: Systems that can be described in terms of probable behaviour, having a certain
degree of error attached to the working of the system (e.g. sales system, inventory system, etc.)
1.10 System — a ‘value-addition’ process

The inner workings of a system or sub-system are organised to produce required outputs from available inputs.
There may be constraints or lacking of inputs — even then, inputs are always more than output obtained because of
process loss, etc.
However, in the process of conversion of inputs to outputs, some value or utility is being added to the inputs by the
system processed. Although outputs may be lesser than inputs, they have more utility than the inputs. In other
words: Outputs are obtained by processing inputs at an incurred expenditure, yet they have higher value than the
inputs.
Hence, a system can be viewed as a value addition process.
1.11 Quality aspects of a System

The output of a sub-system or a system (may) become the inputs for the next. These outputs have to adhere to
certain standards in order to be acceptable to the next. Here comes the concept of quality.
Quality is the performance and functional specification of the system.
Quality differs from quality assurance. Quality assurance is the process for ensuring the achievement of
performance and functional specifications (i.e. assurance for achieving quality).
Quality Control is a control mechanism concerned with controlling the quality aspect of the system.
Chapter .7
2.0 Systems Approach

‘Problem’ is the cause of the trouble, or the cause of the opportunity.
‘Symptoms’ are conditions produced by the problem.
The term ‘problem solving’ brings to mind the correction of things that are going wrong.
Managers quickly respond to influences seeking to prevent or minimize damage. Further, they also respond to
things that are going better than expected. During the course of problem solving, managers are involved in the
process of decision making, in presence of several problem-solving elements. The problem structure influences
how problems are solved and gradually in the problem solving process, the manager becomes careful to distinguish
symptoms from cause.
The systematic approach to problem solving is known as Systems Approach:
“Systems Approach is a series of problem-solving steps that ensure that the problem is first
understood, alternative solutions are considered and finally the selected solution works.”
‘Decision’ is a selection of strategy or action.
‘Decision making’ is the act of selecting the strategy or action that the manager believes will offer the best solution
to the problem.
Problems are of three types –
 Structured problem are of ‘if-then’ nature – i.e., they have a cause-effect relationship and a proper
format. Structured Problems require Structured Decision Making. Structured decisions making follows
pre-determined set of rules and the outcomes of such decision-making have maximum certainty and
stability. These decisions are often repetitive and routine in nature. The choice phase of structured
decision making follows the conditions and rules for actions. Due to the repetitive action-condition based
nature of decision making, Computers may alone solve structured problems by pre-written human
instructions (in machine language), where managers have little or no role to play. Structured decision-
making are mostly required at the lower level (operational level), which keeps on decreasing until at the
top level, where there is least structured decision making.
 Unstructured problems. Situations arise where predetermined reactions to situations can not be
predicted. Such decisions cannot be made purely on pre-determined rules because the situation for which
rules are to be framed, are unknown or unpredictable. These types of problems are known as unstructured
problems and associated decision-making is known as Unstructured Decision making. Unstructured
decision making are complex in nature. Further more, the risks involved are maximum. Such decision
making are mainly used by Top management, and keeps on decreasing with the level of management.
Unstructured problems must be solved by managers (i.e., human tact, knowledge and expertise), with
computer support.
 Semi-structured problems. With structured problems on one extreme and unstructured problem on
another extreme, in between the two are semi-structured problems. Such problems are partly structured
and partly unstructured. Semi-structured problems required Semi-structure decision making. Managers
and Computers may solve semi-structured problems by working together.
There are two types of measures: proactive measure (measure taken before happening) and reactive measure
(activities following as an effect of something that has already happened).
2.1 Personal factors influencing problem solving

The problem-solving style differs from manager to manager, which influences problem sensing, information
gathering and information using, discussed below.
2.1.1 Problem sensing

Managers have to become aware of the problem. He has to ‘sense’ the problem. There are three categories of
problem sensing:
Styles Attitude Problem-Sensing technique used
Problem avoider Assumes everything to be Attempts to block out possibility of problem by ignoring
fine. or bypassing information regarding problems
Problem solver Solves problems when Neither blocks-out nor avoids problems, but solved
they arise. problems whenever they arise.
Problem seeker Enjoys solving problems. Seeks to find out problems, in order to solve them.
2.1.2 Information gathering

The next step to problem sensing is developing of alternatives for decision making. Managers can exhibit one of the
following two attitudes towards the total volume of information available to them, which is known as Information
gathering.
Styles Attitude towards total volume of information
Perceptive Style Manager screens out everything that is not relative to the area interest.
Receptive Style Individual information is reviewed and evaluated to see as to whether it suits
the area of interest, or it suits the area of interest of some one else in the
organization.
2.1.3 Information using

Relevant information gathered needs to be put into actual use in order to solve problems.
Information using styles Attitude towards using information
Systematic Style Manager pays particular attention to follow a prescribed method of problem
solving, such as the systems approach.
Intuitive Style Manager does not favour any certain method or style, but tailors the approach
to the situation.
3.0 System Development

Systems development refers to all the activities used to create an (artificial) system, along with its processes to
accomplish proper functioning.
There is no one best way to develop a system. Needs, situations and organisations differ for such universal
solutions.
3.1 The Process of System Development

The process of system development includes steps requiring objective-setting, analysis, designing, implementation,
maintaining and evaluation of a system in order to provide a total solution (now and later).
Up to 1980s, systems were being analysed and designed on an adhoc basis (now termed as ‘Traditional approach’).
It was considered to be more of an art than a science. The team leader undertaking the job used to have its
individual style of working, which varied from one person to another person, even for the same situation. The team
manager used to study the current physical system with its associated problems/requirements in order to begin the
system development process.
Chapter .9
In the conventional method, there were no tools (like data-flow diagram, decision tables, etc.). It was difficult for
the systems analyst to convey the thoughts to users on one hand and development team on the other. This often
resulted in long essay type description of procedures. It was a cumbersome process to write down the description
and reading and understanding also was difficult. Description also required complex computer terminology, which
was difficult for users to understand. Individual styles of describing the procedures were used. The users of the
systems, after going through the procedures described on several sheets of paper could not (or had difficulty) in
visualising the conceptual model of the system and its elements/interfaces/sub-systems, etc. Systems that were
designed through the conventional method were often observed to pose difficulty in maintenance. In order to
incorporate a change in the system, considerable time, effort and patience was extremely essential to understand the
system architecture.
The desire to overcome these major problems posed by conventional approach resulted in the structured approach,
which was a gift of 1980s. It uses different tools to analyse, design, develop, document and maintain the system.
3.2 System Life Cycle (SLC)

The concept of a life cycle fits anything that originates, matures over time and eventually dies. Irrespective of the
category or type of a system, each and every system has a life cycle or a rhythm (viz. birth or origin, growth or
development, maturity or climax and death or collapse).
3.3 Participants in the systems development process

3.3.1 Project manager
A project is a collection of linked activities with a clearly defined start and finish point, carried out in an organised
manner, to achieve some specific result.
The project manager has overall responsibility for managing a project to ensure that it is delivered to specification,
on time and to budget.
The project manager should possess certain skills, as:
 Leadership
 Technological understanding
 Evaluation and decision-making
 People management
 Systems design and maintenance
 Planning and control
 Financial awareness
 Procurement
 Communication
 Negotiation
 Contractual skills
 Legal awareness
3.3.2 User involvement

Greater the involvement of users in the system development process, greater will be the effectiveness of the system.
Again, if a new system is used wrongly, it is because the users do not understand it; if it is used partly, then the
system has faults which the users are avoiding. Therefore, users are the nucleus of a system, be it in the
development stage, or be it in the usage stage.
Users can provide information on both current systems and on new system requirements. Users can also provide
on-going feedback on proposed designs and systems solutions. Selected users may also be involved in the testing
and implementation stages of a new system.
Most people avoid change and only a handful welcomes it. Some people think that if change takes place, their
existence may be in danger — they fear change. Some people think that change will kill the good which is in the
current system — they protest change. Some people find that they have to upgrade themselves — they resist
change; and so on. Thus, change management is to be done, such that, people will understand and believe that
change has to take place for their own good as well as for others’ good and that they will perish if there is no
change — as a result, almost all will accept, welcome and favour change (except a few, who will never change!).
When the users are welcoming change, they have to feel the need and requirements of a new system. Users must
trust the systems analyst and must be confident in the analyst’s ability and willingness to put their ideas into
practice. On the other hand, the system analyst must trust the users, being willing to accept the users’ ideas.
All these will help the analyst and the user to have a common perception or view of what they are trying to achieve.
3.3.3 System Analysts

Systems analysts are responsible for determining how an existing system operates, together with capturing
information on new system requirements. A wide range of fact-finding techniques can be used here. Analysts will
then consolidate this information into a requirement specification, which details the functionality and performance
required from the new system. These documents will then be used as the framework to guide subsequent
development of the system. Systems analysts also play an important role in the testing and implementation stages of
a project.
System analyst must possess various skills to effectively carry out the job, specifically interpersonal skills and
technical skills.
Interpersonal skills deal with relationships and the interface of the analyst with people in business is useful in
establishing trust, resolving conflict and communicating information. The interpersonal skills relevant to system
work include the following:
1. Communication: ability to articulate and speak the language of the users. Communication is not just
reports, telephone conversations and interview. It is people talking, listening, feeling and reaching to one
another, their experience and reactions.
2. Understanding: identifying problems and assessing their consequence.
3. Teaching: educating people in use of the system, selling the system to the user and giving support when
needed.
4. Selling: Selling or promoting (innovative) solutions to the problems.
Technical skills include:
1. Creativity: Uniqueness and inventiveness in problem solving approach.
2. Problem solving: Reducing problems to their elemental levels for analysis, developing alternate solutions
to a given problem
3. Project management: Scheduling, managing costs and expenditures.
4. Dynamic interface: Blending technical and non-technical considerations in functional specifications and
general design.
Chapter .11
3.3.4 Data analyst

Data analysts can be employed to refine and expand the requirements specification produced by systems analysts.
Typical tasks of data analyst includes detailed analysis of data to be included in the new system, leading to design
of file and database structures. Data analysts also help to refine understanding of processes carried out on data in a
system.
3.3.5 Programmer
Programmers are responsible for writing the computer code that converts the requirements and design
specifications into a working piece of software.
3.4 Approaches to System Development

Effective development of complex systems cannot be undertaken in ad-hoc manner. In order to meet design
specifications in an effective and efficient way, development should be guided by some form of methodology.
Various SDLC methodologies have been developed to guide structured system development. These include — The
Waterfall model, Rapid Application Development (RAD), Joint Application Development (JAD), the Fountain
model, the Spiral model, etc. Mostly, several models are combined into some sort of hybrid methodology, to
assimilate the advantages of each as well as eradicate disadvantages of each, to the extent possible.
Documentation is crucial regardless of the type of model chosen or derived, for any project. Documentation is
usually done simultaneously with the development process. Some methods work better for specific types of
projects, but in the final analysis, the most important factor for the success of a project may be how closely
particular plan was followed.
A brief understanding about few of the various system development models currently in use is necessary to
observe the process of developing systems.
3.4.1 System Development life cycle

It consists of a linear approach with six stages. This approach is dealt in detail § 4.0.
3.4.2 Waterfall approach

The waterfall model of systems development was published in 1970 by W. Royee. This model consists of eight
sequential stages. Each stage is interlinked, as the output from one stage is input to the subsequent stage and thus,
one stage must be complete before moving on to the next stage. Each stage is divided into two parts. The first part
covers the actual work to be done and the second part covers the validation or verification procedures of the work
done in the first part. This approach helps implementation of quality and is clear and easy to understand. However,
estimating time and costs are difficult for each stage.
3.4.3 Prototype approach

A small version of a part or the whole system is designed to behave exactly similar to the real system and built
quickly at a lower cost, with the intention of modifying or replacing it with the full scale system. Prototype
approach is under situation where there is high degree of uncertainty regarding definition of input.
3.4.4 End-user development approach

In this approach, the user identifies problems that need to be solved, and decides what system would be used to
solve these problems; determines the procedures that the system must follow to solve the problems, customises the
system for the solution procedures and uses the customised system to determine the solutions to the problems.
3.4.5 Spiral Model

This model encompasses the best features of both classical life cycle as well as the prototyping model with an
added on feature of risk analysis.
3.4.6 Fourth Generation Techniques (4GT)

This technique encompasses an array of software development tools that enables the developer to specify some
characteristics of the system at a high level. The tools then automatically generate the code for the specifications.
The emphasis in this model is to use a specification technique that is close to natural language. Despite of providing
a very quick way towards developing systems, the success of this technique is limited by the capacity of available
Fourth-Generation Languages. This approach has proved to be more useful for small and medium sized projects.
3.4.7 Hybrid Approach

The approaches discussed so far (viz. 1 to 6 above), are used as an supplementary rather than complementary
approaches to system development. In some cases, however, these approaches need to be and can be combined to
get the strength of each one into a single project. Any one of the approaches can serve as the base into which others
are integrated.
3.4.8 Top-down approach

Top-down approach assures a high degree of top management involvement in the planning process and focuses on
organisational goals, objectives and strategies. According to this approach, the organisational goal should be the
driving force behind the development of all the computer systems. Here, information requirement to support top-
management are considered first. The processing of this information requires as inputs the information needed by
middle management, and so on, until basic transaction data is eventually incorporated into the design.
3.4.9 Bottom-up approach

Bottom-up approach first satisfies transactions processing requirements, then summarizes that data for reports to
first-line managers, next analyzes information in those reports for middle-management and so on until all levels are
satisfied. The information system development under top down approach is more consistent with the system
approach and is also viewed as a total system, fully integrated. The information system development under bottom
up approach is developed through an orderly process of transition, building upon transaction processing sub-
system. The system may not be integrated.
3.4.10 Object-oriented approach

Object-oriented approach involves analysing of objects that are important in the system and designing the system
based on these objects. In this approach, analysts primarily follow a top-down process in which the system
requirements are broken down into smaller and smaller pieces until specific programming modules can be defined,
programmed and put together to yield a system. Similarly, data and their inter-relationships are modelled by
analysts, and these conceptual models are turned over to a programmer who actually implements these data models
in a database management system. The main strength of this approach is that integration of data and processing
during design stage leads to higher quality systems and reuse of common modules makes development and
maintenance easier. However, the main weakness of this approach is that it is very difficult to train analysts and
programmers in this approach and its limited use of common modules.
4.0 Systems Development Life Cycle (SDLC)

In response to the growing use of computer systems, the National Computer Centre (NCC) developed a structured
approach to systems development – the Systems Development Life Cycle (SDLC). The objective was to provide a
formal structure to the development process to improve systems quality.
‘System Development Life Cycle is a logical process by which system analyst, software engineers, programmers
and also end-users build information systems and application to solve business problems and needs’.
Chapter .13
4.1 Stages in Systems Development Life Cycle

The Systems Development Life Cycle is a conceptual model used in project management that describes the stages
involved in an information system development project from an initial feasibility study through maintenance of the
completed application. An SDLC is a phased approach to analysis and design to ensure that systems are best
developed.
Every individual system passes through several phases (or stages). The time span of each phase of one system may
differ from that of other system.
1. System 2. System Analysis

planning 3. System
Design
6. System 4. System
Maintenance & 5. System Development &
Evaluation Implementation Testing
Fig. 4.4 — Different phases in a System Development Life Cycle

As we can observe, system development is done in six different stages. Each stage consists of several steps or
definite courses of actions. These courses of actions are supported by tool or method/procedure. Each stage of
system development has three things — objective of the system, steps required and the tools required to carry out
those steps.
Prior to an in-depth study of these stages of system development, we ought to note that theory differs from practice.
Theoretically these six stages have distinct identity and existence. This means that — in theory, Stage 2 is different
from stage 1 and that stage 2 cannot begin until and unless stage 1 has been completely completed and if stage 2 is
finalised, then only stage 3 can begin, and likewise. As a result, after finishing stage three, we can end up saying
that 50% of system design is complete.
In practice (i.e., real situation), these stages are not water-tight compartments, and are outcome of the circumstance
or situation under review. Thus, the organisation of stages varies. For example, one situation may involve merging
of system design and development (i.e., stage 3 and a part of stage 4, as per our above figure), whereas another
situation may call for a grouping of system definition and analysis (i.e. stage 1 and 2, as per above figure). In a
completely different situation, it may also happen that the stage 4 may be started while stage 3 is just little done
(i.e., say 10% of stage 3 is complete and stage 4 has been started); and then onwards, while stage 4 is being under
progress, stage 3 is slowly but surely built up simultaneously.
Hence we understand that interpretation and execution of stages is just for the purpose of knowledge, but during the
purpose of implementation, practical scenario takes it own deviation. Whatever may be the circumstances, the tools
used in each stage remains rigid. Suppose that there is a need to merge two stages into one (i.e. two different stages
of theoretical existence are considered and executed as one single stage during practical development). In fact, the
tools of one stage are used along with the tools of the other stage, in proper grouping, such that these tools do not
loose their individual identity during such logical combination. Hence we understand that a fragment of one tool of
one stage is not used in conjunction with a portion of another tool of that stage or some other stage. Thus, stages
can be combined or merged or split-up; but the procedures on one tool cannot be blended with that of another tool
(irrespective of the fact that the tools are in the same stage or not); thereby creating a new tool.
In § 4.1.1, etc., we are going to understand the description or objective of each stage; the steps and the mention of
tools used. Detail workings of each tool are to be studied separately in § 4.2.
4.1.1 System Planning

Description:—
System planning phase is mainly concerned with system definition and problem identification.
The need for a new system or replacement of an existing system is identified by users or as the result of a
strategic business review. A feasibility study is then carried out to explore possible system options to meet
the identified needs. If a system successfully passes the feasibility stage, the project moves into the
analysis stage.
Steps of System Planning:—
1. Recognise. The first stage is to recognise that a problem exists and to identify its symptoms. This
will involve some preliminary investigations.
2. Diagnose. Preliminary investigation should go beyond simply identifying the symptoms of a
problem to the point where the underlying cause can be identified.
3. Define. Once recognised and diagnosed the problem can then be defined. Objectives and constraints
of the proposed system can also be defined.
Tools used in System Planning:—
 Observation
 Interview
 Questionnaire
 Survey (total/sample)
 Investigation
 Record inspection
4.1.2 System Analysis

Description:—
Whilst some analysis of needs and system specification would have taken place as part of the feasibility
study, it is during this phase of the lifecycle that details of current and new system operation are gathered.
Information will be recorded in a series of dataflow diagrams and entity-relationship diagrams so that the
system can be designed.
Steps of System Analysis:—
1. Review. A review of the existing system needs to be undertaken.
2. Gather. Information on existing and proposed system functionality should be collected.
3. Measure. The performance achieved by the existing system should be measured for effectiveness.
This provides a benchmark for the new system.
Tools used in System Analysis:—
 Display tools.
 Flow chart
 Decision table
 Decision tree
 Data-flow diagram
 Entity-relationship diagram
 Simulation
Chapter .15
 Charting techniques
 Gantt chart
 PERT chart
 Cost-benefit analysis
4.1.3 System Design

Description:—
Information collected during the analysis stage can be used to produce a detailed design proposal. Design
is a translation of the requirements into ways of meeting them.
Systems design is the evaluation of alternative solutions and the specifications of a detailed solution (it is
also called physical design). System design specifies how the system will accomplish its objective. The key
to understanding the design phase is to realise that the focus is being shifted from understanding the
problem to figuring out an effective solution to the problem.
Steps of System Design:—
1. Consider. Using information collected in the analysis stage, it becomes possible to define and
consider options for the new system
2. Select. Once the alternatives have been considered then a selection must be made.
3. Design. Once the selection is made then the design of the new system can begin.
Tools used in System Design:—
 Logical Design
 Physical Design
 Printed reports
 Screen displays
 Human interaction in screen design
 Data Design
 Process Design
 Procedure Design
4.1.4 System Development and Testing

Description:—
After designing, the system has to be constructed or developed, such that the system comes into being. As
the system is developed, several components/processes/subsystems of the system under review, comes into
reality from documentation (system design).
These processes/components/subsystems are dynamic. Processes provide the transformation necessary to
change raw-data/processed-information, taken as input, into meaningful knowledge in presentable form,
which is in conformance to the specified objective. Processes are critical because different kinds of people
will have different requirements for viewing the same data. A process might be as simple as sorting and
printing a list of customer, or it might be as complex as simulating the interaction of earth’s atmospheric
systems to predict future climate.
The necessity intensifies to test these processes as to whether or not these are meeting producing effective
and useable results. Once all the processes/components have been individually tested, they should be tested
together as a system to check for their compatibility and the extent to which they meet design specification.
System development and system testing are two separate processes. Once a system has been developed,
then only can it be tested. Development and testing and re-development and re-testing continue until the
process is able to produce fruitful results. Further development of the system depends on the feedback
received from system testing. Therefore we observe that a loop exists between system development phase
and system testing phase, and this loop makes these two distinct and independent processes so relative and
dependent to each other that they become almost inseparable.
Steps of System Development and Testing:—
1. Develop. The new system must be developed either in-house or externally, depending on the option
chosen.
2. Purchase. Appropriate hardware and software resources must be procured and tested individually.
3. Test. The system should be tested to ensure that it works and that it meets the need of the users.
Tools used in System Development and Testing:—
 Programming
 Testing and debugging
4.1.5 System Implementation

Description:—
As soon as the system has been developed and tested, it is ready to use. To use the system, it has to be put
into operation. This phase is called system implementation. During system implementation phase, many
practical problems/difficulties, may arise which may not have been believed to have been existed in the
analysis or development phase. Such problems are to be eradicated before implementation or just after
implementation.
Steps of System Implementation:—
1. Document. User and technical documentation must be produced.
2. Changeover. The new system must be brought into operation.
3. Review. The system and project must be reviewed.
Tools used in System Implementation:—
 Documentation
 Training users to use and utilise the system
 System conversion
4.1.6 System Maintenance and Evaluation

Description:—
System maintenance:
System maintenance is a process of refining the system to make sure that it continues to meet business
needs. It is a continuous post-implementation process, driven by feedback received from control
mechanism or from the users.
Once a system has been implemented there should be a post completion review to assess the extent to
which the system is meeting expectations and to learn any lessons from the development process itself.
This phase is known as system evaluation phase.
Chapter .17
System evaluation:
The objective of system evaluation is to understand the extent to which the proposed benefits from the new
system, which were identified during project initiation, were actually realised from the implemented
system. System evaluation is conducted several months after the system is installed because it often takes a
while before the system can be properly assessed. System evaluation is the comparison of the anticipated
benefits against the actual benefits from the system.
System support:
The workings of System Maintenance phase and System Evaluation phase are so closely interlinked, that
sometimes these two phases are together termed as ‘Systems Support’; despite of being distinct,
independent and separate phases. Systems support is the ongoing maintenance and upkeep of a system
after it is placed into day-to-day operation. Over time, the cost of supporting an application may exceed the
cost of developing and replacement.
Steps of System Maintenance and Evaluation:—
Need for system maintenance:
1. Bugs/errors in the system; malfunctioning of the system.
2. Integration of systems.
3. Change in organisation’s strategy.
Basis of system evaluation:
1. Dependability. Probability of the system completing the job satisfactorily.
2. Capability. The ability of the system to achieve the objectives.
3. System integrity, procedural integrity and internal integrity. Reliability of the system in respect of
procedures, documentation, outputs, etc.
4. Information evaluation. Information provided by the system is evaluated to ensure that the system is
providing adequate information to meet its requirements.
Tools used in System Maintenance and Evaluation:—
 Preventive maintenance
 Rescue maintenance
 Backup/Recovery
4.2 Tools used in SDLC

SDLC tools are techniques used to simplify the work of system development. There are several tools to assist each
stage of system development. Use of relevant tool depends of the situation and the choice of the system developer.
Many tools are available in different stages of SDLC. Of these, important and most commonly used tools are
discussed below.
4.2.1 Feasibility study

A feasibility study is a brief look at the major factors that will influence the ability of the system to achieve the
desired objectives. There are six dimensions of feasibility study:
(i) Technical feasibility. Technical feasibility analyses whether the proposed system is technologically
viable, given the existing technologies.
(ii) Economic feasibility. Investigates whether the proposed system be justified based on benefits that
cannot be measured in monetary terms.
(iii) Legal and ethical feasibility. Legal feasibility investigates as to ‘Will the proposed system consider to
the laws and regulations in force’, whereas ethical feasibility considers the ethical issues in feasibility
study.
(iv) Operational feasibility. Justifies as to whether or not the system design will receive the support of the
people who will operate it.
(v) Schedule feasibility. Investigates questions such as: ‘Will it be possible to implement the system within
the imposed time constraints?’
(vi) Organisational feasibility. It involves questions such as whether the system has enough support and how
well the proposed system supports the strategic objectives of the organisation.
The system analyst gathers the necessary information primarily by interviewing key employees in the user area.
Questionnaires are also be used. The technique of observation is used in gathering information, when the source is
active and seeker is passive. Other methods such as investigation, record inspection, etc. are also in use.
4.2.2 Simulation
Simulation is a means of modelling the essence of the activity or system so that experiments can be conducted to
evaluate the systems behaviour or response over time.
Simulation involves the construction of a model which is largely mathematical in nature. It facilitates to represent
and analyse properties or behaviour of a physical or hypothetical system by the behaviour of a system model. It also
helps decision maker to solve problems that are too complex or unsuitable for ordinary mathematics. Analysts
sometimes construct a model of the real world problem and use a trial and error approach to arrive at a reasonable
solution to the problem — e.g. airplane flight, turbine, launching of missiles, etc.
With the advent of high speed digital computers, this technique has gained tremendous importance today.
Simulation provides a means of dividing the model-building job into smaller component parts and then combining
these parts in their natural order and allowing the computer to present the effect of their interaction on each other.
After constructing the model, it is activated in order to imitate the operation of the actual system, and record this
aggregate behaviour. This is repeated for the various alternative design configurations. Due to statistical error, it is
impossible to guarantee that the configuration yielding the best simulated performance is indeed the optimal one,
but it should be at least near-optimal if the simulated experiment was designed properly.
Thus, simulation usually involves the study of a dynamic system over time. In the business environment, it can be
used to examine inventory, queuing, scheduling and forecasting problems. A simulation is so designed that the
analyst can observe the behaviour of the system over time and gather useful information about it. The technique is
mainly experimental in nature in the sense that a ‘simulation run’ can be regarded as a sample in a statistical
experiment. Naturally, this gives rise to the problems of designing the simulation experiment, gathering the data on
which it is to be based in a manner compatible with proper statistical analysis and carrying on suitable tests on the
statistical significance of the simulation results. Hence it is apparent that carrying out a properly controlled
simulation is, in essence, much the same as observing the real system. In simulation, however, the operational
researcher is able to control the system rather than being controlled by it, enabling him to make experiment with the
system by altering its parameters and decision rules at will.
Chapter .19
4.2.3 External and Internal design

External design concerns the interface between users and the system. It does not only include the layout and style
of screen but also includes:
o Methods of data input
o Methods of validating data input
o Method of data output
o Format of data output
o Screen design and layout
o Screen sequences and navigation
o User dialogue with the system
Internal design does not involve users, but is concerned with the technical aspects of a system. It includes DFD
(Data Flow Diagram), Flowchart, Decision Table, Decision Tree, and other tools for structured system design.
4.2.4 Decision table

Decision tables are used as a method of recording in tabular form a decision-making process (i.e. contingencies to
be considered in the description of the problem) and the consequent actions. In other words, a decision table is a
tabular representation of the program logic.
‘Decision tables are used as a method of recording in tabular form a decision-making process and the consequent
actions’.
The decision table has four quadrants together with headings for the title and rule number (draw a thick or double
lines between the four quadrants), as below —
1. the condition stub lists all the possible conditions that may exist within the system
2. the action stub is a list of all the actions that may be taken depending upon the circumstances that may
exist
3. the condition entry section gives the various combinations of conditions that can exist in the system. Each
combination (or rule) is equivalent to a particular route through a program flowchart
4. the action entry indicates what action to take for each particular rule. It indicates what operation symbols
appear on a particular route through a program flowchart.
Example. Select the largest of three distinct numbers: P, Q, R.
Step I: Conditions involved in the problem are:
1. P > Q 3. P > R 5. Q > R
2. Q > P 4. R > P 6. R > Q
Actions involved in the problem are:
1. P is largest
2. Q is largest
3. R is largest
Step II: Conditions 1 & 3 can be combined
Conditions 2 & 5 can be combined
Conditions 4 & 6 can be combined
Therefore, there exist only three conditions:
1. P > Q 2. P > R 3. Q > R
Step III: Cx stands for xth Condition; Ry stands for yth Rule.
Number of rules = 2n conditions = 23 = 8
Rules
Select largest
R1 R2 R3 R4 R5 R6 R7 R8
Conditions
C1 P>Q Y Y Y Y N N N N
C2 P>R Y Y N N Y Y N N
C3 Q>R Y N Y N Y N Y N
A1 P is largest X X
impossible
impossible
Actions
A2 Q is largest X X
A3 R is largest X X
[Note: R3 & R6 contain impossible
combination of condition entries.]
Step IV: R1 & R2 can be combined
R3 & R4 can be combined
Rules
Select largest
R1 R2 R3 R4
Conditions
C1 P>Q Y Y N N
C2 P>R Y N — —
C3 Q>R — — Y N
A1 P is largest X
Actions
A2 Q is largest X
A3 R is largest X X
Step V: All the rules in the reduced table have one dash. Therefore,
the sum of the rules represented by rules in the reduced
table is 21+21+21 which is equal to 23 or 8. Number of
conditions is 3 and hence the number of rules to be
accounted for is 23 or 8. Therefore the reduced table is
complete.
Fig. 4.5 — A Decision Table for selecting largest of the three numbers.
Decision tables are of three types:—
1. Limited entry: a condition is phrased to provide ‘Y’ or ‘N’ answer
2. Extended entry: conditions included in the condition entry section and description of an action is given in
the actions required)
3. Mixed entry: mixture of limited and extended entry.
Chapter .21
Benefits of decision tables:—
o Analysis. Provides valuable aid to analysing a decision-making process to ensure that all possible
conditions have been explored and unnecessary conditions eliminated.
o Communication. Provides a convenient way of explaining a decision making process, even to non-
technical persons.
o Conciseness. The decision-making process is represented clearly in the minimum of space. It is sometimes
easier to see what decision is taken in particular conditions than by tracing the lines of a flowchart.
o Convenience. A decision table is easier to reproduce (e.g. using a spreadsheet) than a flowchart.
o Standardisation. Standard forms can be used for the completion of decision tables far more readily than
with flowcharts.
o Programming. Some high-level languages allow a decision table to be converted into a program. This is
possible only with limited entry tables.
o Intelligibility. The layman understands decision tables more easily than program flowcharts.
Limitations of decision tables:—
o They become cumbersome when the number of conditions and the number of rules are high.
o Not always suitable for planning programs (generally, program flowcharts are better).
4.2.5 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 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 other decision models, such as Decision Table, DFD, etc.). Structured English should not
be confused as alternative to these.
Example. Select the largest of three distinct numbers: P, Q and R.
IF P > Q
IF P > R
“P is largest”
ELSE
“R is largest”
END-IF
ELSE
IF Q > R
“Q is largest”
ELSE
“R is largest”
END-IF
END-IF
Fig. 4.6 — An example of structured English for selecting the largest of the three numbers.
4.2.6 Decision tree

‘Decision Tree is a diagram that presents conditions and actions sequentially and thus, shows which conditions are
to be considered first, which second and so on’.
Decision trees give a visual display of the possible variances in outcome, which can be analysed statistically into a
standard deviation and coefficient of variation with a view to provide management with more complete
information.
Decisions are represented as branches of a tree and for that reason it is called decision trees. 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.
A Decision trees diagram is constructed from left to right using square boxes for controllable (decision) point and
circles for uncontrollable (chance) events. Each branch leads to a pay-off (stated in numerals) on the right. Such
trees help to structure decisions in an objective way, force an explicit identification of alternatives and foster a clear
distinction between controllable and uncontrollable variables.
O u tc o m e ( s )
Y P is larg e s t
Y P > R
N R is la rg e s t
P > Q
Y Q is la rg e s t
N
Q > R
N R is la rg e s t
Fig. 4.7 A Decision Tree to select the largest of three numbers.
4.2.7 Flowchart
Flowcharts are a modelling technique introduced in the 1940s/1950s and popularised for structured development as
well as business modelling in the 1970s.
‘Flowchart is the graphical representation of the algorithm (i.e. steps to follow)’.
Flowcharts are well established process models. They have symbols for showing processes, decisions, data stores,
documents and flows. Flowcharts are typically used to describe the detailed logic of a business process or business
rule.
Types of flowcharts:—
o System Flow Charts depict the flow of data through all parts of a system with a minimum detail.
o Flow Process Charts flow process charts depict the sequence of operations by functions and individuals.
o Document Flow Charts show the movement of various forms, documents or reports from person to person or
from department to department.
o Program Flow Charts describes the specific steps and their sequence for a particular computer program.
There are a number of flow chart symbols used, of which some are as follows:
S ta rt/S to p B o x
N o D ecis io n B o x
In p u t/O u tp u t B o x
Y es
F lo w L in e
C o n n ecto r
Fig. 4.8 — Tools for drawing a flowchart.

Chapter .23
S ta rt
IN P U T
P ,Q ,R
IS
N P >Q Y
?
IS IS
N Q >R Y N P >R Y
? ?
"R l a rg e s t " "Q l a rg e s t " "R l a rg e s t " "P l a rg e s t "
E nd
Fig. 4.9 — Flowchart to select and display the largest of three numbers.
4.2.8 Data-flow diagram

‘A Dataflow diagram (DFD) is a graphical representation of how data moved through a system’.
Business process models depict the flow of data into a business process, their transformation, storage and output.
As such they contain key information for the development of an information system at both a functional and
technical level.
Dataflow diagrams (DFDs) are used to depict how data enters a system, are transformed by processes, stored and
then output from the system.
DFDs can be drawn at different levels of detail. Top level context diagrams five an overview of system structure,
describing key system components and data flows successive detail is added at subsequent levels until individual
processes, data flows and data stores are being described, together with their inter-relationships. As the level of
detail increases, the scope of a dataflow diagram decreases e.g. level 1 diagram might depict the whole of the sales
order processing system, whilst a level 2 diagram may just depict the process of order acceptance.
Dataflow diagrams are used to connect the components of a dataflow diagram. Rules for connecting components
are very simple:
o Every dataflow must either begin or end with a process
o Dataflows can both begin and end with a process.
The highest level of DFD is a Context diagram. ‘A Context diagram shows a system in the context of its
environment with the major information flows’.
F u l fi l m e n t
C o s to m er Or lid
de V a d er
Re r or h
sp a tc
on se p l s
ses D ta i
S a le s o rd e r de
p ro c e s s in g
sy stem
Fig. 4.10 — Context Diagram used to draw DFD

4.2.9 Entity-relationship diagram

Entity relationship model (ERM) reflects a static view of the relationship between different entities. ERM is a
static view of the relationship between different entities (i.e. does not show how entities can change over time;
which being a dynamic model, is shown in event models). ERM have three components:
 Entities are something about which data has to be stored in the system e.g. a customer. An entity
occurrence is a specific example of an entity – e.g. Mr. Smith and Mrs. Jones are two occurrences of the
entity type customer.
 Attributes are items of information stored about a particular entity – e.g. customer name/address/contact
nos., etc.
 Relationships are used to link entities together. Entities can be related to each other in a number of ways:
o One to one (1:1). In this case one occurrence of an entity is related to only one occurrence of another
entity (e.g. one customer has only one account).
o One to many (1:M) or Many to one (M:1). In this case one entity occurrence is related to one or more
occurrences of another entity – e.g. one customer has many orders in a system but each order relates to
only one customer.
o Many to Many (M:M). In this case one entity occurrence is related to one or more occurrences of
another entity and vice versa – e.g. an order can relate to many products and each product can relate to
many orders.
Entity Relationship Models are very important item of systems documentation as they define the structure of data to
be stored in a system. This is particularly important for database systems as each entity represents a possible data
table and each attributes a field.
(M :M )
E xa m p le 1 : E m p lo y ee P ro je c t
(1 :M ) (M :1 )
E xa m p le 2 : E m p lo y ee A s s ig n m en t P ro je c t
Fig. 4.11 — Entity-relationship Diagram
4.2.10 Gantt chart

‘A Gantt chart is a form of horizontal bar chart with each bar representing a project activity.’
‘Earliest Event Time (EET) is the earliest time that an event can exist which is determined by the slowest
activities that feed into it. An event only exists when all of the activities feeding into it have been completed.’
The horizontal position of a bar is determined by EET of the event from which activity leaves. The width of the bar
is determined by its duration. Floats can be marked on the chart. A Gantt chart is initially drawn using Earliest
Event Time and durations. As the project progresses actual event times and durations are used to draw on a second
set of activities that can be used for monitoring and control purposes.
4.2.11 Cost-benefit analysis

A procedure for evaluation and selection of hardware and/or software in which lists are made of all the costs and
benefits of each proposed data processing system.
4.2.12 Testing
Testing includes both the testing of individual programs and the testing of whole system as an operating entity.
Faults not found during testing will reveal themselves more expensively later in the operation. Therefore the testing
must be comprehensive.
Chapter .25
Testing can be broken into four basic stages:
1. Unit testing [test the logic]. The technique of dry running can be used to make sure that the logic that has
been set down by the analyst is correct. The programmer or analyst will trace by hand the progress of a
number of sets of data through the structure diagrams or program flow charts. If all data procedures the
results that are expected, the individual programs can be written. The individual program will also be
tested ‘live’ with test data in isolation from other program.
2. Integration testing [test each program with data]. Each program is thoroughly tested with test data as
above and also tested with several other related programs.
3. System testing [test system as a whole]. Once it has been established that individual and groups of
programs are working correctly, the system must be tested as a whole. This is an equally important task,
and the results should be documented in the same way as those for the testing of programs. It is not only
the software that is evaluated during the system testing process, it is also important to test operating
procedures, staffing levels, etc.
4. Acceptance testing. In this stage, users are involved to ensure that the system is usable for them. Users
ensure that the system performs its specifications.
Testing can be carried out in static or dynamic environment:
o Dynamic testing is the process of evaluating a system or component of that system based upon its
behaviour during execution
o Static testing is the process of evaluating a system or component of that system without executing the
program or system.
4.2.13 Documentation
The word ‘documentation’ refers to a very wide range of reference materials used in the running and maintenance
of computer systems. It takes various forms ranging from the very technical to the completely non-technical.
The level of documentation will vary according to the situation.
Types of documentation:
o Record of initial system development
o Material to help users
User manual:
o Written in non-technical language
o Includes — system objectives/overview, output, reports, sample reports, etc.
Technical manual
o Designed to be used by future project terms who may need to fix, modify or upgrade the system
o Expected to contain — system objectives, overview, performance specification, technical specification,
data dictionary, DFD, etc.
4.2.14 Training
Investment in systems will be worthwhile if the expected benefits that were identified in the feasibility study
develop, which is unlikely to happen if training is inadequate leading to wastage of investment made.
Training is needed for two reasons:
o to ensure staff operate the system correctly
o to ensure staff feel confident to perform their tasks
Training will be needed when:
o a new system is introduced
o there is a material change to a system
o a new staff member is recruited
o someone’s job changes within the organisation
o someone’s job changes as part of a general development programme
o reminder or booster courses are needed to keep skills fresh
Levels of training:
o Operational level. Training targeted to specific skills they need (e.g. how to enter a sale, or how to answer
a customer query about a product, etc.)
o Tactical level. Here, training will be target at some specific skills, but also at equipping them with more
general skills.
o Strategic level. Training is required to be given to senior managers, etc., as to how to operate MIS, DSS,
EIS, etc.
Methods of delivering training:
o Classroom-based training. This normally provides use of real software, in a training environment. Trainees
will be using the real software with dummy pre-entered data. This provides excellent training environment
where trainees can ask the trainer questions and receive an immediate response. Trainer-trainee ratio
should be one to six.
o `Computer-based training (CBT). Here, training course can be produced on a CD or a website; such that
the trainee can run the course where and when it is convenient for him to do so. This method is expensive
and time consuming to built and implement but provides flexibility in terms of location and use.
o Case studies and exercises. Both class-room and CBT can be supplemented with case studies. Case studies
are essential because they duplicate the processing of actual items in the software. They are usually quite
easy to produce and they do help the user understand exactly how the new software will work.
o Reference material.
o At-desk training.
4.2.15 System conversion

In case where a total new system is being developed, there is no requirement of system conversion. However, when
a new system is being developed to replace the existing and working system (referred to as ‘old system’), the need
for ‘system conversion’ arises.
The key moment is when the new system is introduced and goes live. Live operation should not start until:
o Staff training is complete
o Systems are fully tested
o Documents are available for use
o Cut-off procedures of the old system have been properly established
There are four approaches to system conversion:
1. Parallel conversion. This involves running the new system in parallel with the old system and making a
comparison of the results of both. If the new system performs exactly the same as the old system as far as
control details are concerned, then the go-ahead can be given for live running. Despite the theoretical
advantages, this is difficult to manage and nowadays is rarely used.
Chapter .27
N ew S y s tem
I n tr o d u c tio n o f
n e w s y s te m
T im e
O ld s y s te m
N e w & o ld s y s te m s b e c o m e s o b s o le te
a r e r u n n in g p a r a lle l
O ld S y s tem
Fig. 4.12 — Parallel conversion

2. Direct conversion. This involves direct changeover from the old to the new system without any parallel
running. Direct changeover is often the only practicable approach to changeover although there is clearly
the danger that the new system will not work correctly and that the organisation will be in serious trouble.
It is essential that the method of control be clearly established.
P o in t o f
c o n v e r s io n N ew S y s tem
T im e
O ld S y s tem
Fig. 4.13 — Direct conversion

3. Phased conversion. It is used where a complete section of the existing system is run on the new system.
This entails a greater degree of safety than a direct changeover with less disruption at any time. The chosen
section needs to be a complete section. If that part is successfully run, then other parts of the existing
system will be transferred over to be run on the new system, until eventually the whole of the system has
been changed over. For example, if the accounting system were being computerised, first convert the sales
ledger. If successful, then convert the stock system and so on.
C o n v e r s io n
s ta r te d
N ew
T im e
N ew S y s tem
O ld S ys te m
O ld
T im e
C o n v e r s io n
c o m p le te d
Fig. 4.14 — Phased conversion.

4. Pilot conversion. The changeover is carried out department-by-department or branch-by-branch. Thus, if a
manual sales ledger is being converted, it might be carried out geographically area-by-area.
The actual approach used will depend on the specific application and the existing systems. Direct changeover is
simple but can be very risky. Other methods are complex and can sometimes create problems regarding resources,
lack of will to abolish the old system, etc.
4.2.16 Maintenance
There are 2 types of maintenance programs:
1. Preventive maintenance. Preventive maintenance refers to pre-scheduled maintenance on a regular, say
monthly, basis. This is anticipated and is planned for in advance.
2. Rescue maintenance. Rescue maintenance is on-demand maintenance. It pertains to previously undetected
malfunctions that are not anticipated but that require immediate attention. A system that is properly
developed and tested should have few occasions of rescue maintenance.
4.2.17 Backup
Backup is an activity concerned in creating a duplicate set of programs or data files, etc. such that at times when
the original gets damaged, the backup set can replace the originals.
Backup File is a copy of a file, created as a safety precaution against loss of data caused due to corruption or
inadvertent deletion of the original file.
Backup Utility is a program that enables the users to create duplicate copies of necessary softwares/data-files, etc.
such that these can be kept safe to become useful at times of need. Thus, backup files are nothing but reserves.
Factors to be considered during backup are:
(i) Medium of backup — such that, at least investment, maximum benefit can be derived form most durable
and useable media
(ii) Frequency of Backup (e.g. every hour for the head office of a Bank; for an University, after publication of
result; etc.)
(iii) Physical conditions of storing backup media (since damp conditions may lead to fungus development on
magnetic media, which may disturb backup-purpose)
(iv) Physical security of backup media (i.e. person responsible, etc.)
4.2.18 Backup vs. Copy

Apparently it seems that Backup creates a duplicate copy of the file, and so does ‘copy’ utility. However there are
huge differences between backup and copy — conceptually and technically, which we will now observe.
Every file in a computer system contains certain attributes or characteristics, irrespective of whether it is a data-file
or a software-file. The number of attribute depends on the operating systems being used. However, there are at least
four common attributes in a file, irrespective of the Operating System; which are : ‘Read-Only attribute’ (set to on,
the attribute means ‘only read and do not write’– i.e., access but do not alter); ‘System Attribute’ (set to ‘on’
signifies that the file is used by the Operating System and that it is not to be even accessed by the user); ‘Hidden’
(‘on’ indicates that the file cannot be during directory listing, only by giving a special command); and lastly the
‘Archive’ attribute. In addition to these, files in UNIX, WinNT or other O/S have certain additional attributes to
specify the ownership, accessibility, etc.
When files are backed-up using a backup utility, the Archive attribute of the file just backed up, is set ‘off’ (i.e., set
to zero). This indicates that particular file has been backed up. Later, whenever this file is used (read or write) by
the system; this archive attribute is spontaneously set to ‘on’ — thereby indicating that this file has been used after
the last backup, which renders this file available for the next scheduled backup. However, if we copy file using
copy utility, a duplicate file is created, which has the same content and attributes as that of the original one (except
that the date & time of creation of the copied file contains the current value available in the system and hence
differs from that of the original file). Thus, it is not possible to identify which files have been copied and which
files have not been copied; and which files have changed since the last copy. Therefore, it is always beneficial to
use backup utility to backup files, instead of using copy utility to copy files.
Another reason why it is easy to backup files using backup utility than using copy utility, is that backup utility
software provides provision for storing the files backed-up at on that date/time, the location (i.e. directory) from
which these filed had been backed up. These help during Restore operations. If Copy utility is used, manual record
keeping of backup catalogue is required for restoration purpose, which is almost impossible.
Following are the main differences between backup-utility and copy-utility.
o Purpose. The purpose of backup is to use the backed up files only in case the original file renders itself un-
functional or inoperative. Backup-files are not meant for distribution purposes, and it is quite difficult to
distribute backup-files. The purpose of copy is to create a duplicate file. This duplicate file may be used, or
may not be used at all. This duplicate file may simply be distributed to others (which may lead to
Chapter .29
unauthorised/illegal file or software distribution); or just kept in the shelves; or may be used when the
original files become inoperative. However, backup files are not meant for distribution.
o Technical operation. Technology used by backup utility to backup files, differs from the technology used
by copy utility to copy files, since we already know about the Archive-attribute setting. Moreover, backup
utility provides flexibility in ‘restore’ operations, unlike copy utilities.
o Backup Schedules. Timetable or schedules can be made, such that whenever that time and date gets
matched, the backup utility invokes the referred backup program. Such facility is absent for copy utility.
o Password protection is available in backup protection, where as there is no such opportunity for copy
utilities.
Backup is a form of insurance, as it eliminates the risk of system breakdown, thereby avoiding system stagnation
and hence preventing huge losses.
4.2.19 Recovery
Recovery is a set of procedures to be followed in order to restore a system after a crash (i.e. malfunctioning).
Backed-up data can only be restored. Thus, recovery is impossible without backup data. In certain cases, although
backup had been taken, recovery was not required since there was no system crash or whatever. In such case, taking
backup was an additional function which now did not come to any use.
There are backup schedules — backup being taken at particular time intervals. However, there are no Recovery
schedules since recovery need not be done unless it is required.
We may think like this — Backup is a form of ‘preventive maintenance’ or proactive event; whereas Recovery is a
reactive response to some mishap, or ‘rescue maintenance’ — i.e., reactive event.
Summary
• System is an ‘organised or complex whole’ and ‘organised complexity.
Each system has interacting elements, interfaces, sub-systems and
limitations/constrains, being demarcated by its boundary. System
environment plays an important role in system functioning. There are
six types of systems. A system can be understood as the value-
addition process. Each system has a quality aspect.
• Problems are cause of concern. ‘Systems approaches’ is a series of

problem-solving steps. The structure of problem affects decision
making process. Problems are situation-specific. There are also
several personal factors that influence problem solving.
• System Development refers to the development of artificial systems,

which involved the active participation of: project manager,
system/data analyst, programmer, users, etc. System Development
process undergoes several phases, collectively called ‘Systems
Development Life Cycle’ (SDLC). A structured approach to SDLC is
known as ‘Structured SDLC’. In Structured SDLC, there are six stages,
each having a set of its own tools or methods. These phases are
namely, system planning, system analysis, system design, system
development and testing, system implementation and system maintenance
and evaluation. Theoretically, these stages are distinct and
isolated. From the practical view-point, these stages are not water-
tight compartments and hence can be blended to suit the purpose.
• Different methods known of SDLC which have been developed to guide

structured system development includes: Waterfall model, Rapid
Application Development (RAD), Joint Model, etc.
• Systems analysts are the shapers of the system, play vital role in
several areas including system operation, system requirements, etc.
Technical skills include creativity, problem solving, project
management and dynamic interface. Apart from only technical skills,
system analyst must possess certain essential skills to effectively
carry out the job.
Self-test Questions
1. What is structured system analysis?
2. ‘Analysis’ is what of the system, whereas ‘design’ is how of the system. Comment.
3. What is system development? Outline the activities involved in system development.
4. What is prototyping? Explain the use of prototyping in SDLC. What are the differences between system
prototype and system protocol?
5. What is system evaluation? When and how is it conducted and by whom? Is system evaluation just
concerned with proper system implementation? How does documentation help in system evaluation?
6. Discuss the role of system analyst with reference to users’ involvement in an organisation.
7. Discuss four approaches of system conversion and explain where and how one differs from the other.
8. What are the types of maintenance activities?
9. Explain how Backup is a form of insurance.
Chapter .31
— 1.1 — 1.30
1.0 System Study----------------------------------------------------------- ------------------------------------1

1.1 Introduction 1
1.2 Definition of ‘System’ 2
1.3 Elements of a System 2
1.4 System Environment 3
1.5 System Boundary 3
1.6 System Interface 4
1.7 Sub-system 4
1.8 Categories of Systems 5
1.9 Types of Systems 6
1.10 System — a ‘value-addition’ process 6
1.11 Quality aspects of a System 6
2.0 Systems Approach------------------------------------------------------------- ----------------------------7
2.1 Personal factors influencing problem solving 7
2.1.1 Problem sensing 8
2.1.2 Information gathering 8
2.1.3 Information using 8
3.0 System Development---------------------------------------------------------- ----------------------------8
3.1 The Process of System Development 8
3.2 System Life Cycle (SLC) 9
3.3 Participants in the systems development process 9
3.3.1 Project manager 9
3.3.2 User involvement 10
3.3.3 System Analysts 10
3.3.4 Data analyst 11
3.3.5 Programmer 11
3.4 Approaches to System Development 11
3.4.1 System Development life cycle 11
3.4.2 Waterfall approach 11
3.4.3 Prototype approach 11
3.4.4 End-user development approach 11
3.4.5 Spiral Model 11
3.4.6 Fourth Generation Techniques (4GT) 12
3.4.7 Hybrid Approach 12
3.4.8 Top-down approach 12
3.4.9 Bottom-up approach 12
3.4.10 Object-oriented approach 12
4.0 Systems Development Life Cycle (SDLC)-------------------------------- ---------------------------12
4.1 Stages in Systems Development Life Cycle 13
4.1.1 System Planning 14
4.1.2 System Analysis 14
4.1.3 System Design 15
4.1.4 System Development and Testing 15
4.1.5 System Implementation 16
4.1.6 System Maintenance and Evaluation 16
4.2 Tools used in SDLC 17
4.2.1 Feasibility study 17
4.2.2 Simulation 18
4.2.3 External and Internal design 19
4.2.4 Decision table 19
4.2.5 Structured English 21
4.2.6 Decision tree 21
4.2.7 Flowchart 22
4.2.8 Data-flow diagram 23
4.2.9 Entity-relationship diagram 24
4.2.10 Gantt chart 24
4.2.11 Cost-benefit analysis 24
4.2.12 Testing 24
4.2.13 Documentation 25
4.2.14 Training 25
4.2.15 System conversion 26
4.2.16 Maintenance 27
4.2.17 Backup 28
4.2.18 Backup vs. Copy 28
4.2.19 Recovery 29

CH 01

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CH 01

Загружено:

Авторское право:

Доступные форматы

CHAPTER 1

SYSTEM ANALYSIS AND DESIGN

1.0 System Study

1.2 Definition of ‘System’

 “System is an orderly arrangement of a set of inter-related and integrated components or

 “A set of interacting elements responding to inputs to produce outputs.”

 “System is an ‘organised or complex whole’ and ‘organised complexity’.” — Bertanalaffy

Thus, we observe that:

1.3 Elements of a System

Fig. 1.1 — Elements of a System

1.4 System Environment

1.5 System Boundary

1.6 System Interface

B u s ine s s F ina n cial

E lem en t/M o d u le/C o m p o n en t

Fig. 1.2 — Components, interfaces, boundaries of a system and its sub-systems.

1.8 Categories of Systems

1.9 Types of Systems

a cco r d in g to elem en ts : a cco r d in g to in ter a ctive b eh a vio u r : a cco r d in g to o u tp u t/w o rkin g :

Fig. 1.3 —Types of Systems

1.10 System — a ‘value-addition’ process

1.11 Quality aspects of a System

2.0 Systems Approach

2.1 Personal factors influencing problem solving

2.1.1 Problem sensing

2.1.2 Information gathering

2.1.3 Information using

3.0 System Development

3.1 The Process of System Development

3.2 System Life Cycle (SLC)

3.3 Participants in the systems development process

3.3.2 User involvement

3.3.3 System Analysts

3.3.4 Data analyst

3.4 Approaches to System Development

3.4.1 System Development life cycle

3.4.2 Waterfall approach

3.4.3 Prototype approach

3.4.4 End-user development approach

3.4.5 Spiral Model

3.4.6 Fourth Generation Techniques (4GT)

3.4.7 Hybrid Approach

3.4.8 Top-down approach

3.4.9 Bottom-up approach

3.4.10 Object-oriented approach

4.0 Systems Development Life Cycle (SDLC)

4.1 Stages in Systems Development Life Cycle

1. System 2. System Analysis

Fig. 4.4 — Different phases in a System Development Life Cycle

4.1.1 System Planning

4.1.2 System Analysis

4.1.3 System Design

4.1.4 System Development and Testing

4.1.5 System Implementation

4.1.6 System Maintenance and Evaluation

4.2 Tools used in SDLC

4.2.1 Feasibility study

4.2.3 External and Internal design

4.2.4 Decision table

4.2.5 Structured English

4.2.6 Decision tree

Fig. 4.7 A Decision Tree to select the largest of three numbers.