0

Posted by Suresh Khanal | Posted on 3:01 PM

Introduction to System Analysis and Design

29.1 INTRODUCTION

Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, The subject System Analysis and Design, mainly deals with the software development activities.

29.2 OBJECTIVES

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

understand a system
understand the different phases of system developments life cycle
know the components of system analysis
know the components of system designing

29.3 Defining A System

A collection of components that work together to realize some objective forms a system. Basically there are three major components in every system, namely input, processing and output.

In a system the different components are connected with each other and they are interdependent. For example, Human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational system and so forth. The objective of the system demand that some output is produced as a result of processing the suitable inputs.

29.4 SYSTEM LIFE CYCLE

System life cycle is an organisational process of developing and maintaining systems. It helps in establishing a system project plan, because it gives overall list of processes and sub-processes required developing a system.

System development life cycle means combination of various activities. In other words we can say that various activities put together are referred as system development life cycle. In the System Analysis and Design terminology, the system development life cycle means software development life cycle.

Following are the different phases of software development cycle:

System study
Feasibility study
System analysis
System design
Coding
Testing
Implementation
Maintenance

The different phases of software development life cycle is shown in Fig.29.1

Fig. 29.1 Different phases of Software development Life Cycle

29.5 PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE

Let us now describe the different phases and the related activities of system development life cycle in detail.

(a) System Study

System study is the first stage of system development life cycle. This gives a clear picture of what actually the physical system is? In practice, the system study is done in two phases. In the first phase, the preliminary survey of the system is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identification of user's requirement and the limitations and problems of the present system are studied. After completing the system study, a system proposal is prepared by the System Analyst (who studies the system) and placed before the user. The proposed system contains the findings of the present system and recommendations to overcome the limitations and problems of the present system in the light of the user's requirements.

To describe the system study phase more analytically, we would say that system study phase passes through the following steps:

problem identification and project initiation
background analysis
inference or findings

(b) Feasibility Study

On the basis of result of the initial study, feasibility study takes place. The feasibility study is basically the test of the proposed system in the light of its workability, meeting user's requirements, effective use of resources and .of course, the cost effectiveness. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy.

(c) System Analysis

Assuming that a new system is to be developed, the next phase is system analysis. Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system. During analysis, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for system analysis. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration:

Keeping in view the problems and new requirements
Workout the pros and cons including new areas of the system

All procedures, requirements must be analysed and documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specifications. System Analysis also includes sub-dividing of complex process involving the entire system, identification of data store and manual processes.

The main points to be discussed in system analysis are:

Specification of what the new system is to accomplish based on the user requirements.
Functional hierarchy showing the functions to be performed by the new system and their relationship with each other.
Function network which are similar to function hierarchy but they highlight the those functions which are common to more than one procedure.
List of attributes of the entities - these are the data items which need to be held about each entity (record)

(d) System Design

Based on the user requirements and the detailed analysis of a new system, the new system must be designed. This is the phase of system designing. It is a most crucial phase in the development of a system. Normally, the design proceeds in two stages :

preliminary or general design
Structure or detailed design

Preliminary or general design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage.

Structure or Detailed design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a blue print of a computer system solution to a given problem having the same components and inter-relationship among the same components as the original problem. Input, output and processing specifications are drawn up in detail. In the design stage, the programming language and the platform in which the new system will run are also decided.

There are several tools and techniques used for designing. These tools and techniques are:

Flowchart
Data flow diagram (DFDs)
Data dictionary
Structured English
Decision table
Decision tree

Each of the above tools for designing will be discussed in detailed in the next lesson.

(e) Coding

After designing the new system, the whole system is required to be converted into computer understanding language. Coding the new system into computer programming language does this. It is an important stage where the defined procedure are transformed into control specifications by the help of a computer language. This is also called the programming phase in which the programmer converts the program specifications into computer instructions, which we refer as programs. The programs coordinate the data movements and control the entire process in a system.

It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance and future change, if required.

(f) Testing

Before actually implementing the new system into operations, a test run of the system is done removing all the bugs, if any. It is an important phase of a successful system. After codifying the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results.

Using the test data following test run are carried out:

Unit test
System test

Unit test: When the programs have been coded and compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections).

System Test: After carrying out the unit test for each of the programs of the system and when errors are removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analysed. During the result analysis, it may be found that the outputs are not matching the expected out of the system. In such case, the errors in the particular programs are identified and are fixed and further tested for the expected output.

When it is ensured that the system is running error-free, the users are called with their own actual data so that the system could be shown running as per their requirements.

(g) Implementation

After having the user acceptance of the new system developed, the implementation phase begins. Implementation is the stage of a project during which theory is turned into practice. During this phase, all the programs of the system are loaded onto the user's computer. After loading the system, training of the users starts. Main topics of such type of training are:

How to execute the package
How to enter the data
How to process the data (processing details)
How to take out the reports

After the users are trained about the computerised system, manual working has to shift from manual to computerised working. The following two strategies are followed for running the system:

Parallel run: In such run for a certain defined period, both the systems i.e. computerised and manual are executed in parallel. This strategy is helpful because of the following:

Manual results can be compared with the results of the computerised system.
Failure of the computerised system at the early stage, does not affect the working of the organisation, because the manual system continues to work, as it used to do.

Pilot run: In this type of run, the new system is installed in parts. Some part of the new system is installed first and executed successfully for considerable time period. When the results are found satisfactory then only other parts are implemented. This strategy builds the confidence and the errors are traced easily.

(h) Maintenance

Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environment. It has been seen that there are always some errors found in the system that must be noted and corrected. It also means the review of the system from time to time. The review of the system is done for:

knowing the full capabilities of the system
knowing the required changes or the additional requirements
studying the performance

If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above life cycle phases.

29.6 What You Have Learnt

In this lesson systematic approach of any given problem is explained. Computer based systems are defined. System development life cycle is discussed in detail. The different phases of the development of system life cycle are explained in detail.

29.7 Terminal Question

Define a system. Explain the components of a system.
What do you understand by system development life cycle?
Discuss the importance of system analysis and design in the development of a system?

System Description Techniques

30.1 INTRODUCTION

Graphical representation of any process is always better and more meaningful than its representation in words. Moreover, it is very difficult to arrange and organise the large amount of data into meaningful interpretation of the whole. System Analysis and Design makes use of the various tools for representing and facilitating comprehension of the complex processes and procedure involved. In this lesson, we present some details about Flowcharts, data flow diagram (DFD), Decision Tables and Decision Trees.

30.2 OBJECTIVES

After going through this lesson you should be able to

Draw flowchart
Represent any physical system through DFD
Prepare decision table
Display decision tree

30.3 FLOWCHARTS

The pictorial representation of the programs or the algorithm is known as flowcharts. It is nothing but a diagrammatic representation of the various steps involved in designing a system. Some of the boxes which are used in flowcharts are:

A flowchart consists of a set of 'flowchart symbols' connected by arrows. Each symbol contains information about what must be done at that point & the arrow shows the 'flow of execution' of the algorithm i.e. they show the order in which the instructions must be executed. The purpose of using flowcharts is to graphically present the logical flow of data in the system and defining major phases of processing along with the various media to be used.

Flowcharts are of three types:

System flowcharts
Run flowcharts
Program flowcharts

(a) System Flowcharts

System flowchart describes the data flow for a data processing system. It provides a logical diagram of how the system operates. It represents the flow of documents, the operations performed in data processing system. It also reflects the relationship between inputs, processing and outputs. Following are the features of system flowcharts:

the sources from which data is generated and device used for this purpose
various processing steps involved
the intermediate and final output prepared and the devices used for their storage

Prompt the user for the centigrade temperature.
Store the value in C
Set F to 32+(9 C/5)
Print the value of C , F
Stop

Figure: 30.1 System Flowchart

(b) Run flowcharts

Run flowcharts are used to represent the logical relationship of computer routines along with inputs, master files, transaction files and outputs. Figure30. 2 illustrates a run flowchart.

Figure: 30.2 Run Flowchart

(c) Program flowcharts

A program flowchart represents, in detail, the various steps to be performed within the system for transforming the input into output. The various steps are logical/ arithmetic operations, algorithms etc. It serves as the basis for discussions and communication between the system analysts and the programmers. Program flowcharts are quite helpful to programmers in organising their programming efforts. These flowcharts constitute an important component of documentation for an application.

Figure 30.3 represents a program flowchart for finding the sum of first five natural numbers ( i.e. 1,2,3,4,5).

Fig 30.3 Program Flowchart

(d) Data flow diagram

Data flow diagrams are the most commonly used way of documenting the process of current & required systems. As their name suggests they are a pictorial way of showing the flow of data into, around & out of a system.

(e) Defining DFD

Graphical representation of a system's data and how the processes transform the data is known as Data Flow Diagram (or DFD). Unlike, flowcharts, DFDs do not give detailed descriptions of modules but graphically describe a system's data and how the data interact with the system.

(f) Components of DFD

DFDs are constructed using four major components

external entries
data stores
processes and
data flows

(i) External Entities

External entities represent the source of data as input to the system. They are also the destination of system data. External entities can be called data stores out side the system. These are represented by squares.

(ii) Data Stores

Data stores represent stores of data within the system. Examples, computer files or databases. An open-ended box represents a data/store – data at rest or a temporary repository of data.

(iii) Process

Process represents activities in which data is manipulated by being stored or retrieved or transferred in some way. In other words we can say that process transforms the input data into output data. Circles stand for a process that converts data into information.

(iv) Data Flows

Data flows represents the movement of data from one component to the other. An arrow identifies data flow – data in motion. It is a pipeline through which information flows... Data flows are generally shown as one-way only. Data Flows between external entities are shown as dotted lines.

(g) Physical & Logical DFD

Consider the figure30.4. It is clear from the figure that orders are placed,
orders are received, the location of ordered parts is determined and delivery notes are dispatched along with the order.

Fig 30.4

It does not however tell us how these things are done or who does them. Are they done by computers or manually and if manually who does them ? A logical DFD of any information system is one that models what occurs without showing how it occurs.

A physical DFD shows, how the various functions are performed? Who does them? Consider the following figure:

Fig 30.5

The figure 30.5 is opposite, it shows the actual devices that perform the functions. Thus there is an "order processing clerk", an "entry into computer file" process and a "run locate program" process to locate the parts ordered. DFD(s) that shows how things happen, or the physical components are called physical DFD(s).

Typical processes that appear in physical DFDs are methods of data entry, specific data transfer or processing methods.

(h) Difference between flowcharts & DFD

The program flowchart describes boxes that describe computations, decisions, interactions & loops. It is an important to keep in mind that data flow diagrams are not program flowcharts and should not include control elements . A good DFD should

have no data flows that split up into a number of other data flows
have no crossing lines
not include flowchart loops of control elements
not include data flows that act as signals to activate processes.

30.4 DECISION TABLES AND DECISION TREES

Decision tables and trees were developed long before the widespread use of computers. They not only isolate many conditions and possible actions but they help ensure that nothing has been overlooked.

(a) Decision Tables

The decision table is a chart with four sections listing all the logical conditions and actions. In addition the top section allows space for title, date, author, system and comment as shown in the fig.30.6

Five sections of a decision table:

TITLE : Author : Comments :	DATE : System :
Condition Stub	Condition Entry
Action Stub	Action Entry

Figure 30.6 Decision Table

The condition stub contains a list of all the necessary tests in a decision table. In the lower left-hand corner of the decision table we find the action stub where one may note all the processes desired in a given module. Thus Action Stub contains a list of all the processes involved in a decision table.

The upper right corner provides the space for the condition entry - all possible permutations of yes and no responses related to the condition stub. The yes and no possibilities are arranged as a vertical column called rules. Rules are numbered 1,2,3 and so on. We can determine the rules in a decision table by the formula:

Number of rules = 2^N = 2^Nwhere N represents the number of condition and ^ means exponentiate. Thus a decision table with four conditions has 16 (2⁴ = 2 x 2 x 2 x 2 = 16) rules one with six conditions has 64 rules and eight conditions yield 256 rules.

The Condition entry contains a list of all the yes/no permutations in a decision table. The lower right corner holds the action entry. X's or dots indicate whether an action should occur as a consequence of the yes/no entries under condition entry. X's indicate action; dots indicate no action.

Thus Action entry indicates via dot or X whether something should happen in a decision table. Let us consider the following example of book order illustrated by figure 30.7

If order is from book store

And if order is for 6 copies

Then discount is 25%

Else (if order is for less then 6 copies)

No discount is allowed

Else (if order is from libraries)

If order is for 50 copies or more

Then discount is 15%

Else if order is for 20 to 49 copies

Then discount is 10%

Else if order is for 6 to 19 copies

Then discount is 5%

Else (order is for less then 6 copies)

No discount is allowed

A decision table for the above process is illustrated below

Figure 30.7: Decision Table

(b) Decision Tree

The decision tree defines the conditions as a sequence of left to right tests. A decision tree helps to show the paths that are possible in a design following an action or decision by the user. Figure 30.8 illustrates the concept of decision tree.

Figure 30.8: Decision Tree

Decision tree turns a decision table into a diagram. This tool is read from left to right, decision results in a fork, and all branches end with an outcome. Figure 6 illustrates the decision tree for the book order decision table we saw earlier.