1.

SYSTEM ANALYSIS AND DESIGN - INTRODUCTION

Purpose of the course

- To present fundamental methodology and process for the analysis and design of
computer based business information systems

Objectives
- Describe the lifecycle approach to business information system development
- Use the tools of systems analysis and design to design business information systems

Introduction

“The course aims at developing effective information systems i.e. it involves cognitive
skills in understanding problems and knowing where computer technology best “fits in”)
It’s much more than just writing computer programs

Definition of concepts
1. Computer
2. Data
3. Information
4. I.T
5. System:
- A whole entity with a set of components that all work together to achieve a common
objective / goals.

A system is an assembly of ideas of procedures, processes, methods, routines or

techniques united by some form or regulated interaction to form an organized whole.

4. Synergy.

- The output from two or more components working together is more than the sum of the
individual parts.

1
I.S
A set of interrelated components that collect (or retrieve), process, store, and distribute
information to support decision making and control in an organization.

- Activities in an information system

- Input-Process-output-feedback

N.B A good IS must be able to produce information that carries the following
characteristics:
 Relevant – information must pertain to the problem at hand.
 Complete – partial information is often worst than no information.
 Accurate – erroneous information may lead to disastrous decisions.
 Current – decisions are often based upon the latest information available.
 Economical – in a business setting, the cost of obtaining information must be
considered.

Components of a system / information system.

Inputs
Inputs to the system include resources such as raw materials, money, technologies and
people.
- These inputs go through a process where they're aligned, moved along and carefully
coordinated, ultimately to achieve the goals set for the system

Processes: Does the actual conversion of inputs in to outputs i.e calculation sorting
summarizing e.t.c

Outputs
- Outputs are tangible results produced by processes in the system, such as
products or services for consumers.

Feedback

2
 - This is the output information that is returned to the appropriate member of the
system and makes the system to be self regulating and adjusting.

- Feedback comes from employees who carry out processes in the organization,
customers/clients using the products and services, etc.

- Feedback also comes from the larger environment of the organization, e.g.,
influences from government, society, economics, and technologies.

Environment
- This is the supra system within which the organization operates

Boundary and the interface: The dividing line between the system and its environment
Importance in system theory
- Determines the system permeability
- Determines the system scope of operation.

Classification of Systems
The frame of reference within which one view the system depends by the way it interacts
with its environment as follows

1. Physical systems

- Physical systems are the physical and tangible entities which can be felt and touched
e.g. the hardware components of a computer.

2. Abstract systems

- Abstract systems are representation of a real system that may exist either in theory, a
model or conceptualization of the intended. Eg Models, flow charts, DFD’s etc.

3. Open systems

3
 - An open system is a system which continuously interacts with its environment i.e
receives inputs from the environment and passes back the output to to
environment.
- The interaction can take the form of information, energy, or material transfers into
or out of the system boundary.
- Examples Biological Systems, and Organizational Systems

4. Closed systems

- A closed system is a system isolated from its surrounding environment so that it

cannot interact with its environment.
- Organizations that have closed boundaries often are unhealthy. Examples include
bureaucracies, monopolies and stagnating systems. A chemical reaction in a
sealed, insulated container

5. Deterministic

- Deterministic systems are systems where the output can perfectly been predicted
form the inputs with certainty.
- The interaction between the parts or subsystems is known for certain; example: a
computer program which performs exactly to a set of instructions.

6. Probabilistic

- Probabilistic/ stochastic: is a system where the output can be predicted from the
previous state but with some probability.
- A system that can be described in terms of probable behavior (a certain degree of
error); examples: a business enterprise.

7. Cybernetic system.

4
 - This is a self organizing system that react and adjust according to inputs and
stimulus e.g. a bank that pays the rate of interest to depositors depending with the
amount of money in the deposit account.

8. Computer based information systems –These are information systems that handle
business applications. Examples. (Stratification)
a. Transaction Processing System (TPS)

- Capture and record information about the transactions that affect the organization
(e.g. the sale of an item, a withdrawal from an ATM etc.)

b. Management Information System (MIS)

Take information captured by the transaction processing system and produce reports
management needs for planning and controlling business

c. Decision Support System (DSS)

– Support human decision making and allows users to explore the potential
impact of available options or decisions (e.g. can ask “what if”)
– Highly interactive systems that assist managers in making semi structured
decisions.

d. Office Automation System (OAS)

A system that automates the office activities by computerizing the office
procedures.
Examples word processors, spreadsheets etc.

Characteristics of a System

1. Organization: It defines the Structure or order or the arrangement of components

that helps to achieve the objectives.
2. Interaction: Procedure in which the components interact.

5
 3. Interdependence. One subsystem depends on the input from another sub system
for proper functioning.
4. Integration: This is concerned within how the components are tied together and
successful system integration produces a synergistic effect (synergy) that is where
the output from two or more components working together exceeds the sum of
their individual participation.

N.B Decoupling is the separation of systems and subsystems. Importance Increases

system coordination, increase efficiency, for cross coordination etc

5. Central Objective: Defines the ultimate systems goals i.e. to increase profit as you
reduce expenditure.

Systems Analysis: Involves understanding and specifying in detail what an information

system should do.

- The purpose of systems analysis is to provide an overview or detailed pictures of the

operations in an organization in terms of the following: -
i A general statement of the objectives
ii A description of the organizational structure.
iii Description of the functions performed
iv A definition of user’s requirements.
v Definition of the constraints for the system design.
vi A statement of cost incurred in the operations
vii Preliminary h/w and s/w specifications
viii Overall schedule for system design development and implementation
ix Recommendation to management whether or not to start the system design.

System Design: Involves specifying in detail how the parts of an information system
should be implemented

6
 Why is it important?

• Success of information systems depends on good SAD

• The approach is widely used in industry - proven techniques

8. System Analyst: A professional who used analysis and design techniques to solve
business problems.

Required Skills of the Systems Analyst

• Technical Knowledge and Skills

• Computers and how they work in general

• Programming languages
• Communications networks
• Database and database management systems
• Operating systems and utilities
• Business Knowledge and Skills
• What activities and processes organizations perform?
• How are organizations structured?
• How are organizations managed?
• People Knowledge and Skills
• Good communicator
• Should be able to persuade
• Skill in interviewing, listening and observing
• Good written and oral presentation
• Being able to work in a team
Discuss why the system analyst is referred to as a caterist of change in organisations.
System methodology
Systems methodology refers to the methods by which systems are compared and
evaluated.

7
IS System Development methodologies
 System Development Life Cycle (S.D.L.C) /Life cycle approach
 Waterfall model
 Spiral
 Prototyping
 Structured Analysis Development Method (S.A.D.M)

System Development Life Cycle

- It the oldest methodology for building an information system. This method breaks the
development into various stages that must be followed systematically.

The life cycle: -

Birth Problem Recognition

Growth Feasibility
Analysis
Design
Implementation

Death Testing
Maintenance

NB: Every system goes through a process of birth, growth maturity and decline

1.Problem Recognition (investigation)

- This is where a formal work is done on the system to identify the new system to
develop i.e. project selection or opportunity recognition.

8
 - During problem definition, the management or the system analyst must know the
exact problem. E.g. In a bank a typical problem would be the long queues in the
banking hall. Lack of data security in the existing system.
- Is a description detailing why an investigation has to be carried out and what the
system does. It also guides to determine the area of study. This should be
communicated to the systems analyst in a formal written document which acts as
the terms of reference. It can be drafted by a committee of senior personnel who
guides the work of the project according to a long range predetermined, plan of
action.
Terms of reference.
Is a formal document to guide the analyst on the objectives to be achieved. It has the
following contents
i) Title of project
ii) Purpose of study
iii) Project time table
iv) Constraints the analyst will meet or have to work to during the
investigation
v) The subject of study (area of study)
vi) The personnel involved in the project.
vii) The necessary material (resources) to be used in the project.
Reasons for development of new system/Modification
 Difficulty being encountered in the operation of the existing system. This may be
recognized by the user who encounters difficulties and asks for help from systems
analysts.
 An area of poor performance being identified by the management, which
increases the level of indirect expenses.
 Invention of new systems, which are more successful than the existing ones.
N.B
- Once the problem has been recognized and acknowledged by the management,
the user and system analyst, the work of implementing new system is assigned to
the analyst.

9
 - The management comes up with a report (terms of reference), which is given to
the system analyst to conducts feasibility study.

Feasibility study

- This is an exercise where the system analyst investigates the problem and the
information needs of the stakeholders.
- The process seeks to determine the resources required to provide an information
systems solution, the cost and benefits of the solution.
- The analyst conducting the study gathers information using a variety of methods,
as follows:

 Interviewing users, employees, managers, and customers.

 Questionnaires to interested stakeholders, such as potential users of the
information system.
 Observing or monitoring users of the current system to determine their needs as
well as their satisfaction and dissatisfaction with the current system.
 Analyzing documents, reports, layouts, procedures, manuals, and any other
documentation relating to the operations of the current system.
 Modeling, observing, and simulating the work activities of the current system.

N.B

- The goal of the feasibility study is to consider alternative information systems

solutions, evaluate their feasibility, and propose the alternative most suitable to
the organization.

Types of feasibility study

1. Economic feasibility. This is where the economic viability of the proposed

system and the proposed project's costs and benefits are evaluated.

10
 2. Technical feasibility. This tries to see whether existing technology should be
suitable to support the new system and whether the needed technology can be
developed, Examples
1. Training the staff
2. Consultants
3. Ways of developing it e.g. more training
4. Hiring experts’ e.t.c.

3. Operational feasibility. This evaluates the ability, desire, and willingness of the
stakeholders to use, support, and operate the proposed computer information system.

4. Social feasibility. This takes the needs of the various people affected by the proposed
system in to account.

5. Legal feasibility  This factor mandates that no conflicts exist between the system
under consideration and the organizations ability to discharge its legal obligation.

6. Schedule feasibility  The analyst must estimate when the proposed system will be
operative, assuming that it is eventually accepted. Gantt charts and PERT charts are used
to show the schedule.

What are Gantt Charts?

Gantt charts are bar graphs that help plan and monitor project development or resource allocation
on a horizontal time scale.

11
PERTchart
- A PERT chart is a project management tool used to schedule, organize, and coordinate
tasks within a project. PERT stands for Program Evaluation Review Technique,

- A PERT chart presents a graphic illustration of a project as a network diagram

consisting of numbered nodes (either circles or rectangles) representing events, or
milestones in the project linked by labelled vectors (directional lines) representing
tasks in the project. –
- The direction of the arrows on the lines indicates the sequence of tasks. In the
diagram, for example, the tasks between nodes 1, 2, 4, 8, and 10 must be
completed in sequence. These are called dependent or serial tasks.
- The tasks between nodes 1 and 2, and nodes 1 and 3 are not dependent on the
completion of one to start the other and can be undertaken simultaneously. These
tasks are called parallel or concurrent tasks.
- Tasks that don't require resources or completion time are considered to have event
dependency and are represented by dotted lines with arrows and are called dummy
activities.
- For example, the dotted arrow linking nodes 6 and 9 indicates that the system files
must be converted before the user test can take place, but that the resources and
time required to prepare for the user test (writing the user manual and user
training) are on another path. Numbers on the opposite sides of the vectors
indicate the time allotted for the task.

12
 N.B After the feasibility the systems analyst prepares a system specifications/
feasibility report which contains the following
 Introduction
 Aim of the system
 File conversion procedures
 Program specification.
 Job control specification
 System description
Methods of fact finding

1) Interview
1) Observation
2) Questionnaire
3) Research

13
 4) Reading documents - inspection of maintained records

Interview:
- Involves the direct conversation between the analyst and the user of the system, in order
to obtain answers, comments and suggestions about the current state of the system.
- Interviewing process:
i. Determine who is to interview
ii. Establish the objectives of the interview
iii. Preparing for the interview
iv. Conducting the interview
v. Documenting the interview
vi. Evaluating the interview

The factors to consider for the success of an interview:

- Before the interview

1) Understand the background information about interviewees.

2) Establish interview objectives. Then write questions to cover key areas in
decision-making.
3) Include key people at all levels who will be affected by the system
4) Prepare the person to be interviewed by calling ahead of time
5) Arrive a little early to your interview
6) Keep department managers informed of your meetings

- During and after the interview

- Avoid direct questions.

- State the reasons for the interview
- Don’t interrupt i.e. allow the conversation where opinion and suggestions can be
heard.

14
 - Avoid yes or no questions
- Get used to interviewee language
- Compliment where possible (good, thank you e.g.

Rules to be followed when framing questions.

- Questions should not suggest their own answers (e.g. “I’m sure you have had
experience in data processing haven’t you?”

- Open-ended questions are best; they suggest no particular answer and encourage
the candidate to talk at some length. Example is: “Tell me about any data
processing experience you have had?”

- The meaning of questions should be clear.

- Probing questions should be used. Example If a staff says he was responsible for
a certain activity, this must not be taken at its face value – further questioning is
needed.

- The interviewer should guide the course and subject matter of the interview, by
questions which introduce new topics, linking them to what has been dealt with
before.

- A large number of questions should begin with the words how or why.

Advantages
- Access to first class information
- Give adequate opportunity for interviewee to put forward opinions and
suggestions
- Make the interviewee feel as part of the system
- Help the analyst clear the panic and resistance, and eliminate fear and rumors

Disadvantages

- Make the interviewee feel they are being summoned or grilled

- Some interviewees give answers which are not facts but opinion

15
 - Demands patience an persistence especially when one has decided not to give
out information

Questionnaire:
- This is a document containing a number of standard questions, asked to a
large number of people in order to gather information.
- It enables analysts to gather attitude, beliefs, behaviors and characteristics
from key people who may be affected by the proposed system.
- It is used to identify an area for in-depth study of specific requirements.

When to use questionnaire

- Limited amount of information is required from a large number of people
- You desire to do problem sensing and identifying problems of the current
system
- You want to do a study on a system with the view of forming an opinion about
it
- There is a large number of people involved in the system project
- The people you need to gather information from are vastly dispersed.
Advantages

- Saves analyst time, especially when respondents are scattered

- Answers given in less tense environment
- Provides many people with the opportunity to provide input and suggestions
- Questions presented to all respondents without bias
- Suited where no detailed or long answers are required

Disadvantages

- Response can be poor with unanswered questions.

- Some questions can be easily misunderstood
- Designing a questionnaire requires expertise

16
 - Analysis of questionnaire requires a lot of time

Observation:
- This is a technique, which involves observing people in the act of executing their
duties.
- It gives analysts a clear understanding of the system in question.
Benefits:

- Can protect confidential information sources

- Can correct erroneous impression.
- Recommendation will receive better acceptance since they are based on personal
observations
- Helps analysts become acquainted with operating personnel

Problems:

- Costly and time consuming

- Staff members not comfortable when they are being observed.
- Personnel may improve their performance while they are under constant observation

Research
Involve reviewing journals, periodicals and books that contain information relevant to the
system, attending professional meetings and seminars, discussing with other
professionals, visiting other installation to see relatively similar systems in actual use.
Advantages
- Get the exact information needed.
The method has the following drawbacks
a) It is time consuming
b) Documents are not always up to date.

17
System Analysis
- Involves the evaluation of the current system using the general information to ascertain
whether it meets the users current and projected needs and subsequent information of
what is to be done.

- The system analysts work in conjunction with the user to develop a logical model of the
system understanding and specifying in detail what an information system should do.zzz
- This involves modeling the users’ environment with functioning diagrams, data
diagrams, entity-relationship diagrams and the other tools of the system analysis.
Analysis Tools used during systems analysis
 Functional diagram (FD)/ Functional hierarchy diagram/ hierarchy diagram
 Data flow diagrams (DFD)
 Entity relationship model (ER Model)
 Data dictionary
 Decision tables
 Decision Trees
Functional diagram (FD):
- A functional diagram is used to show system’s functions that will be constructed and
the implementation process of data diagram.
- A function diagram only shows what to do not how to do. In a functional diagram, a
function is divided into many smaller functions of what the system intends to do.
- Functional diagram involves Constructing diagram is a process of division, from a
higher function to appropriate smaller functions.
- example:

18
19
 Data Flow Diagrams
- Definition: Data Flow Diagramming is a means of representing a system at any level of
detail with a graphic network of symbols showing data flows, data stores, data processes,
and data sources/destinations.

- Is a technique for modeling or documenting a system as a whole in a structured way.

Shows how data moves and changes through an information system in a graphical,
top down style.

THE TECHNIQUE OF DATA FLOW DIAGRAMMING

- Purpose/Objective:
- The purpose of data flow diagrams is to provide a semantic bridge between users and
systems developers.

- The goal of data flow diagramming is to have a commonly understood model of a

system.
- Data flow diagrams have the objective of avoiding the following costs:

 User/developer misunderstanding of a system, resulting in a need to redo systems

or in not using the system.

20
  Having to start documentation from scratch when the physical system changes
since the logical system remains the same when technology changes.
 Being unable to evaluate system project boundaries resulting in a project of
inappropriate scope.

Symbols Description:
Data Flow Diagrams are composed of the four basic symbols shown below.

Process

External Entity

Data flow

Data store

The External Entity symbol represents sources of data to the system or destinations
(sink) of data from the system.
- They provide the net inputs to a system and receive the new outputs from the system.

1. Are named with appropriate name.

2. Can be duplicated, one or more times, on the diagram to avoid line crossing.
3. Determine the system boundary. They are external to the system being studied.
They are often beyond the area of influence of the developer.
4. Can represent another system or subsystem.

The Data Flow symbol represents movement of data.

21
 - Data flow names should be descriptive adjectives and nouns. data flow names should
describe the data flow without describing the implementation of that data flow.

The Data Store symbol represents data that is not moving ( data at rest).
- Data stores represent the business people, objects and events about which we need to
store data.

- Are generic for physical files (index cards, desk drawers, magnetic disk, magnetic
tape, shirt pocket, human memory, price list etc.)

1. Are named with an appropriate name, and numbered with a number.

2. Can be duplicated, one or more times, to avoid line crossing.

The Process symbol represents an activity that transforms or manipulates the data
(combines, reorders, converts, etc.).

1. Show data transformation or change. Data coming into a process must be "worked
on" or transformed in some way. Thus, all processes must have inputs and
outputs.
2. Are represented by a rectangle
3. Are named with one carefully chosen verb and an object of the verb (eg Verb
Purchasing Object of the verb Prepare orders)
4. Are numbered within the diagram as convenient. Levels of detail are shown by
decimal notation. For example, top level process would be Process 14, next level
of detail Processes 14.1
5. Should generally move from top to bottom and left to right.

- N.B In a DFDs omit processes that do nothing e.g. move or route data. For example,
omit a process that corresponds to a secretary receiving and simply forwarding a variety
of documents to their next location. Thus, only those processes that change data should
be included on a DFD.

The procedure for producing a data flow diagram is to:

22
 1. Identify and list external entities providing inputs and receiving outputs from
system;
2. Identify and list inputs from and outputs to external entities;
3. Create a context diagram with system at centre and external entities sending and
receiving data flows;
4. Identify the business functions included within the system boundary;
5. Identify the data connections between business functions;
6. Confirm that the sent data is received and vice-versa;

Advantages of DFD’s

 They are an independent method of processing i.e can be used on computer or

manual based information system
 Symbols used are simple and easy to remember
 Link system with environment
 Progress with details after increasing level of detail.

Example 1 (demonstrate fact recording)

A purchasing department receives a purchase requisition from the stores. The

requisition is checked and an invalid one is returned to the stores for correction.
An order is made out using a file of approved suppliers and sent to the appropriate
ones. A copy order and the requisition are filled. When goods are received the
invoice is compared with the filled copy order, and an invalid invoice is returned to
the supplier. Valid invoices are passed to the accounts department for payment
and fulfilled orders are filled. Draw a DFD for the requisition system.

SOLUTION
The analysis of the CASE should lead us to the following points.
- The store is a source,
- the accounts department is a sink

23
 - The supplier is both a source and a sink.
- The files involved are the approved suppliers file, pending order,
requisition and fulfilled orders file.
The DFD is as figure below

24
Example II
Draw a data flow diagram to represent the following system When an invoice is
received from a supplier, it is checked against a file of authorized purchases. If
the invoice does not match an authorized purchase, then it is returned to the
supplier with a querying letter. If the invoice matches an authorized purchase,
but is for an incorrect amount, then it is returned to the supplier with a
standard form. If the invoice
reconciles, a payment authorization is made out. A cheque is then sent to the

25
supplier. and the invoice and the authorization are filed

3. Entity-Relationship Modeling (Also known as Logical Data Structures)

1. Introduction
- A model is a representation of reality.
- Logical models show what a system is or does and depict the system independent of any
technical implementation.

- Physical models what a system is or does and also how the system is physically and
technically implemented.
- Data modeling is a technique for organizing and documenting a system’s data.
- Entity-Relationship modeling is a technique which can be used to analyze an
organization’s data requirements.

- The aim is to obtain a model which is a logical view of an organization’s data and serve
as a basis for computer implementation.

- Analysis of the proposed system will have provided the analyst with details of all the
data items or attributes

- The process uses a diagrammatic representation of the proposed tables identifying the
table’s, attributes and entities.

2. Components of an Entity Relationship Diagram

2.1 Entities

- An entity is something of importance to the system, about which data is held.

- An entity is a class of persons, places, objects, events, or concepts about which we need
to capture and store data.

26
- For example, in a student administration database entity could be Students; the entity
type would therefore be Student, whilst a particular occurrence of the entity type could be
the Student Chris Davies.

Identifying entities:

1. Entities are representations of data that is being stored. So if a DFD has been draw
check there should be an entity corresponding to each data store or file on the
DFD.
2. Think about what groupings of data the user is going see.
3. An entity is something we are going to hold data about .

- An entity instance is a single occurrence of an entity.

- Example: instances of the entity STUDENT may include
- Betty Arnold
- John Taylor
- Bill Mac

An entity must have the following characteristics:

1. It must contain information of interest to the system i.e. the STUDENT entity
contains information concerning names, addresses, qualifications, exam results
etc.;
2. It must be possible to have more than one occurrence i.e. the environment itself
cannot be an entity as there is only one occurrence;
3. Each occurrence must be uniquely identifiable - there must be a code or key for
each entity instance.

2.2 Entity Attributes

-An attribute is a descriptive property or characteristic of an entity. i.e. a field.

- These are the data items associated with each entity.

27
Example - Student as an entity may have the following attributes:

 Name:
 Address:
 DOB:
 ADM Number:

2.3 Unique Identifiers

A unique attribute that identifies an entity.

2.4 Relationships

The association between Entities

Cardinality

- The degree of association between entities.

- A relationship’s cardinality defines the maximum number of entities of one type that
can be associated with an entity of another type.

There are three basic cardinalities

- One to one
- One to many
- Many to many

A one-to-one (1:1) relationship is when at most one instance of an entity A is associated

with one instance of entity B. For example, take the relationship between board members
and offices, where each office is held by one member and no member may hold more
than one office.

28
A one-to-many (1:N) relationship is when for one instance of entity A, there are zero,
one, or many instances of entity B but for one instance of entity B, there is only one
instance of entity A. An example of a 1:N relationships is

a department has many employees; each employee is assigned to one department.

A many-to-many (M:N) relationship is when for one instance of entity A, there are zero,
one, or many instances of entity B and for one instance of entity B there are zero, one, or
many instances of entity A. An example is employees may be assigned to no more than
three projects at a time; every project has at least two employees assigned to it.

Components of ER Diagrams:

 rectangles representing entity sets.

 ellipses representing attributes.
 diamonds representing relationship sets.
 lines linking attributes to entity sets and entity sets to relationship sets.

Example:

- The entity types such as EMP and PROJ are depicted as rectangular boxes, and the
relationship types such as WORK-FOR are depicted as a diamond-shaped box.
- The attributes such as EMP#, NAME, and PHONE are depicted as ellipse.
- The cardinality information of relationship is also expressed. For example, the “1” or
“N” on the lines between the entity types and relationship types indicated the upper
limit of the entities of that entity type participating in that relationship.

29
Review Questions

Question 1. For each of the following pairs of rules, identify two entity types and
one relationship. State the cardinality and existence of the relationship in each
case. Draw the ER diagram.

1. A department employs many persons. A person is employed by, at most, one

department.
2. A manager manages, at most, one department. A department is managed by, at
most, one manager.
3. An author may write many books. A book may be written by many authors.
4. A team consists of many players. A player plays for only one team.
5. A lecturer teaches, at most, one course. A course is taught by exactly one lecturer.
6. A flight-leg connects two airports. An airport is used by many flight-legs.
7. A purchase order may be for many products. A product may appear on many
purchase orders.
8. A customer may submit many orders. An order is for exactly one customer.

30
 Question 2: Draw an ER diagram for the following. Be sure to indicate the
existence and cardinality for each relationship.

A college runs many classes. Each class may be taught by several teachers, and a teacher
may teach several classes. A particular class always uses the same room. Because classes
may meet at different times or on different evenings, it is possible for different classes to
use the same room.

4. Decision Tables:

Used to explain confusing narratives with clear and structured definitions of what
happens under certain condition.

- Are graphics methods for describing the logic of a decision? They give a clear and
structured definition of what happens under certain circumstances.

- The conditions applying in the particular problem are set out and actions to be taken as
a result of any combination of the conditions arising are shown.

Have standardized format and are comprised of the following sections

1. Condition stub:- contain a list of all possible conditions which could apply in a
particular problem.
2. condition entry:- contain the different combination of the condition, where each is
given a number of “Rule”
3. Action stub:- contain a list of the possible actions which could apply for any given
combination of conditions.
4. Action entry:- shows the actions to be taken for each combination of condition

Conditions Rules
Condition Stub Condition entry

31
 Action / AternativeStub Action Entry

Construction of Decision table

1. on the narrative, identify all the conditions which must be addressed before a
decision can be executed and enter them on the condition stub
2. Identify all actions, and enter them on the action stub.
3. Tabulate the number of rules
4. Make Y(yes) or N(no) for the conditions entry
5. Mark actions to be taken by an X in the Action entry.

Example 1.

An insurance company invites applications for motorist regarding insurance cover.

Applicants are required to submit the following details.

 Name and address

 Age
 Number of accidents in the last ten years
 License type, full or provisional

The rules regarding the acceptance are as follows

 Motorists who are 31 years old or over, with no accidents in the last ten years,
who hold a full license are accepted for full cover
 Motorists who are 31 years old or over, with no accidents in the last ten years,
who hold a provisional license are accepted for third party cover
 All others are rejected.

Draw a full limited entry decision table.

32
 Conditions Rules
1 2 3 4 5 6 7 8
Age 31 yrs or over Y Y Y Y N N N N

No accident in last 10 yrs Y Y N N Y Y N N

Full license Y N Y N Y N Y N
Full cover X

Third party
X

Reject
X X X X X X

Example 2:

Students who have passed both the course work and exam for a Degree Course are
allowed to graduate. They are also issued their Degree scripts provided they have
completed payment of all fees. Students who have passed their course work only must
attend further exam coaching before sitting for the next exam. Those who have passed
their exam but not their course work are required to attend a semester of remedial classes.
Any student who has not paid his or her fees is issued a warning letter.

R1 R2 R3 R4 R5 R6 R7 R8
Passed course work? Y Y Y Y N N N N
Passed exam? Y Y N N Y Y N N
Paid all fees? Y N Y N Y N Y N

33
 Issue graduate status X X - - - - - -
Issue degree script X - - - - - - -
Attend exam coaching - - X X - - X X
Attend remedial classes - - - - X X X X
Issue warning letter - X - X - X - X

Redundancy

Consider the following decision table which shows a procedure for dealing with
applicants for a motor car license.

Insurance 1 2 3 4
Age ≥ 25? Y Y N N
Clean license? Y N Y N
Normal terms X
Loaded premiums X
Refuse X X

The last two vertical rules lead to the same action an could therefore be combined
into one, since once an applicant is less than 21 yrs, the applicant is refused regardless
of the conditions of the applicants license hence question of clean license is redundant
in the last two rules.

Thus where two vertical rules have action entries which are exactly the same and
conditions differ in one respect only, they can be combined. Rule 3 & 4 can be
combined into one whereby it has a dash opposite the condition which is irrelevant.

Insurance 1 2 3
Age ≥ 25? Y Y N
Clean license? Y N -
Normal terms X

34
Loaded premiums X
Refuse X

Exercise

Students registered for technical exams by K.N.E.C are dealt with, according to the
following.
 A student who passes the examinations and completes the coursework and
project satisfactorily is awarded a pass
 If the coursework and/or the project are not satisfactory, the student is asked
to re-submit the unsatisfactory work as long as the exams have been passed.
 A student who fails the examinations is deemed to have failed the whole
course, unless both the coursework and the project are satisfactory, in which
case the student is allowed to re-sit the examination.
i) Draw a full limited entry decision table which covers all the above rules
[8
Mks]

Advantages of decision tables

1. It provides a clear-cut procedure for identifying conditions and actions.

2. It establishes the relationship between conditions and actions in a
compact and unambiguous manner.
3. It makes it possible to examine all alternatives to a problem(since the
maximum number of rules is known).
4. It forces the programmer to think logically.
5. It is easy to construct and to understand.
6. It serves as a convenient form of communication between users,
systems analysts and programmers, being readily understandable and
verifiable by all.
7. It can be readily translated into a program code (see section 7.5) either
by the programmer, or by a software known as a decision table pre-

35
 processor.

Decision trees

Are used when complex branching occurs in a structured decision process. Are also
useful when it is essential to keep a string of decision in a particular sequence..

Structure of decision tree.

Action 1
Condition X1

Action 2
Condition A1 Condition X2

Condition X1 Action 3
Condition A2

Condition X2 Action 4

Example
Full licence Full cover

No accidents in 10yrs
Provisional

Full licence
Reject

Age ≥ 31 Accidents in 10 yrs

Provisional Reject
Full licence Third party
Full licence
No accidents in 10yrs Reject
Age < 31
Provisional
Reject
Accidents in 10 yrs Full licence
Reject

Provisional
Reject

Program flow chart (**done in programming)

36
System flowcharts
Is a diagram which gives an overall view of data processing system by showing
tasks carried out, device and medium used by the system.
-it depict the logical flows of data and processing steps in an Information System.
They use symbols that are industry conventions standardized by the National
Bureau of Standards.

37
4.System Design

- The design of an information system produces the details that state how a system
will meet the requirements identified during systems analysis.
- System design can be categorised into two sections i.e Logical and Physical Design.
- Logical is concened with what is required. It defines all the input to the systems, the
output to be produced, the processes that must be performed and constrains to be
met.
- Physical design deals with how the requirements are satisfied. Describes how the
data is input, how it is stored and processed, how the output is produced, and the
constraints that are met.

- Activities of systems Design

 Define output requirements, volume, frequency and format
 Specify input layouts, frequency etc
 Develop overall systems logic
 Identify files to be used i.e master files, working files, frequency of
update and speed of response required from files
 Decide which storage devices should be used.
 Determine file organization layouts i.e sequential , random etc.

- Design objectives
 Produce information with all the desirable quality of accuracy, timeliness,
efficiency and robustness.
 Develop a system which conforms with company policy.
 To develop a system which will link with other subsystems
 To design a realistic cost effective system with laid down constraints
 To intensify system security inorder to ensure confidentiality of stoterd
data, prevent invations of privacy and minimize accidents.

38
 Aspects to systems design.
(a) Design the Input : The types of forms to be used.
(b) Design the Output
- Is identifying reports and other output the system will produce
Usually, designers sketch the form or display(screen) as they expect it
to appear when the system is complete.

(c) File Design

- Designers define the database and select storage devices, such as magnetic disk,
magnetic tape, or even paper files.
(d) Design the Processing
- The systems design also describes how the data will be processed. Individual data
items and calculation procedures are written in detail.
-
5 Implementation
- Is a process of putting a new system into use? Before the implementation the
following activities must be undertaken.
 Five major activities takes place:
(a) Site preparation,
(b) Software & quality Testing
(c) Training,
(d) Conversion.

 Site preparation

 Implementation begins with equipment installation, putting in place the

equipment and software so that testing and conversion activities can occur.
 Preparation activities include electrical and air- conditioning preparation, site
layout and installation of the equipment
 The electric lines should be checked to ensure that they are free of static or
power fluctuations. It is desirable to install a "clean" line that is not shared by
any other equipment

39
 Software quality testing.

- Involves testing all the system aspects to ensure its ready for use and of quality.

Examples.

- Volume testing; to ensure the system can handle situations with a lot of work.

- Usability testing; The system can be used easily by all users

- Functionality testing : Does the intended

- Security testing: Can restrict unauthorized users.

System/software quality factors can be categorization into three important

aspects of a software product:

Product Operations: A software product's operational characteristics;

Product revision: Its ability to undergo change,

Produced Transition: Its adaptability to new environments.

Product Operations

 Correctness (Does it do what I want?)

The extent to which a program satisfies its specification and fulfils

the mission objectives.

 Reliability (Does it do it accurately all the time?)

The extent to which a program can be expected to perform its

intended function with required precision.

 Efficiency (Will it run on my hardware as well as it can?)

The amount of computing resources and code required by a

program to perform a function.

 Integrity (Is it secure?)

40
 The extent to which access to software or data by unauthorised
persons can be controlled.

 Usability (Is it designed for the user?)

The effort required to learn, operate, prepare input, and interpret

output of a program.

Product Revision

 Maintainability (Can I fix it?)

The effort required to locate and fix an error in a program.

 Flexibility (Can I change it?)

The effort required to modify an operational program.

 Testability (Can I test it?)

The effort required to test a program to ensure that it performs its

intended function.

Product Transition

 Portability (Will I be able to use it on another machine?)

The effort to transfer the program from one hardware and/or

software system environment to another.

 Reusability (Will I be able to reuse some of the software?)

The extent to which a program (or parts of a program) can be

reused in other applications-related to the packaging and scope
of the functions that the program performs.

 Interoperability (Will I be able to interface it with another system?)

The effort required to couple one system to another.

41
  Training

- This involves the orientation of the users to give them confidence and minimize data
entry errors.
Thus training has advantages like
 Enable staff to carry out the tasks required of them to support the system
 Convince the user department staff that the new system is an effective and
efficient one.
 Overcome fear of change and any feeling that they may be unable to cope with
the demands of the new system
Who should be trained
Amount of training required for various categories of personnel will depend upon the
complexity of the system i.e. how much someone’s job will change and the skills
presently available.
Basically all staff who will come into contact with the system need to be
trained. This include
i. Staff in data entry department e.g. operators and data preparation staff
ii. I.T department staff who support the operation of the system
iii. Management staff who make use of the output to make decisions
iv. The auditors who are responsible for determining whether or not an
organization assets are properly protected
v. Any other department staff affected by the new system.
NB/ Ensure that users of different skill levels and job interests are separated. Certain
trouble is the result of mixing novices with experts.

Who are the Trainers?

In a large project, many different trainers may be used depending on how many users
must be trained and who they are. Possible trainers are:
1. System vendors (provide training on their equipments)
2. Systems Analysts / Developers
3. Externally paid trainers
4. In-house trainers
5. Other system users

42
Methods of training
The options include
i) Handbooks- will be produced as part of, or as a development from the
systems specification
ii) Courses- Either full time or part time courses often run by vendors or
training institutions
iii) Lectures- covers general background knowledge or knowledge of specific
areas including advantages of the system
iv) Case studies and group discussion

NB/ Staff recruitment: if new staff is required to be hired for technical areas, then it can
be done alongside the training.

System Testing

 Is the process of executing a program with the intent of finding an error

 Ensures that individual programs have been written correctly and that the
system as a whole will work. The analyst, programmers and staff involved
perform test walkthrough
 System testing includes testing of procedures used to capture data, to convert
data into computer readable form and to produce outputs of the system.
 Main concern during system testing is the system’s capabilities to process
transaction correctly without creating backlog.
Throughout the development, and as a separate stage after development is
completed, testing and debugging will be necessary. Tests will be carried out
according to the schedule prepared by the SA or Senior Programmer. During the
process of testing, changes can be made in any of the previous stages to rectify
any errors or problems discovered.

At this stage, the documents generated are:

 Test log

43
  Test plan
 Test data
 Test results (both expected and actual)

Test Plan
A test plan is required before testing starts. It serves as a guide to carry out the tests.
During preparation of the test plan, the objective must be to ensure that the component is
tested thoroughly.

The test plan should include:

 A description of the component being tested;

 A description of the function of the component to be tested;
 A description of the conditions under which the test will run,
(i.e. the values of any global variables);
 The test data to be used; and
 The expected result
Nature of system testing

Affected personnel from various departments are involved in a test walkthrough. This
apart from assisting to improve confidence, it ensure an error free system is implemented.
Each group has special contribution namely:

i. System managers check if the system conforms with the policy of the
organization
ii. System analyst check if objectives are being met and the system is error free
iii. Programmers debug the programs in case of errors
iv. Auditors check the controls in the system
v. Operation managers check on the operational weakness of the system
vi. User department ensure the system is tested to their satisfaction

Test data

44
Dummy data which contains valid and invalid data items created by user department
staff, analyst, programmers and auditors to determine expected resorts. The test data may
cover conditions such as:-

i. Range errors
ii. Format errors
iii. Zero or negative values where +ve values are allowed
iv. Non-integers in such fields as quantities
v. Transaction record which is not matched by a corresponding master file.
vi. Invalid combination e.g sex “M” title “Miss”
………E.T.C
Types of Tests.

“Black Box” Testing

Method that focuses on functional requirements. In black box testing, there is no attempt
to understand how the codes work. In fact, the codes may not even be known. In this
testing approach, test data is derived from the specifications of the program and is
carefully selected to test every possible combinations of the input.

Then the actual result from a given set of test data is compared with the expected result.
If the actual results agree with the expected results, it can be concluded that the codes
work as specified.

“White Box” Testing

With white box testing, the test data is selected to test every bit of code or module. This
requires a detailed knowledge of the codes to be tested. Since the emphasis of the tests is
the individual codes, the test data may be illogical when compared with the program
specifications.

Test for logical and cyclic errors of the code.

As with black box testing, the code is said to have passed the test if the actual and
expected results agree.
Alpha and beta testing

45
 - Are acceptance tests conducted to enable the customer to validate all
requirements.
- Alpha testing is conducted at developers site by a customer. The customer uses
the software with the developer and recording errors and usage problem.
- It is conducted in a controlled environment.
- Beta testing is conducted at one or more customers site. It is a live testing in an
environment not contolled by the developer. The customer records and reports
difficulties and errors.

 File Conversion

 Conversion is the process of changing existing files into a format suitable for
the new system. Example conversion of the existing master file in to a
magnetic file.

Master file Conversion

 The objective is to maintain the accuracy and completeness of existing data

while creating the new data entities required by the new system.
 The existing master files are converted into a magnetic form
 Though it depends on the method currently used for keeping the files the steps
are
i. Record the old file data on specially designed input documents by clerical
effort
ii. Transcribe the completed document to a suitable media.
iii. Verify the data to ensure it is error free.

System Changeover

 Refers to the activities necessary to transfer operations from the old to the new
system.
 The factors to consider when choosing a change over method are
i. Maintenance and operation of the new system
ii. Method of controlling errors

46
 iii. Method of monitoring and evaluating the results of the system change
over
iv. Necessary communication required during the system changeover
v. Types of personnel responsible.

Methods.
1. Direct Changeover

 Places the new system in operation and immediately ceases operation of the
old one.

 Appropriate when the

i. Old system has no value i.e. has many weaknesses

ii. The new system design differs so much from that of old system.
iii. The system is not replacing any other system
iv. New system is small or simple
 Benefits:
i. Avoids the cost of inconvenience of the other approaches i.e it is less
expensive
ii. it is viable for non-critical systems that involve simple processes and few
people.

 Drawbacks:
i. it is extremely risky if the new system fails.
ii. Places the organization in a do or die situation

2. Pilot

 Installation of the entire new system but implement first within a limited
segment of the organization. The new system is introducer in piecemeal to
different departments at a time until the entire system is converted.

47
  Benefits:
i. Unexpected problems can be corrected before introducing the new system
throughout the organization.
ii. Allow system to be implemented quickly
iii. Less costly
iv. Causes minimum disruption
v. Allows for training of personnel in the new system

 Drawbacks:
i. a system works well in one department may not work as well in others.
ii. Problems on ensuring that the part of system is implemented and
converted.

3. Parallel

 Processes actual data on both the old system and new one. Both systems run
simultaneously in order to ex-check the results.

 Benefits:

i. it is the safest approach since entire system is cross checked.

ii. Provide a method of training in the new system
iii. Personnel become familiar with the new system prior to the actual “cut
over”.
iv. Old system is on a standby in case of new one fails in initial stages.

 Drawbacks:
i. it requires all operations be performed twice, thus it doubles the employee
workloads.
ii. Additional cost of running two systems
iii. Cross checking is difficult and taxing

48
 iv. If employees are not enough, then more staff needed for training

4. Phase-in

 Implement portions of the new system one at a time until the entire new
system is functioning properly.
 Benefits: limits the problems that can arise during changeover to those
associated with the current portion of the system.

 Drawbacks: Not many systems allow phase in changeover. For example: ad

hoc reporting and data entry change simultaneously and in this case the design
team must convert all procedures at the same time.
NB/ Both Pilot and Phased share same benefits and drawback.

Direct Changeover Parallel Operations

Old System
Old System New System

New
System

Phase In Pilot System

1 2 3 1 2 3
Old System

New
System Ol Ol Ol Ol Ol N
d d d d d e
w

49
 1 2 3 1 2 3

Ol N N N N N
d e e e e e
w w w w w

Post-implementation
- The activities which take place immediately after the implementation. cutover are
onsite support and the post-implementation review (PIR).

(a) Onsite support

- Initial teething problems are expected and the IT professionals should provide onsite
assistance to users.

(b) Post-implementation Review (PIR)

- The system is evaluated to ascertain its performance relative to its objectives.
- The post-implementation review is an evaluation of both the process and product
quality.
- The strengths and weaknesses of the system are discussed with a view to improving
it. Similarly, the process of its development, the SLDC, is reviewed with the
intention of learning from mistakes.
- Also helps to
 Confirm if planned objectives are being met and take approppriate action.

50
  Ensure that the system is able to cope with the changing requirement of
organization
 Provide information about system development and design which may be
beneficial to future projects.
-
- System review report
- The results of a system review would be used for system maintenance. Normally the
management, I.T department, users and auditors meet to review the system and come
up with the report. The report incudes
I. Introductory summary of the parts of the system which have poor
peformance.
II. Details of whether the systems objectives are still the same and whether
are being met.
III. Level of errors experienced by the system
IV. Changes which have been experienced e.g environment, organizational
policy and government laws
V. Whether the system is easy to use.
VI. Whether the system is taking advantage of latest technology
VII. Whether the security of the system are sufficiently tight
VIII. Report on the cost-benefit appraisal showing how actual cost and benfits
compare with the anticipated ones.
IX. Recommendation on how the system can be improved in order that any
short comings can be rectified.

Maintenance
- Maintenance is the ongoing process of monitoring and evaluating the new system.
- Involves identifying the need for change in the current system and making
appropriate change due to change in technology.

Types of Maintenance

51
 1. Corrective maintenance: This type of maintenance deals with fixing or
correcting problems with the system. I.e. Problems that were not
identified during the implementation phase. An example improper
functionality of the system.

2. Adaptive maintenance: This refers to the creation of new features or

adapting existing ones as required by changes in the organization or by the
users, e.g., changes on the organization's tax code or internal regulations.

3. Perfective maintenance: It deals with enhancing or improving the

performance of the system either by adding new features or by changing
existing ones. An example is the conversion of text-based systems to GUI
(Graphical User Interface).

4. Preventive maintenance. This is the maintenance to avoid major problems

with the system. An example of this maintenance is the correction for the
year 2000.

Problems of maintanance
 Many systems developed by consultants and software houses do not have
source code made available to the organization
 Maintenance work requires extra training of the personnel to do the job e.g
programming and operating system
 Can cause more failures especially if documentation is poor.

Maintenance activities can be divided into three categories: perfective, adaptive,

and corrective, as follows:
Perfective Maintenance
Looks on changes, which improve the system in some way without changing its
functionality. I.e. includes all efforts to improve the quality of the software.
Involves restructuring code, creating and updating documentation, improving
reliability or efficiency.
Perfective maintenance is generally performed as a result of new or changing
requirements, or to fine-tune the documentation.

52
 Fine-tuning is an excellent way to introduce a new writer to the documentation,
while reducing the probability of serious errors in the future.
Adaptive Maintenance
Is maintenance, which is required because of changes in the environment of the
program.

 includes all work related to how the software functions

o i.e. relates to enhancing software functionality
 includes all changes to meet the evolving needs of the user and the environment
o i.e. system changes, additions, insertions, deletions, modifications,
extensions and enhancements

Equipment configurations, such as, new computers, new terminals, local printers,
etc., usually to take advantage of improved features and/or pricing; normally
performed on a scheduled basis.

Data formats, file structures, etc.; may require extensive maintenance if same
were not properly designed and implemented. If changes are isolated to specific
modules, they may have less impact, if not, the effort can be both lengthy and
costly.

Corrective Maintenance
Is the correction of previously undiscovered system errors.

 It focuses on fixing defects

 is a reactive process
o i.e. defects generally need to be corrected either immediately or in the near
future
 Defects refer to the system not performing as originally intended or as specified in
the requirements

There are three main causes requiring corrective maintenance:

53
  Design errors. Incomplete or faulty design due to incorrect, incomplete, or
unclear descriptions, or when the analyst does not fully understand the user's
needs.
 Logic errors. Invalid tests, assumptions, instructions, and conclusions; faulty
logic flow, incorrect implementation; usually attributable to the designer or
previous maintainer. Often logic errors occur when user instructions and/or
unusual combinations of data are not tested during development or maintenance.
 Writing Errors. Incorrect implementation or design logic or incorrect use of
special terms; caused by the writer. While they may be errors of negligence or
carelessness, they are usually the easiest to fix.

System Documentation
.
- This is a written record of all the steps taken during system development process.
It acts as an operational, reference and users manual for the installed system.
- Includes all the documents describing the system itself from the
requirements specification to the final acceptance test plan.
- Documents describing the design, implementation and testing of
a system are essential if the program is to be understood and
maintained.
- System documentation should include:
1. The requirements document and an associated rationale.
2. A document describing the system architecture.
3. For each program in the system, a description of the
architecture of that program.
4. For each component in the system, a description of its
functionality and interfaces.
5. Program source code listings. These should be commented where
the comments should explain complex sections of code and provide a
rationale for the coding method used.
6. Validation documents describing how each program is validated and
how the validation information relates to the requirements.

54
Porpose of documentation
 Acts as a communication tool: Communicate facts about the system to
users
 Aid to maintenance: Provision of all neccesary information to allow
corecton or mintenance of the system or its programs
 Aid to understability of the system: Provision of operating instruction to
user and operaters
 Aid of training: For training of new staff
 Aid to development process: Acts as a reference material for the system

Qualities of a good documetation

i. Availability- shoul be accessible to the intended users.
ii. Objectivity- must be clearly defined in a language that is easily
understood

CONTROL & AUDIT

INTRODUCTION
The owners of the organization may be interested in the control of the system and to look
after their interest they appoint auditors who examine and report upon the efficiency of
the whole system.
Types of Controls.
In a computer environment four elements must be controlled namely
Source documents, input, processing and output

SOURCE DOCUMENT CONTROL

1. The source documents used must be accounted for.

2. Ensure that the entire source documents are authorized and any changes to
the source document are authorized.

55
INPUT CONROLS
 To Ensure there has been a complete and accurate conversion from the
source document to the input media
 are composed of
1. Transaction code (in any organization , data represent people not
events, assets, object etc)
2. Form design:-the form can be designed to force more legible entries
by use of the individual blocks for each character to be recorded.
3. Verification : source document can be proof read by another clerk to
improve accuracy
4. Control totals: are prepared for specific batches of data to minimize
loss of data when transported from one location to another.
5. control total: are prepared for specific batches of data minimize loss of
data transported from one location to another
6. Other control: use check digit for important code such as acc No

PROCESSING CONTROLS
 These are procedures incorporated in the programs to ensure there is
complete and accurate processing of the data that has been entered into
the system.
 An edit run Test that consists of a series of checks is created. E.g.
program checks
 Arithmetical accuracy is performed by limit checks and overflow tests.
 Checks are made to ensure that the correct files are being proceed.

OUTPUT CONTROL
Output control are established as final checks on the accuracy and completeness of
the processed information . The following control procedures are related to output.
1. Output should be immediately be rooted to a controlled area and distributed
only by authorized person.

56
 2. Output control totals should be reconciled to input control totals to ensure that
no date has been changed lost or added during processing or transmission
3. All vital forms (e.g paychecks passbook etc) should be pre-numbered and
accounted for
4. Any highly sensitive output that should not be accessible by computer
centre should be generated via an output device in a secured location.
5. screening conducted to detect errors
 Control of errors wound be part of output control which should specify
how error should be handled
Other controls are
1. Organizational control
 Control to ensure that proper segregation of duties in computer department
and that they achieve the appropriate specialization required for operation
efficiency.
2. Documentation control
 It shows the managers, auditor, users on how the system is supposed to be and
how it should perform.
3 Management controls
 concerned with system planning and evaluation of the system performance
from both the equipment and personnel
4 Sociological control
 Ensure that computerization do not dehumanize the staff
5 Technological control
 Is meant to eliminate the unfair deal of acquiring less competitive
equipments.
6 Environmental controls. Ergonomics effects.
 The computer room has to be dust free, the correct temperature has to be
maintained and should also have the correct power supply without power
interruption
Objectives of system development control
1 To ensure that only beneficial systems are developed

57
 2 To ensure that suitable operations and administration control are built in system
design
3 Ensure users acquired the understanding of the new system
4 Ensure the system is properly tested
5 Ensure proper documentation is maintained
6 Ensure system and program are well maintained

Auditing
Auditor:-is a person who determines whether or not an organization assets are properly
protected.
 For it to be successful the auditor should be familiar with
a) Organization and responsibilities of the I.T department
b) Data correction and validation techniques
c) File organization and processing techniques
d) System controls
e) Methods of control of system, development, programming and
operation activities
Audit Objectives
1 Ensure that an adequate system of controls is implemented and used.
2 Determine whether resources are being used in a cost effective manner.
3 Check to see that assets are properly safeguarded and used in a proper manner.
4 Review the integrity, reliability and efficiency of the information system and the
financial report it produces
Auditing techniques
The three most common methods of auditing in a computer are
I. Auditing around the computer
II. Auditing through the computer
III. Auditing with the computer

Auditing around the computer

58
  Concentrates on review of inputs and output documents and disregards
the way in which such results are achieved by processing (“the computer
is viewed as a block box”) thus auditor do not review the computer
system and program.
 The auditor select input and compare them against the appropriate
output and the vice versa if they matched and proved to be accurate its
assumed that the system of controls is operational and working properly
 The technique is adopted if
I. The system is such that adequate check can be made without examination of
computer processing.
II. Auditors knowledge of data processing is insufficient for him to carry out an
effective audit.
Advantages
I. There is little risk in tampering with the live data
II. Little technical training of the auditor is required
III. It is simple straight forward and easily understood
IV. Cost of audit resources are generally low
Disadvantages
I. Many computer system are voluminous for proper manual testing
II. No means are provided by which the auditor got involved and gain firm
understanding of the computer system
III. It ignores the system of controls and thereby fails to recognize potential errors and
weakness within the system
IV. It does not make use of the computer
V. It does not really achieve the auditors goals

Auditing through the computer

 The technique place a greater emphasis on testing the computer system
that produces the output rather than testing the output its self
 It require two basics accomplished i.e
1. Review and verification of the source transaction

59
 2. Actual testing of computing programs ,logic and programmed
control
One of the key tool in applying this technique is the preparation of a series of test
transaction referred to as test deck or test packs :-it include both valid & invalid
transactions.
Advantages
1. Help auditor become more involved in the system
2. Works as an aid in making compliance tests and aid in the evaluation of the
programmed controls
3. increase services to client since controls and operation are checked
4. Test results are readily identifiable and can be as a measure of internal proceeding
reliability.
5. utilized the computer as a tool
Disadvantage
 Require computer time
 Require more technique knowledge
 Represents only a limited test of the system test deck

Auditing with a computer

 The auditor uses the computer to assist them in various auditing task.
 Auditors use standard software packages known as audit packages
 The packages are essentially file-processing program. The main
facility available are:-
1. verification of file controls
2. verification of individual balances in records
3. verification that all necessary data are present in records
4. selection of records according to parameters specified
by the auditors eg
 Random sample of a given % of the file

60
  Data outside specified limit e.g overdue
acc. ,non-active records, payment above certain
values etc
5. Analysis of file contents e.g depts. or type of customers,
payments by size or by type and stock holdings by
value
6. Comparison of two files (reporting any differences )to
verify the accuracy of file maintenance.

SYSTEM OBSOLESCENCE
- An obsolete information system is one that has reached the end of its
economically useful period and should be replaced by another information system
- or one that is not used because its function are no longer required by the end
users, or the hardware, software on which it depend become out of date
Sign of a system which is nearing the end of it economic life
1. High cost in maintenance of the system
2. Increased operation costs and lags in execution times
3. A software package is available that will provide the same or additional services
as well or better than the current system
4. New technology developments in hardware provide a means to perform the same
services in a more efficient manner
5. When the users define additional requirements that cannot be easily
accommodated in the existing system

Project failures
Project failure is the worst experience for a system analyst, though not without a good
experience, such as experience should be avoided in future.
An information system project is said to have failed if
1. The resulting information system does not meet the end users needs.
2. If the cost exceed the budget
3. If the deadline for system development is not met

61
Causes of project failures
When finally a project fails the likely causes include
1. Unidentified requirement or lack of proper objective.
2. Poor design choices.
3. Insufficient testing or inadequate testing procedures.
4. unrealistic end user expectation
5. Schedule delays due to unanticipated factors.
6. Poor monitoring and control of progress
7. Personality conflict among the team members
8. Insufficient feedback and feed forward
9. Lack of user participation.
10. Lack of management support.

Review questions
1 An important aspect of input and output design is Form design. List five
factors that should be considered in Form design.

2 A system is not complete without a proper documentation

(i) Define the term documentation
(ii) Outline FOUR major forms of documentation
3 With reference to system implementation
i. Define the term system testing.
ii. Outline Two type system testing
iii. Explain any TWO types of system conversion
4 Explain the following terms as used in systems design quality

i) Correctness
ii) Integrity
iii) Maintainability

62
 5
(i) Define the term maintenance
(ii) Describe the three types of maintenance
(iii) Outline the four problems of maintenance
6
(i) Explain the term system obsolescence
(ii) List any six causes of project failure
7 The outcome of a complete system design is a system specification
i. Outline FOUR functions of the document
ii. ii Explain the contents of system specification

iii. Outline the personnel’s to whom it is forwarded

8 Yawezekana Hardware is a bussiness which deals with sales of Vehicles

spareparts. The sales department produces invoices every week for the customers. Draw a
system flowchart for the sales department, given that most customers are active each
week but relatively few parts are sold in each period.

- Site preparation. Involves putting up new structures that will accommodate the system.
- System testing. Examples.
- Stress testing. Testing whether the system can handle situations with a lot of work.
- Functionality testing. Does the intended
- Usability testing. Whether it can be used easily by all users
- User training. Orientation of the users to give them confidence and minimise data
entry errors.
- File conversion. Converting existing files in to a format suitable for the new system.

Other approaches of system Methodology.

Waterfall model

63
 The Classic Life Cycle

- Refered to as the Waterfall model which demands a systematic and sequential

approach to software development.
- It presents a highly structured method of software development that starts at the
system level, and progresses through analysis, design, coding, testing and finally
maintenance.

 Systems Engineering:

-Involves establishing software specification requirements for all system

elements.

 Analysis:

Involves understanding and specifying in detail what an information system should do.

- The purpose of systems analysis is to provide an overview or detailed pictures of

the operations in an organization

64
 Design:

Involves specifying in detail how the parts of an information system should be

implemented

 Coding: design is translated to machine readable form

 Testing: focuses on the logical internals of the software.

 Implementation/Maintenance: Putting the system in to use

Spiral model.

65
- The spiral seeks to improve on the waterfall model and other models by combining
their useful features combining some characteristics of the waterfall and prototyping
approaches.

- Takes the form of a spiral and includes a well defined risk analysis activity.

- Each loop in the spiral represents a phase of the software process

- The innermost loop may be for system feasibility

- Second loop for system requirement definition.

- Third loop for system design

- Fourth loop for implementation and testing etc.

Each loop is divided into four sectors as follows

- Objective setting. Specific objectives for the phase constraints for the process and the
products are identified. A detailed management plan ids drawn for the phase.

- Risk assessment and reduction. In this stage of the loop, project risks are identified,
for each detailed analysis is carried out, steps are taken to reduce risk.

- Development and validation. A development model is chosen. Work on the phase

commences based on the model chosen.

- Planning. The project is reviewed and a decision made on whether to continue with a
further spiral in the model. If to continue plans are drawn up for the next phase of the
project.

66
 Cumulative
cost

Progress
through
Determine steps Evaluate alternatives,
objectives, identify, resolve risks
alternatives,
constraints
(OAC) Risk
Assessment
Concrete
Specification
OAC Risk
Assessment
Abstract
Specifcation
OAC Risk Risk
Requirements Assessment Control
Risk
OAC Control
Risk
Commit Control
Review
partition Requirements
Concept of
Plan
Operation
Requirements
Abstract Specification Abstract
Plan Specification Concrete
Requirements Specification
Validation
Concrete Specification
Plan
Abstract Specification
Validation

Software Concrete
Plan next phases Development Plan Specification Validation Develop, verify
and Verification next-level product

67
 Risk
Assessment Req. Change
Requirements Risk
Assessment
Verify
Design
Risk
Assessment
Verify Implementati
on
Test
Adds a Risk
Analysis
step to each phase Operations

Retirement

Prototyping.

Prototyping Paradigm

An experimental approach of software development where the software developer

and customer agree that the prototype defines all users’ requirements .

68
 A prototype is only a working model that is refined un till it meets all users
requirements.

 Requirements gathering: developer and customer meet to define

overall objectives of software.

 Quick Design: quick implementation of these aspects of the software

that will be visible to user.

 Build prototype: design of the prototype.

 Evaluate and Refine Requirements: analysis of prototype;

refinement.

 Engineer product

SSADM

69
STRUCTURED SYSTEM ANALYSIS AND DESIGN METHODOLOGY (SSADM)
Is a data driven methodology whose objectives is to provide tools and procedures which enable
production of computer systems which provide what people want, robust and capable of
amendments to cope with future changes.
Consists of six phases each subdivided into sub-phases

1) Analysis (investigation) of current system

 Carry out detailed investigation
 Create current data flow
 Create ideal current data flow
 Create logical structure overview
Generally the current operational system is investigated and problems identified. e.g system
shortcomings, users dissatisfaction etc. The traditional techniques of fact gathering are used here.
DFD’s and ER-models of the current systems are constructed followed by identification of new
services requested by users and some of the options that might be available in the new system.
Finally an ideal model of the present system is constructed and agreed with the users.
In case there is no current system, the environment for the new system is studied. By the end of
the phase, a general understanding of what happens, system strengths and weaknesses and and
overview of possible options of new system.

2) Specification of the required system

 Extend logical data structure overview
 Create required data flow
 Define process outline
 Define audit control and security
Generally the logical view of an ideal current system is extended to include the new requirements
of the users.
The logical view looks at data and processes aspects and includes requirements for audit, security
and system controls.
The view is documented as a brief explanation of the aims and services of the new system in
general terms.

3) Selection of technical system

 Create user options

70
  Assist user in selection
 Set performance objectives
This phase can be carried out either as part of feasibility study or as a full study.
In a feasibility study the various options for implementation are presented to users which include
options such as a centralized, distributed batch processing or online system.
In a full study, the options tend to be more detailed as users are made aware of the implications of
any option on issues such as staffing levels and skills, other resourses required, standard of
service provided etc.

4) Detailed data design

 Carry out Normalization
 Create detailed logical data structure
 Build composite data structure
 Define 1st cut physical data structure.
In this phase data and data relationships are defined in detail to ensure the model support the
process.
This process looks at the data requirements implied by screen formats, report layouts and input
forms, selected by users.
A composite logical design (Third Normal Form and Logical data structure) is produced and then
converted to a “first cut” or database design which is the mapping of the physical data structure.
The information is described in a Data dictionary.

5) Detailed procedure design.

 Carry out physical design
 Design manual procedures
From the chosen version of the system to be implemented, the the required functions are
cataloged and checked against the CLD so ss to ensure that the logical design will meet all the
systems requirements.
A prototype version may be developed at this phase.

6) Physical Design
 Design system test plan
 Create program specification
 Create operating schedule

71
  Create file and database definitions
 Write user manuals
This phase is concerned with the production of a plan for building and testing the system,
program specifications, operating procedures and file layouts.
These aspects are analyzed on papers and verified to maximize performance before developed on
computer. Alternatively the prototype in (5) is developed so that it conforms to acceptable
performance criteria.
Lastly documentation is consolidated and checked for completeness. This includes test plans,
operation guides, implementation plan and user guides.

NB/ SSADM is expected to be used along with general computer CASE tools eg 4GL.s packages,
auto-mate and data-mate which help in drawing ER-models, DFD’s and data dictionary. It
recommends quality assurance reviews based on structured walkthrough.

72