SYSTEMS ANALYSIS AND DESIGN NOTES

CHAPTER 1

SAD: It is the process of designing, building and maintaining information systems (Computer programs).

The individual who performs this task is called system analyst or software engineer.

Terms definition

System: it is a set of components that work together to achieve a common goal or objective

Information system: (software) it is a set on inter-related components or technologies that collect or

retrieve, process, store and distribute information to support decision making and control in an
organization.

Data: it is a collection of raw facts, figures and symbols which must be arranged or processed in order to
be meaningful.

Examples: names of students and their marks in different subjects listed in random order.

Name of employees and hours worked.

Information: it is data which has been processed to a point where it conveys knowledge and represents a
usable statement

Examples: when the names of students are arranged in alphabetical order, total and average marks are
calculated and represented in tabular form.

Information technology (IT): It is the study, design, development, implementation and management of
computer based systems, particularly software applications and computer hardware.

CHAPTER 2

SYSTEMS THEORY

System: It is a collection of objects or components that work together to realize some objectives.

Subsystem: it is a system within a system.

This means that systems exist on more than one level and can be composed of subsystems.

Example: software consists of modules (subsystems)

 SYSTEM

Subsystem A Subsystem B Subsystem C

Subsystem A1

Subsystem A2

Components/elements of a system

 Resources
 Procedures
 Data/information
 Process

Resources

They can be hardware, software or live ware

Hardware resources may include: the computer, its peripherals, stationery etc.

Software resources include the programs running on the computers

Live ware resources include people required to operate the system and make it functional.

Procedures

Every system functions under a set of rules that govern the system to accomplish the defined goal of the
system.

The set of rules define the procedures of the system.

Example: Banking systems have their pre-defined rules for providing interest at different rates for
different types of accounts.

Data/information

To achieve goal/objectives the system requires certain input which is converted to the required output.

Processes
Systems have processes that make use of resources to achieve the set goals under the defined
procedures.

These processes are the operational elements of the system.

Characteristics of a system
A system has 9 characteristics.
 Components
A system is made up of components. A component is an irreducible part or aggregation
Of that make up a system, also called subsystems. We can repair or upgrade the system by changing
individual components without having to make changes throughout the entire system.

The components are interrelated. This means the dependence of one subsystem on one or more
subsystems. The function of one subsystem is tied to the function of others.

 A Boundary
A system has a boundary within which all of its components are contained and which
Establishes the limits of a system, separating the system from other systems. The boundary is the line
that makes the inside and outside of a system and that sends off the system from its environments.
 A purpose
This is the overall goal or function of a system. A system must give priority to the objectives of the
organization as a whole as compared to the objectives of a subsystem.
 An Environment
This is everything external to a system that interacts with the system i.e. everything
Outside the system’s boundary, usually the system interacts with its environment, exchanging, in the
case of an information system, data and information.
 Interfaces
This is the point of contact where a system meets its environments or where subsystems
Meet each other. E.g. The interface between an automated system and its users (manual system) and
interfaces between different information systems. It is the design of good interfaces that permits
different systems to work together without being too dependent on each other. Because an interface
exists at the point where a system meets its environment, the interface has several special, important
functions outlined below:-
i. Security - protecting the system from undesirable elements that may want to infiltrate it.
Filtering unwanted data both for elements leaving and entering the system.
Coding and decoding incoming and outgoing messages.
Detecting and correcting errors in its interaction with the environment.
ii. Buffering - providing a layer of slack between the system and its environment, so that the
system and its environment can work on different cycles and at different speeds.
iii. Summarizing raw data and transforming them into the level details and format needed
throughout the system.

 Constraint/ Controls
This is a limit to what a system can accomplish. A system must face constraints in its
Functioning because there are limits – in terms of capacity, speed, or capabilities to what it can do and
how it can achieve its purpose within its environment.
  Input
This is whatever a system gets from its environment, e.g. raw data.
 Output
This is whatever a system returns to its environment in order to fulfill its purpose

Classification of Systems

1) Open Systems
These are the system which are connected to and interact with the environment. Examples are, the
biological and social system. All business organizations are also open systems since they must have the
capacity to adopt in the future of changing competition, changing markets etc.

2) Closed Systems
A closed system is that which does not interact with its environment. The system is neither influenced
by nor influences its environment. It does not take in from or give to it. The system behavior occurs
because of internal interaction and is more relevant to scientific than social systems. They do not obtain
modification from their environments. A computer program is a relatively closed system because it
accepts only previously defined outputs. In fact, no system can be a completely closed system for a long
time.

Difference between Open Systems and Closed Systems

Open System Closed System

- Interacts with the environment constantly - Does not interact with the Environment
- Has infinite scope - Limited Scope
- Relevant variables keep on interacting - Self Contained
- Flexible and abstract - Rigid and mathematical

3) Abstract systems
These are conceptual. They are not physical entities. They maybe formulas, representation or model of a
real system.

4) Deterministic Systems (Mechanistic Systems)

These are the systems that function according to some predetermined procedure and have results and
future behavior predicted with certainty provided they are working correctly and under control.

5) Probabilistic Systems (Stochastic Systems)

These are those systems which operate on probability. State and behavior can be predicted only within
certain limits, even when they’re under control.
Cybernetic system (Self Organizing/ Adaptive)
These are systems that have to adapt to their environments/ react to stimuli, they learn from their
mistakes, so that they do not always react in the same way to a particular input. Examples are the social
systems, organizations, plants.
6) Open – Loop System.
This is a system which does not act in a controlled manner, i.e. no feedback, and so no measure of
performance against standards.
7) Closed – Loop System
A system that functions in a controlled manner e.g. A system accepts inputs, work upon them according
to some pre-defined processing rules, and produces outputs, so that it can function in a controlled
manner, must give feedback
8) Artificial Systems
These systems are created rather than occur by nature e.g. computer programs, organization, etc.
They are usually made to support the objective of the designer and user.

SYSTEM PROPERTIES

 Hard properties

These are attributes that enable data to be measured .e.g. Cost of an item, number of employees in an
organization etc.

Often engineering or science data has hard properties that can be measured.

 Soft properties

Are attributes that are not capable of precise measurement e.g. there is nothing an individual can use to
say a material is attractive

Often, social and political data have soft properties.

 Hard systems

Problem has a definite solution/specific solution

 Soft system

There are infinitely many ways to solve the problem. Problem cannot be specified precisely.

Information systems

It is a set of interrelated components or elements that collect, process, store and distribute information
to support decision making and control in an organization.

A computer based information system is an information system that uses computer technology to
perform some or all of its intended tasks.

Activities of information systems

 Entering data into the information system(input)

 Changing and manipulating the data in the information system(data processing)
 Getting information out of the information system(output)
 Storing data and information(storage)
 STORAGE

INPUT PROCESSING OUTPUT

FEEDBACK

COMPONENTS OF AN INFORM ATIONSYSTEM/INFORMATION SYSTEM RESOURCES

All information systems consist of five major resources:

 People resources
 Hardware resources
 Software resources
 Data resources
 Procedures
 Network resources

People resources

They include end users and information system specialists

End users are people who use an information system or the information it provides. They can be
customers, sales persons, clerks or accountants

Information specialists are people who develop and operate information systems. They include system
analysts, software developers, database designers and system operators.

System analysts design information systems based on information requirements of end users.

Software developers/programmers create computer programs base on specifications of system analysts.

System operators help to monitor and operate large computer systems and networks.

Hardware resources

They include all devices and materials used in information processing

Hardware includes computers, printers, data media on which data is stored etc.

Software resources

Software includes system software such as operating system and application software.

Data/information resources

Data can take many forms including alphanumeric data, numbers, letters, images/pictures and other
characters that describe business transactions.

Procedures

Every system functions under a set of rules that govern the system to accomplish the defined goal of the
system.

Network resources

Telecommunication networks consist of computers, communication media and network infrastructure.

QUESTIONS

Disadvantages to expert systems, such as:

 No common sense used in making decisions.

 Lack of creative responses that human experts are capable of.
 Not capable of explaining the logic and reasoning behind a decision.
 It is not easy to automate complex processes.

The System Owner is a key contributor in developing system design specifications to ensure the security
and user operational needs are documented, tested, and implemented

A systems analyst is an information technology (IT) professional who specializes in analyzing, designing
and implementing information systems.
 CHAPTER 3
TYPES OF INFORMATION SYSTEMS

 Transaction processing systems(TPS)

It is a computerized system that performs and records the daily routine transactions necessary to
conduct the business.

These systems serve the operational level of the organization

A business can have several transaction processing systems examples are stock control system, inventory
system, billing system, order tracking systems.

They are used by operational level employees to help them make structured decisions.

 Knowledge management system(KMS)

These are systems designed to help businesses create and share information.

They are used in a business where employees create new knowledge which can then be shared with
other people in other organization to create further commercial opportunities. E.g. AUTO-CAD, Arch-
CAD.

 Management information systems(MIS)

It is an information system at the management level of an organization that serves the functions of
planning, controlling and decision making by providing routine summary reports.

They take data from TPS and summarize them into a series of management reports. They make semi-
structured decisions.

 Decision support systems(DSS)

It is an information system at management level of an organization that combines data and sophisticated
analytical models to or data analysis tools to support semi-structured and unstructured decision making.

A decision is considered unstructured if there are no clear information or procedure for making the
decision.

Components of a DSS

-data management component

Performs the function of storing and maintain information the DSS uses.

-user interface management component

It allows the user to communicate with the DSS.

-Knowledge management component

Provides information about relationships about data that is too complex for a database to represent.

Characteristics of a DSS

 DSS offers users flexibility, adaptability and quick response.

 DSS operate with little or no assistance from professional programmers.
 DSS provide support for decisions and problems whose solutions cannot be
specified in advance.
 DSS use sophisticated data analysis and modeling tools.
Group Decision Support System (GDSS) is a type of a DSS that helps a team of
decision makers to solve problems.
 Executive support system(ESS)/Executive information system(EIS)

An information system designed to help senior management to make strategic decisions.

It is used at strategic level of organization to assist in making unstructured decisions.

They gather, summarize and analyze the key internal and external information used by the business.

 Expert information systems

It is a computer based system that emulates the decision making ability of a human expert.

They are designed to solve complex problems by reasoning about knowledge like an expert and not by
following the procedure of a developer as in the case in conventional programming.

Benefits of expert systems

-preservation of knowledge: Expert systems preserve knowledge that might be lost through
retirement, resignation, or death of an expert or acknowledged person in a company.
-it is not subject to human feeling such as fatigue, being too busy or emotional.
-an expert system can effectively be used as a strategic tool in the areas of marketing of
products, cutting costs and improving products

Disadvantages of expert systems

-knowledge designing problem: enormous amount of time and effort is required to extract the expert
knowledge and translate it into IF/THEN rules upon which an expert system is based.
-programming problem: programming the system and monitoring the source code is very difficult

-judgment problem: an expert system cannot apply judgment which is an important ingredient for
problem solving. It has no common sense or judgment.

 Geographic information system(GIS)

It is an information system designed to capture, store and manipulate, analyze, manage and present all
types of geographical data. Example Google earth.
Executive support
Figure below shows the relationship between the different systems:
system (ESS)

Management systems Management systems

(MIS) (DSS)

Knowledge systems Transaction

(KWS and OAS) processing system
(TPS)
 CHAPTER 4

INFROMATION SYSTEM STAKEHOLDERS

Roles of information system stakeholders

 System owners or sponsors

Providing clear requirements and expected project outcomes to the development team

Reviewing and approving project tasks, plans, budgets and schedules.

Reviewing and approving scope of work.

Authorizes the system to be used.

 System users/end users

Provides source information to the development team.

Provides expert business understanding of the organization

Review and confirm major SDLC work products for the project (system development life cycle)

Participate as required in user acceptance testing activities.

Benefits of user involvement

 Improved quality of the system arising from more accurate user requirements
 Acceptance of the system
 When users are involved in system development, they are more likely to accept it than reject it.
 Short training period: There is greater understanding of the system by users resulting in more
effective use.
 System analyst
 Collects information to analyze and evaluate existing or proposed systems.
 Prepares detailed flow charts and diagrams outlining systems capabilities and processes.
 Prepares and maintains system documentation
 Conducting technical research on system upgrade, define feasibility, cost, time required and
compatibility with current system.
 Documenting system problems for future reference.
 Skills of a system analyst
 Problem solving skills.
  Leadership qualities.
 Good communication skills.
 System developer/programmer
 Converting software specification requirement into appropriate programming languages.
 Writes and tests the source code.
 Observing, testing, diagnosing and fixing faults in the software.
 Training system users on how to use the system.
 Modifying and updating the system.
 Software project manager
 Creating clear and attainable project objectives.
 Management of the team. The software project manager co-ordinates software development
activities.
 Controlling budget, confirms resources are within budget.
 Performance monitory: monitors performance against the plan.
 Approves project deliverables.

CHAPTER 5

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

Meaning

SDLC is a set of activities that system analysts, designers and users carryout to develop and implement
an information system

Activities are closely related and usually inseparable.

Each phase of SDLC uses results of a previous stage.

Stages/phases of SDLC

Preliminary system
study/preliminary investigation

System Feasibility study

maintenance

System System analysis

implementation

System design
System testing
 System coding

Advantages of Waterfall Model

1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes

Advantages of SDLC

 Project management

Breaking down a project into phases has distinct advantages in that each stage can be specified, planned
and evaluated before moving onto the next stage.

 Documentation

SDLC tends to be associated with thorough documentation. Each stage has its own documentation
standards and this makes the quality assurance process much easier.

Disadvantages of SDLC

 Inflexibility

This is because SDLC has distinct sequential phases; it is regarded as inflexible especially for smaller
systems.

 Old fashioned

SDLC is associated with structured techniques and many of these have been found to be inappropriate
for today’s modern system.
SYSTEM DEVELOPMENT METHODOLOGIES

It is a formalized, standardized and documented set of activities used to manage system development.

It is also a framework used to structure, plan and develop systems.

Types of system development methodologies

i. STRUCTURED SYSTEM ANALYSIS AND DESIGN METHODOLOGY(SSADM)

SSADM is a set of standards for system analysis and application design. It is based on the waterfall
model.

Characteristics of SSADM

a) Division of project into sub processes with well-defined objectives

b) Activities are performed in a sequence
c) Diagrammatic representation and other useful modeling techniques are used. With SSADM, a
system is represented in form of diagrams before translating the diagrams into real working
software.
ii. OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN METHODOLOGY(OOSADM)

It is a software engineering approach that models a system as a group of interacting objects.

Each object represents some entity of interest in the system being modeled and is characterized by its
class, its state and its behavior.

Object oriented analysis applies object modeling techniques to analyze the functional requirements of a
system.

iii. RAPID APPLICATION DEVELOPMENT(RAD)

It is a software development methodology that has minimal planning in favor of rapid prototyping.

Planning of software developed using RAD is interleaved with writing the software itself.

The lack of extensive pre-planning allows the software to be written much faster and makes it easier to
change requirements.

PHASES OF RAD

 Requirements planning phase

This phase combines the elements of the planning and system analysis phase of the SDLC.

Users, managers and ICT staff members discuss and agree on business needs, project scope, constraints
and system requirements.
It ends when the team agrees on the key issues and obtains management authorization to continue.

 User design phase

Users interact with the system analyst and develop models and prototypes that represent all system
processes, inputs and outputs.

 Construction phase

This phase focuses on program and application development tasks similar to the SDLC.

In RAD however, users continue to participate and can still suggest changes or improvements as actual
screens, forms or reports are developed.

 Change over phase

This phase resembles the final tasks in the SDLC implementation phase, including data conversion,
testing, and change over to the new system and user training.

Advantages of RAD

 Reduced development time

This is achieved by rapid prototyping and by using automated tools like computer aided software
engineering tool(CASE tools) that enable the developer to re-use previously generated code thus saving
the time needed four manual coding.

 Reduced cost

RAD involves the use of existing re-usable components leading to lower cost of production.

 Better project management

In RAD, there is active participation of the management, the development team, as well as the business
owners and end users.

 Greater customer satisfaction

The RAD methodology involves active participation of the customers and end users in all stages of
analysis and development of the system.

Disadvantages of RAD

 Requires highly skilled developers/designers

 Depend on strong team and individual performances for identifying business requirements.
iv. JOINT APPLICATION DEVELOPMENT(JAD)
JAD is a methodology that involves the clients or end users in the design and development of an
application through a succession of collaborative workshops called JAD sessions.

Advantages of JAD

 Time saving

All stakeholders are usually in the same place at the same time with no outside distractions. This enables
the group to reach consensus on the requirements of the system much faster

 Cost saving

Reduced cost is as a result of faster analysis in design process.

 Ownership of the system

Due to the interactive nature of JAD, all issues and ideas can be discussed resulting in a system that
meets everyone’s expectations.

Disadvantages of JAD

 Time commitment

All JAD participants must be able to meet at the designated times and will need to suspend all other
activities for these periods.

 JAD commitment

JAD can only produce effective and productive results if the organization is firmly committed to the
approach.

Factors affecting choice of a system development methodology

 Well-structured problem situation with well-defined clear requirements can be handled with
traditional SDLC approach
 Unclear user requirements can be addressed by RAD through prototyping where a model of
proposed system can be presented to the user in order to assist in capturing and understanding
user requirements.

System development models/approaches

a) Waterfall model

Outlines the series of steps that should occur when building an information system.

The steps usually occur in a pre-defined order with review at the end of each stage before the next can
be started.
 Preliminary investigation or problem
definition

Feasibility study

System analysis

System design

Illustration.
System coding

System testing

System implementation

System maintenance and

review
Advantages of waterfall model

 Documentation is produced at every stage of waterfall model allowing people to understand

what has been done.
 It is linear (step by step) and therefore very easy to be implemented.
 After every major stage of coding, testing is done to check whether the code is running
correctly or not.

Disadvantages of waterfall model

 If any mistake happens in any stage developers may have to start from the beginning.
 It is not simultaneous. Several activities cannot be done at the same time.
b) Prototyping model

A prototype is a usable system or system components that is built quickly and at a lesser cost and with
the intention of being modified or replaced by a full scale operational system.

A prototype is an incomplete version of the software being developed.

Software prototyping refers to the activity of getting prototypes of a software application.

Prototyping process

 Identify basic requirements

In this phase, only fundamental system requirements needed to build an initial prototype are identified.

 Develop the initial prototype

The initial prototype is developed that enables users to interact with data entry, display forms, menus
and input forms.

 Review the prototype

Customers including end users examine the prototype and provide feedback on additions or changes.

 Revise and enhance the prototype

Using the feedback, both the specifications and the prototype can be improved.

If changes are introduced, then a repeat of step 3 and step 4 will be needed.

Diagrammatic representation of prototype model

Requirement Quick design Building

Start s gathering prototype

Final system Refining Customer

Stop prototype evaluation

TYPES OF PROTOTYPING

 Throw-away prototyping/close-ended prototyping

Throw away or rapid prototyping refers to the creation of a model that will eventually be discarded
rather than becoming part of the final delivered software.

A simple working model of the system is constructed to visually show users what their requirements may
look like when they are implemented into a finished system.

 Evolutionary prototyping

The main goal/objective when using evolutionally prototyping is to build a very strong prototype and
constantly refine it.

The prototype when build, forms the heart of a new system and the improvements and further
requirements will be based on it.

 Incremental prototyping
The final system is built as separate prototypes.

At the end, the separate prototypes are merged in an overall design.

Advantages of prototyping

a) Reduced time and cost

The early determination of what the user really wants can result in faster and less expensive software.

b) Improved and increased user involvement

It requires user involvement and allows them to see and interact with the prototype, hence allowing
them to provide better and more complete feedback and specifications.

c) Missing functionality can be easily identified.

Dis advantages of prototyping

d) Insufficient analysis/incomplete analysis

It can lead to overlooking better solutions, preparations of incomplete specifications or conversion of

limited prototypes into poorly engineered final system that is hard to maintain.

e) User confusion of prototype and finished system

Users can begin to think that a prototype intended to be thrown away is actually a final system that
merely needs to be finished and polished.

This can lead to them expecting the prototype to accurately model the performance of the final system
when this is not the intention of the developers.

f) Developers attachment to prototype

Developers can become attached to the prototype that offers a great deal of efforts producing and this
can lead to problems like attempting to convert a limited prototype into a final system.

g) Excessive development time of the prototype

If the developers lose track of the fact that they are supposed to develop a system very fast, they may
end up developing a prototype that is too complex.

c) Spiral model

It is an alternative systems development model in which the stages of analysis, design, coding and review
repeat as new features of the system are identified.
 d) V-model

Also called verification and validation model.

The testing activity is performed in each phase of software life cycle. The v-model shows software
development activities on the left hand side of the model and the right hand side of the model shows
testing phases activities.
 Product out phase

Project initiation Verified system

Requirements System integration and

specification testing

Integrated
System design
software

Software integration and

Detailed design
testing

Module design Debugged

modules

Code and unit

testing

e) Incremental model

With this approach, a model is designed, implemented and tested incrementally until the software is
completed.

CHAPTER 6

SYSTEM DEVELOPMENT LIFE CYCLE STAGES

 PROBLEM DEFINITION/PRELIMINARY INVESTIGATION

It is the activity of identifying the problem and understanding any constraints that may limit the solution.

Preliminary system study/investigation involves the preparation of a system proposal which lists the
problem definition, objectives of the study, and terms of reference for study, constraints and expected
benefits of the new system in the light of the user requirements.
The system proposal is prepared by the system analyst and places it before the management. The
management may accept the proposal and the cycle proceeds to the next stage or may reject the
proposal or request some modifications in the proposal.

TERM OF REFERENCE (TOR)

It is the document that describes an assignment for an individual or a team.

It helps one to know who initiated the project, objectives of the project and benefits of the project.

TOR is a document that acts as a reference throughout system development stages.

Contents of TOR

o Personnel involved
o Subject involved
o Available resources
o Estimated duration for developing the system.
o Estimated cost of development and implementation.
o Departments that are affected during system implementation.

PROBLEM STATEMENT

A problem statement defines a description of issues and problems that require to be solved.

Example

The college student registration system is unable to cope with the high volume of telephone calls
received at registration time.

Signals and long distance charges are the problem of the telephone registration system.

An online registration system needs to be developed.

Students on campus, off campus and out the country can easily and in expensively take advantage of the
many services provided by the college.

At the end of this phase, a preliminary study report or system proposal is produced and presented to the
sponsors for approval.

Reasons for introducing a new system

 The current system may no longer be suitable for it purpose.

Changes in work process expansion of the business, changes in business requirement or the
environment in which the organization operates may all lead to reassessment of information
system requirements.
 Current system may be too inflexible or expensive to maintain.
  Technology development may have made the current system outdated.
 FEASIBILITY STUDY

It is the measure of how beneficial the development of an information system will be to an organization.

It assesses the operational, technical and economic merit of the proposed system.

The aim of feasibility study is to understand the problem and determine whether it is worth proceeding.

Types of feasibility study

 Economic feasibility

It is a measure of the cost-effectiveness of a project.

It is an evaluation of all incremental cost and benefits.

 Technical feasibility

It means investigating whether the technology exists to implement the proposed system or whether
there is a practical solution.

It is a measure of the practicality of a specific technical solution and the availability of technical
resources and expertise.

 Operational feasibility

It is a measure of how well people feel about a system or a project.

It is a measure of how well a system will work in an organization.

Operational feasibility is concerned with whether the current work practices and procedures are
adequate to support the new system.

 Schedule feasibility/time

It is a measure of how long it will take the new system to become operational. It looks at how long it will
take to develop a system or whether it can be done in a desired time frame.

 Legal feasibility

Determines whether there is any conflict between the proposed system and the legal requirements.

Example: legal feasibility study, will determine whether the system violates data protection act.

 Social/behavioral feasibility

It is a measure of how the system will affect the behavior of people.

The completion of this phase is marked by the production of a feasibility study report produced by the
systems analyst.

If the report concludes that the project should go ahead and this is agreed by the senior managers,
detailed requirements analysis will proceed.

 SYSTEM ANALYSIS

It is the process of gathering and interpreting facts and using the information to recommend
improvements to the system.

It is also a process of examining business situation in order to develop a system to solve existing
problems.

Fact finding methods/techniques/data collection methods

1. Review of Written Documents: The first step to gather information of a system is to

Search and review the various forms of written documents such as professional references,
Procedure manuals, textbooks, company studies, government publications, consultant Studies, etc. of
that system.
2. On-site observations: The major objective of on-site observation is to get close to the
real system being studied. The methods used may be natural or contrived, obtrusive or
Unobtrusive, direct or indirect, and structured or unstructured. The main limitation of
observation is the difficulty of observing attitudes and motivation and the many
unproductive hours that often are spent in observing one-time activities.
3. Interviews: It is a face-to-face interpersonal meeting designed to identify relations and
Capture information as it exists. It is flexible tool, offering a better opportunity than the
Questionnaire to evaluate the validity of the information gathered. The major drawback is Preparation
time. Interviewing is an art that requires experience in arranging the
Interview, setting the stage, establishing rapport, phrasing questions clearly, avoiding arguments, and
evaluating the outcome.
4. Questionnaires: It is a self-administered tool that is more economical and requires less skill to
administer than the interview. It examines a large number of respondents at the same time, provides
standardized wording and instructions, and places less pressure on
Subjects for immediate response. The main drawback is the low percentage of returns.

 SYSTEM DESIGN
It is the process of defining the architecture, components, modules, interfaces and data for assisting to
satisfy specified requirements.

It is also the process of designing and developing systems to satisfy specified requirements of the user.

System design is based on the user requirements and the detailed analysis of the existing system.

Types of design
 1. Logical design
2. Physical design

Logical design

It is a graphical representation of a system showing the system processes and the flow of data into and
out of the processes.

To represent the logical design of a system, the system analyst can use different diagrams like:
flowcharts, data flow diagrams (DFD), entity relation diagrams(ER) etc.

Physical design

It is a graphical representation of a system showing the system’s internal and external entities and the
flow of data into and out of the entities.

An internal entity is an entity within the system that transforms data.

An internal entity can be a person, place or thing.

The physical design part can be broken down into 3 sub-tasks

 User interface design

 Data design
 Process design

User interface design

Concerned with how users add information to the system and with how the system presents information
back to them.

Data design

Concerned with how data is represented and stored within the system.

Process design

Concerned with how data move within the system and with how/where it is validated, secured or
transformed as it flows into, through and out of the system.

SYSTEM DESIGN TOOLS

 Flowcharts

It is a graphical representation of a system or algorithm.

It is a diagrammatic representation of the various steps involved in designing a system.

Notation/symbols used in flow charts

 Start and Stop

Decision

Flow of data

Input and Output

Process

Connector

TYPES OF FLOW CHARTS

 System flow charts

It describes the data flow for a data processing system.

Provides logical diagram of how the system operates

Represents the flow of documents and operations performed in data processing system.

Example:

Algorithm

Prompt the user for the centigrade temperature

Store the value in the centigrade(C)

Set (F) to 32+ (9C/5)

Print the value of C, F

Stop

Start

Prompt the user

for the centigrade

YES
Is C=0

Store 32+ (9C/5)

Print C, F

Stop
  Run flow charts

Used to represent the logical relationship of computer routines along with inputs, master files,
transaction files and outputs.

Input data

RUN 1

Display
temperature C

RUN 2

Calculate F

RUN 3 Forms with

C value
Print C and F
  Program flow charts

Represents in detail the various steps to be performed within the system for transforming the input into
output.

The various steps are logical or arithmetic operations and algorithms.

Serves as the basis for discussion and communication between the system analyst and the programmers.

Program flow charts are helpful to programmers in organizing their programming efforts.

Start

S=0

I=1

S=s+I

I=I+1

PRINT
IS I >5 SUM=”5” End

The registrar of wananchi technical institute intends to develop a system that will be used during the
interview of new students.
During the interview, it is intended that the students undertake four written examinations. The proposed
system would input the result. The system would then verify entry of marks before computing the
average for each student. The system would then print “Pass” if the average is >80 else print “Fail”.

Draw a system flow chart to represent the logic of the program.

Start

Enter results

Verify marks and

compute average

NO
Is average>=80 FAIL

YES

PASS

STOP

Advantages of using flow charts

  Communication: flow charts are better way of communicating the logic of a system to all
stakeholders
 Effective analysis: problem can be analyzed in more effective way.
 Efficient coding: they act as a guide or blue print during the system analysis and program
development phase.
 Proper documentation: program flow charts serve as a good program documentation which is
needed for various purposes.
 Proper debugging: They help in debugging processes.

Limitations of using flow charts

 Complex logic: when the program logic is completed, the flow chart will become complex.
 Alterations and modifications: If alterations are required, the flow charts may require redrawing
completely.
 CONTEXT DIAGRAMS

Also known as level 0 data flow diagrams (DFD)

Provides an overview of the data entering and leaving the system.

Also shows the entities that are providing or receiving that data.

This usually corresponds to people who will use the system.

The context diagram helps to define system boundary to show what is included and what is excluded
from the system.

Illustration of context diagram.

A certain company has a budget monitoring system (BMS) for its external entities namely
department, Board of Directors (BOD) and suppliers. Each department channels its spending
requests to the budgetary monitoring system, which ensures that the departmental budgetary
allocation is not exceeded. The system then transmits the budgets to the BOD for approval. On
approval, it is the function of the BMS to send orders to the suppliers. On receipt of the orders,
the supplier channels the delivery note to the respective departments. In certain cases, the
requests are rejected when they exceed the budgetary allocation. The BMS generates summary
reports.
Draw a context diagram to represent this information.

Se
Suppliers or nd ary
de Summ B.O.D
rs ts
repor
De
l
no ivery BUDGET MONITORY
te
SYSTEM
it
n sm
g Tra get
n din bu
d
e t
Sp ues
re q

ry
live
De e
Department
not

 DATA FLOW DIAGRAMS

DFD is a graphical representation of a systems data and how the processes transform data.

DFD is a graphical tool that allows system analysts and system users to depict the flow of data in an
information system.

DFD is intended to serve as a communication tool among systems analyst, end users, DB designers,
system programmers and other members of the project team.

Components of DFD/Notations/Symbols

External entities

Represents the source of data as input to the system.

Are also the destination of system data.

May represent job titles or other systems that interact with the system to be built.

Or
Process

These are actions carried out with the data that flows around the system.

A process accepts input data needed for the process to be carried out and produces data that it passes
on to another part of the DFD.

Process Where/who
identifier

Process name

Example of a process

1 Registrar

Enter student
details

Data store

Data store are places where data may be stored.

This information may be stored either temporarily or permanently by the user.

Data store description

Data store identifier

D1 Invoices
 Example of data store.

Data flows

They represent the movement of data from one point to another.

Another arrow identifies the data flow/data in motion

Data flows between external entities are shown as dotted line.

Example of data flow

Applicant’s name

Rules for drawing data flow diagrams

1. Any data flow leaving a process must be based on data input to the process
2. All data flows are named. The name reflects the data flowing between processes, data stores
and sources.
3. Only data needed to perform the process should be an input to the process.
4. All processes in DFD must be linked to either another process or a data store.
5. Each data store must have at least one data flow going into and one data flow leaving it.
6. Data must be moved by a process from a one data store to another.

Example of a level1 DFD diagram.

1 Entry clerk

D1 Customer orders
Edit order

Customer

D1 Shipping schedule
1 Shipping clerk

Gather shipment
products

D1 Products
Exercise

 An external entity “supplier” sending an invoice to a process “deals with payment”. Assume the
process takes place in the accounts division.
 A process called “update membership” writing customer details to a data store called customers.
Assume the process is performed by the membership secretary.
 A process called “order raw materials” is performed by the purchasing clerk. To do this, the clerk
retrieves details from the supplier data store and sends the purchase order to the external entity
supplier. The clerk also stores the purchase order details in a data store “purchase orders”.
 ENTITY LIFE HISTORY DIAGRAM

It is a map that attempts to map the possible life of each occurrence of an entity from creation to
deletion.

ELH is part of the event model and shows the effects of time on an entity or the dynamic behavior of the
system data.

Entities have lives in that over time things happen to them which change their state.

Entity life history symbols

- Sequence construct
Shows things that are expected to happen one after the other

The thing that is expected to happen first is positioned to the left and at the same height as the thing
that is expected to follow it.

ENTITY NAME

EVENT A EVENT B EVENT C

Selection construct
ENTITY NAME

Iteration construct

These are entities that occur many times for each particular occurrence of an entity. It is represented
using (*)

* e.g
Payment *
.

Parallel construct
 Example of entity life history diagram

Employee

New employee Working life of Working life end

employee

New staff
New Salary paid
Recruited
trainee Resigns Fired
Accepted *
  Data dictionary

Describes the properties of the fields used in a database.

Data dictionary: It is a file containing descriptions of all data items in a database.

The data dictionary holds data about data and can be made to appear as a table.

The description might include: data type, element size, attribute entity relationships, entity descriptions
and validation range of values.

Example of a data dictionary which stores employee information

Field name description Data type form Field size key validation
Pay roll A unique no number - double primary N
number given to an
employee
First name First name text - 30 N
of the
person
Last name Last name text - 30 N
of the
person
 Date of date DD/MM/YY 8 Must be a
birth date

 DECISION TREEE

It defines the conditions as sequence of left to right test.

A decision tree helps to show the paths that are possible in a design following an action or decision by
the user.

Illustration

1. If order is from book store and if order is for 6 copies, then discount is 25%.else if order is for less
than 6 copies no discount is allowed. Else if order is from library and if order is for 50 copies or
more, then discount is 15%.else if order is for 20-49 copies, then discount is 10%.else if order is
for 6-15 copies, then discount is 5%.else if order is for less than 6 copies no discount is allowed.

6 or more 25% discount

Book store
order size Less than No discount
6

Customer 5 or more 15% discount

20-49 10% discount

Library order
size
6-19 5% discount

Less than No discount

6

Amua Sacco limited issues loans to its members using the following criteria.

A member would qualify for a loan if he/she has operational FOSA account for the last three
years and he/she has never defaulted loan. In addition, a member should have 3 guarantors and provide
proof of reliable monthly income.

Represent this using a decision tree.

  STRUCTURED ENGLISH

It is a narrative form of English written as a series of blocks that use indentation and capitalization to
represent hierarchical structure of logical specifications.

It is based on structured logic.

It is used when process logic involves formulas or iteration or when structured decisions are not too
complex.

A good structured English statement reads like a short sentence. By convention, only key words such as
IF, THEN, REPEAT, DO, UNTILL, WHILE are capitalized. Data names and the general English needed to
complete a sentence or a phrase are lower case.

Format/syntax:

IF (some condition)

THEN (what to do if true)

ELSE (what to do if false)

END IF

DO WHILE <condition>

(Do while condition is true)

END DO WHILE

e.g.

IF customer balance is>60 days past due

THEN hold the customer-order

Send reminder letter

ELSE process the customer-order

END IF

DO WHILE there are overtime pay records

Read a record

Add overtime hours to overtime hours total.

Add overtime pay to overtime pay total

END DO WHILE

Example

A car insurance company process claims as follows:

First it determines whether claims are valid. If a claim is invalid, the process terminates with regrets.
Otherwise the claim will be processed depending on the insurance policy. This process will be repeated
until all the claims for the day are complete.

Model this process using structured English

IF (Claim is valid)

THEN process claim according to the insurance policy

ELSE terminate policy

END IF

Alternatively

DO process claim depending on the insurance policy

WHILE claim is valid

END DO WHILE

Advantages of structured English

 Useful for planning/designing program routines, modules and manual procedures.

It resembles a programming language and hence programmers find it easy to understand.

 It is excellent for describing English and algorithm particularly when user communication is
essential.
 ERD(ENTITY RELATION DIAGRAM)

An ERD is a data modeling technique that graphically illustrates an information system database entities
and the relationship between these entities.

ERD’s show entities in a database and relationships between tables within the database.

ERD’s illustrate the logical structure of databases.

Elements in an ERD
Entity

It is an object in the system that we want to model and store information about. Can be person, place,
event etc.

Attribute

It is an item of information which is stored about an entity e.g. student would have attributes such as:
first name, last name, date of birth etc.

Relationship

It is an association of entities where the association includes one entity from each participating entity
type.

Entity relation diagram notations/symbols

SSADM CHEN NOTATION

ENTITY
ENTITY NAME

ATTRIBUTE

ATTRIBUTE NAME

RELATIONSHIP

Degree/types of relationships/cardinality

 One-to-one relationship(1:1)

It is where one occurrence of an entity relates to only one occurrence of another entity.

Example:

If a man marries one woman and a woman is married by only one man, it is a one to one relationship.
 Man 1 1 Woman

1 Is 1 Woman
Man
married
to

 One-to-many relationship(1:M or N)

It is where one occurrence in an entity relates to many occurrences in another entity.

Example: one manager manages many employees but each employee has one manager only.

Manager 1 Manages Employees

 Many-to-many relationships(M:N,N:M)

It is where many occurrences in an entity relate to many occurrences in another entity.

Example:

One teacher teaches many students and a student is taught by many lecturers.

Lecturer Teaches Students

 Stock item
Refers to

Teaches
Illustration of ERD

Estimate
Order

1 Issued to
Places

Attribute
Attribute
Customer
Attribute
Attribute Attribute
1

Attribute

Entity Relationship Entity

Relationship

Attribute
Attribute
Entity
Attribute

 STRUCTURE CHARTS

It is a chart which shows the breakdown of a system to its lowest manageable levels.
Structured charts represent hierarchical structure of modules.

They describe functions and sub functions of each part of the system.

Modules are self-contained system components.

Symbols used in the construction of structure charts

a. Module

Represents process or subroutine or task.

Module

Module Module
Module

Library module

Sub-modules

b. Data flow

MODULE

Labels
Labels

MODULE
 Example of structure charts

A: customer order

B: order details

C: inventory data

Food ordering
A

system

C
B
Get order Update
inventory file
A
MODULE
A

B
B

Generate
order Generate
receipt

CHARACTERISTICS/QUALITIES OF A GOOD DESIGN

 Correctness: a good design should correctly implement all the functionalities identified in the
system requirements specification document(SRS document)
 Minimal complexity/understandability: A good design is easily understandable. The design must
be a readable and understandable guide for the developers who will write the code for the
system based on it as well as for the developers who will later test and maintain it.
 Maintainability/ease of maintenance: it should be easily changed
 Re-usability: design of the system should allow part of it to be used in other systems.
 Extensibility/flexibility: should be easy to change part of a system without affecting other parts.
 Loose coupled: it means designing so that connections among different parts of a program are
minimal. It should not be tightly coupled (components depend on each other so much)
The deliverable of system design phase is a blue print/model for the design with the necessary
specification for the hardware, software, people and data resources.

 SYSTEM CODING/CONSTRUCTION/PROGRAMMING

The objective of system coding is to convert the system’s specification into a functioning system.

The system design needs to be implemented to make it a workable system.

Programming languages commonly used are as follows:

Object oriented languages e.g. C++, VB, Java, C#(C Sharp)

Scripting languages e.g. Java Script, VBScript

Expert system languages e.g. PROLOG

Factors to consider when selecting a programming language

 Knowledge of software development staff: software developers should select a language which
they are familiar with.
 Capabilities of software development staff: the staff within the organization (IS specialists)
should be able to understand the language used in order to perform maintenance to the
software.
 Application area: environment in which the software is to be executed.
 SYSTEM TESTING

Testing is the process used to assess the correctness, completeness, reliability and quality of developed
computer software.

It helps to uncover different classes of errors in minimal time.

Levels of testing

 Unit testing
 Integration testing
 System testing
 Final acceptance testing

Unit testing

It is a software verification and validation method in which the programmer tests if individual units of
source code are fit for use.

A unit is the smallest testable part of an application and it may be an individual module, function or
procedures.

The five categories of test that a programmer performs on program unit are
  Parallel test: some data is used in the new and the old system and output results are then
compared.
 Structural test: examining the internal processing logic of software.
 Performance test: to verify response time, execution and memory initialization
 Functional test: it is conducted to verify whether the system does what is expected.
 Stress test: performed to determine the stability of the system

Types of unit testing

 Static analysis testing: performs desk checks, structured walkthrough on source code inspection.

Desk check: programmer checks for logical and syntax errors and deviation from coding standards.

Structured walkthrough: the programmer leads other programmers through the source code of the
software giving explanations.

 Dynamic analysis testing: consists of three types of testing

o Black box testing: takes an external perspective of the test object to derive test cases. No
knowledge of internal structure is required.it is applicable to all levels of software testing.(a
testing that is concerned with the external working of a component)
o White box testing: uses an internal perspective of the system to design test cases.
o Grey box testing: combination of black box and white box testing.

Integration testing

It is a software testing activity in which individual software modules are combined and tested as a group.

System testing

It is a process in which software and other software management tools are tested as one system/unit.

The purpose is to ensure that the new system/modified function properly.

Final acceptance testing

It is conducted when the system is ready for implementation.

It ensures that the new system satisfies quality standards and user needs.

It has two major parts

Quality assurance: ensures the new system satisfies quality standards

User acceptance: users test the system to ensure that functional aspects expected by them have been
well addressed in the new system.
Types of user acceptance testing

o Alpha testing: this often performed by users within the organization and it is the first stage.
o Beta testing: it is generally performed by external users.it involves sending the system outside
the development environment for real world exposure/usage (performed by users outside the
organization).

 SYSTEM IMPLEMENTATION

It is the process of ensuring that the information system is operational and then allowing users to take
over its operation for use and evaluation.

Implementation includes all those activities that take place to convert from the old to the new system.

The new system may be totally new replacing an existing manual or automatic system or may be a major
modification in an existing system.

The major steps/activities involved in this phase are

 Acquisition and installation of new information system.

 Conversion of data to the new system.
 User training
 Documentation(completion of user documentation)
 System changeover

System implementation techniques/changeover/conversion strategies

Conversion or changeover is the process of changing from old system to the new system

 Direct implementation changeover: it is the complete replacement of the old system by the new
system.it is done in one operation completely replacing the old system at once.
 Phased implementation: the new system is put into use in stages or phases. Some files maybe
converted and used by employees in the new system while other files continue to be used in the
old system. If each phase is successful, the next phase is started eventually to the final phase
where the new information system fully replaces the old system.(install some modules/phases
with time until the whole system is completed)
 Pilot implementation: in this strategy, the new system replaces the old system in one operation
but only in a small scale.

Example: it might be tried out in one branch in a company or in one department and if successful, the
pilot is then extended until it eventually replaces the old system completely.

 Parallel implementation: the old and the new systems are both used alongside each other both
being able to operate independently.

If all goes well, the old system is stopped and the new system carries on as the only system.
INFORMATION SYSTEM MAINTENANCE

Maintenance is the process of making needed changes to the structure of some information system.

System maintenance is the ongoing maintenance of a system after it has been placed into operation.

Types of information system maintenance

 Corrective maintenance

It implies removing errors in a program which might have crept into the system due to faulty design or
wrong assumptions.

Thus, in corrective, it is the process where performance failures are repaired.

 Adaptive maintenance

Program functions are changed to enable the information system to satisfy the information needs of the
user.

This type of maintenance may become necessary because of the organizational changes which may
include change in the organizational procedures, change in forms, change in information needs of
managers, change in system controls and security needs, change in organizational objectives and
policies, change in operating system.

 Perfective/enhancement maintenance

Perfective maintenance means adding new features or modifying the existing programs to enhance the
performance of the current system.

Perfective maintenance is undertaken to respond to users additional needs which may be due to
changes within or outside the organization.

An example of this type of maintenance is the conversion of text based systems to graphical user
interface design (GUI)

 Preventive maintenance

It deals with activities aimed at increasing system maintainability, such as updating documentation,
adding comments and improving the modular structure of the system.

Reasons for information system maintenance

 Changes in business processes

Systems should be modified or updated to enable them address emerging or new business processes.

 New requests from stakeholders ,users and managers

  Bugs or errors in the system
Maintenance is necessary to fix errors.
 Change in operating system or hardware on which the system runs.
 Corporate mergers and acquisitions
 Government policies

CHAPTER 7

SYSTEM DOCUMENTATION

It is a document that gives a comprehensive description of a system.

It shows how the software has been developed and the features or functionalities.

There are several types of documentation that should be produced when creating a new system.

Types of documentation

 Technical documentation

It is a document of source code, algorithms and interfaces. It is intended to assist skilled

programmers/technical people know exactly how the system works.it includes:

 Details of Hardware and software for the system

 Details of expected inputs
 Details of validation checks
 Details of how data is processed
 Diagrams showing how data moves through the system
 Flow charts describing how the system works.

 User documentation

It is a complete description of the system from user’s perspective.it gives in detail how to use the system
or operate the system.

These are manuals prepared for the end user, system administrator and support staff.it is intended to
help users of the system. Users are usually non-technical people who don’t need to know how the
software works. They just need to know how to use it.

User documentation includes:

 List of minimum hardware and software required to use the system.

 How to install the system.
 How to start/stop the system.
 Screen shots showing the system in typical use.
  Explanation of any error messages that might be shown.
 Example inputs and outputs.
 Troubleshooting guide.

 Marketing documentation

It describes how to market the product and analysis of the market demand.

INFORMATION SYSTEMS ACQUISITION

Factors affecting the choice of information system acquisition method

 Cost of acquisition

Small organizations can prefer to purchase commercial off-the-shelf software rather than developing in-
house programs.

 Capability of in-house ICT team

The number of ICT personnel and the level of their knowledge and skills can determine if the
organization has enough manpower or expertise to develop the system.

 System complexity

If in-house ICT team is not able to manage a complex system, the organization can opt to outsource ICT
services.

 Size of the organization

Small organizations may not be able to develop in-house software and therefore can adopt other
methods like purchasing ready-made software or using open source software.

Information system acquisition methods

 Commercial off-the-shelf purchase

 System development/bespoke development/in-house development
 Outsourcing
 Open source software
 Renting
 Leasing
 Commercial off-the-shelf purchase

This is an acquisition method that involves direct purchase of a pre-written application or system used by
more than one company.

Advantages
-readily available for purchase and use

-cheap

Disadvantages

-the system may lack all the requirements needed.

 System development

This is where an information system is developed from scratch by information system professionals to
suit the business requirements of the organization.

Advantages

-ownership: The organization owns the system completely

-the system has the required features

Disadvantages

-expensive: As it requires both resources and time to develop.

 Outsourcing

It is the practice of subcontracting part or all of an organization’s information system functions to an

external service provider

Advantages

-cost reduction: Focus/concentrate on their core competencies

-knowledge: a way to gain access to new technology and outside expertise.

 Open source software

Software that has no copyright over the code and allows the public to modify the source code and
develop it to their own content.

Software that is developed, tested or improved through public collaboration and distributed with the
idea that it must be shared with others ensuring an open future collaboration.

 Renting

An acquisition method where an organization that requires the hardware, software or computer system
gets them from another company after signing a rental contract.

The computer system or hardware system can only be used for the activities or functions that have been
specified in the contract.
  Leasing

An information system is acquired from another company after signing a lease contract. The lease
contract is longer than that of renting.

CHAPTER 8

INFORMATION SYSTEM PROJECT MANAGEMENT

Information system project management is the process of planning, monitoring, controlling people,
processes and events that occur as software evolves from a preliminary concept to an operational
implementation.

Project

A set of related tasks that is coordinated to achieve a specific objective within a given time limit and
under a specified budget.

Deliverable

It is the end product of a software development life cycle phase.

It can be a report or a working system depending on the software development phase.

Importance of information system project management

 Meeting customer expectation

Project management techniques will enable developers to deliver a system that satisfies user
requirements.

 Satisfying budget constraints

Effective project management will ensure that the system is delivered within budget.

 Satisfying time constraints

Project management will ensure that the system is delivered within scheduled time.

 Equal distribution of tasks and responsibilities to members of the development team.

Project identification techniques

 Top-down identification: focuses on global needs of the organization and is usually done by the
top management or steering committees.
 Bottom-up: project is identified by a business unit or information system group.

Information system project management techniques

 Cost estimation techniques
 Expert judgment

Several experts on software development techniques and the application domain are consulted. They
each estimate the project cost.

These estimates are compared and discussed.

The estimation process iterates/repeats until an agreed estimate is reached.

 Estimation by analogy

This technique is applicable when other projects in the same application domain have been completed.
The cost of a new project is estimated by analogy with these completed projects.

 Pricing to win

The software cost is estimated to be whatever the customer has available to commit to the project.

 Constructive cost model(COCOMO)

It is an approximation of effort needed based on experience of past projects

Project scheduling
It is the process of estimating the duration of activities in a project and presenting the estimation using
tools that are universally accepted.

The two graphical tools that are used in project scheduling are:

 Gantt chart
 PERT chart/Network diagram

Gantt chart

It is a graphical representation of a project that shows each task/activity as horizontal bars whose length
is proportional to its time of completion.

Different colors or shades can be used to highlight different activities.

Example:

Time 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2
(weeks) 0 1 2 3 4 5 6 7 8 9 0
feasibility
analysis

design

coding

testing

Pert chart/network diagram PERT (project evaluation and review technique)

On the PERT chart, a project is viewed as a network of activities of which some must be completed
before others can begin.

PERT assumptions

 Inter-relations of activities are depicted/shown on a network on directed arrows which denote

sequence of activities.
 The nodes called events represent instance in time when certain activities have been completed
and others can then be started.
 The origin node is the beginning of the project.

Types of network diagrams

 Activity on arrow(AOA)
 Activity on node(AON)

Activity on arrow

 Activities are shown on the arrow

 It is easier to draw and modify
 Non-experts are more likely to understand the network diagram
 Milestone events are readily visible.
Illustration

ACTIVITY PRECEEDING DURATION(WEEKS)

ACTIVITY
A - 5
B - 4
C A 2
D B 3
E B 5
F B 5
G C,D 4
H F 3

Activity on node

7
C 4
5 8 G
2
2 4
0
A
12
5 6
D

0
3

1 12
B E
0
4 5
4
H

3
F
4
3

9
5 5
 EST: Earliest Start Time
EST
LCT: Latest Event Start Time
N N: node number
Critical path: B-F-H=12 weeks
LST

Activity on arrow

7 8

5 6
C 4
G
2 2 12 12
0 0 A 4
D

5 6
3

1 B E

4
5
3 H
9 9
F
3

4 4

5 5

EST: Earliest Start Time

EST LCT LCT: Latest Completion Time
Critical path: B-F-H
Earliest Start Time

EST at an event is the earliest time activities ahead of that event can start, keeping in mind that all the
activities before the event must be complete. It is calculated in the forward pass.

Activity durations on each path linking to an event are added and then the largest is taken.

The first event has EST value 0

The EST in the last event gives the project duration.

In the above example, the project duration is 12 weeks.

Latest Completion Time

LCT at an event is the latest time that preceding activities can complete without delaying any of the
succeeding activities.

It is calculated in backward pass, starting from the last event whose LCT is set to the project duration.

Critical path

It is the sequence of activities that takes the longest time to complete.

It is the sequence of activities that have the same EST and LCT values.

Any delay to an activity in the critical path will cause delay to overall project.
Slack time

It is free time associated with each activity as it represents unused resources that can be averted to the
critical path.

Dummy activity

It is a hypothetical activity which requires zero time and zero resources for completion. A dummy activity
has a completion time of zero.

Dummy arrow represents an activity with zero duration.

It is represented by a dotted line.

Estimation of activity times

Optimistic time

It is the estimate of the maximum time an activity will take

The most optimistic (O) case where everything goes right

Most likely time

The completion time having the highest probability.

The most likely (M) case given normal problems and opportunities

Pessimistic time

An estimate of the longest time that an activity might require.

The most likely (M) case given normal problems and opportunities

The resulting PERT estimate is calculated as (O + 4M + P)/6. This is called a "weighted average"

Signs of a failing information system project

 Poor communication: It is where no one understands what to do and there is no communication

as to current progress.
 Poor planning and estimation: projects that are poorly estimated and planned tend to fail both
in cost and schedule which eventually causes the overall project to fail.
 Poor documentation/minimal documentation: many failed projects reveal that there was too
little documentation to adequately describe the project in its broader terms and serve as a clear
communication channel.
  Poor user requirements: when the user requirements have not been adequately captured it may
lead to misalignment between the project and business objectives.
 Budget overrun: projects that run over budget are likely to be cancelled.
 Poor project control: the project manager may not have the skills or experience required to
manage the project.
 Time overrun: developers may run out of time that they had scheduled.

Causes of information system project failure

 Lack of senior management support and involvement in information system development.

 Lack of user participation

User involvement is necessary to reduce resistance to change and ensure adequate development.

 Shifting user needs

User requirements for ICT change constantly. Changes during an ongoing development process cause a
challenge and may cause the project to fail.

 Poor estimation techniques

When project cost and time are not well estimated, developers may run out of funds and time.

 Inadequate testing and user training

New systems must be tested before installation

Users must be adequately trained on how to use the system.

 Undertrained development staff

Developers may lack the required skills and knowledge/expertise required.

 Lack of standard project and system development methodologies.

 Resistance to change

Users have a natural tendency to resist change.

Control measures and techniques of rescuing a failing information system project

 Pausing the project

Pausing the project creates an opportunity to restore integrity to the project.

 Auditing the project

The purpose of project audit is not to place blame but rather is to find out the root cause why the
project is failing.
  Recognizing early warnings

It is always easier to get projects back on track if they have not drifted too far off the track.

 Assessing the effort to complete the project

The human effort required to complete the project should be reviewed or assessed.

Measures of project success

 The resulting information system is acceptable to the client or users

 The system was developed within the time scheduled.
 The system was delivered within budget.

Criteria for evaluating ICT projects/project appraisal methods

 Net present value(NPV)

 Return on investment(ROI)
 Payback time(pay back analysis)

Net present value

It is a method of calculating the expected monitory gain or loss from a project by discounting all future
cash inflows and outflows to the present.

NPV=∑t=1……………nA (Hr)-t
OR

NPV=∑t=1…………n
Where, A= cash flow
r=required rate of return A
t=year of cash flow
n=nth year (1+r)
t

It is normally assumed that any initial investment takes place immediately and is indicate by year 0 and it
is discounted.

Later cash flows are normally assumed to take place at the end of each year and are discounted by the
appropriate amount.

NPV acceptance rules

  Accept the project if its NPV is positive
 Reject the project if its NPV value is negative
 A project with 0 NPV may be accepted or rejected
 NPV can be used to select between mutual exclusive projects. The one with the higher NPV
should be accepted.

Example

Project A requires an initial investment of Ksh 363000 and it is expected to generate a cash inflow of ksh
50000 per month for 12 months. Assume that the salvage value of the project is 0 and the target rate of
return is 12% p.a.Calculate NPV for the project.

-363 000
YEAR 0 = = -363 000
(1+0.12)0

600 000
YEAR 1 = = 535,714.28
(1+0.12)1

NPV=-363,000+535,714.28=172,714.28.

The table below shows cash flow details of project A and B

YEAR PROJECT A PROJECT B

1 -5000 -100000
2 3500 65000
3 3500 65000
Using NPV at a discount rate of 15%, determine the most viable project to undertake assuming the
starting capital was ksh 500.

Solution

PROJECT A PROJECT B

-500 -500
YEAR 0 = = -500 = -500
YEAR 0 =
(1+0.15)0 (1+0.15)0

-5000 -100000
YEAR 1 = = -4347.83 = -86056.52
YEAR 1 =
(1+0.15)1 (1+0.15)1
 3500 65000
YEAR 2 = = 2646.50 = 49148.34
YEAR 2 =
(1+0.15)2 (1+0.15)2

3500 65000
YEAR 3 = = 2301.31 = 42738.56
YEAR 3 =
(1+0.15)3 (1+0.15)3

NPV Total=99.98 NPV Total=4431.38

Project B should be selected since it has higher NPV than that of project A.

Return on investment (ROI)

It compares the lifetime profitability of alternative solution/project.

This is a percentage rate that measures the relationship between the amount invested and the amount
the business gets back from investment.

Life time benefits-life time costs X 100%

ROI =
Life time cost

OR

Net profit X 100%

ROI =
Cost of investment

Average annual profit X 100%

ROI =
Total investment
The solution offering highest ROI is the best alternative.

Example

The table below shows net profit for project A and B.The initial cost for the projects were Ksh 180,000
and 220,000 respectively.

Determine the cost worthwhile project using the ROI technique.

PROJECT A PROJECT B
YEAR NET PROFIT VALUE NET PROFIT VALUE
1 30000 40000
2 35000 46000
3 40000 46000
4 45000 46000
5 50000 46000
TOTAL 200000 224000

Project A
Project B

200000
224000
ROI = X 100%
5 100%
ROI = 5 X

180000
220000

= 22.22%
= 20.36%

Payback analysis
Project A is(time/period)
the best alternative as it has a higher ROI

It is a method of determining the time it will take for an information system investment to pay itself. This
period of time is called the payback period. Project with the shortest payback period is supposed to be
selected.
The table below shows net profit for project A and B.The initial cost for the projects were Ksh 180,000
and 220,000 respectively.

Calculate the payback time for each project.

PROJECT A PROJECT B
YEAR NET PROFIT VALUE NET PROFIT VALUE
1 30000 40000
2 35000 46000
3 40000 46000
4 45000 46000
5 50000 46000

PROJECT A PROJECT B
YEAR 1=-180,000+30,000=-150,000 YEAR 1=-220,000+40,000=-180,000
YEAR 2=-150,000+35,000=-115,000 YEAR 2=-180,000+46,000=-134,000
YEAR 3=-115,000+40,000=-75,000 YEAR 3=-134,000+46,000=-88,000
YEAR 4=-75,000+45,000=-30,000 YEAR 4=-88,000+46,000=-42,000
YEAR 5=-30,000+50,000=20,000
Project A should be selected as it has theYEAR 5=-42,000+46,000=4,000
shorter payback time
PROJECT A payback time=4 years PROJECT B payback time=4 years

Project A should be chosen as it has shorter payback time

COPUTER AIDED SOFTWARE ENGINEERING TOOLS (CASE tools)

CASE: Refers to the use of software tools to assist in the development and maintenance of software.
CASE tool: It is a computer based product aimed at supporting one or more software engineering
activities within a software development process.

CASE tools: Are those software which are used in one or all phases of developing an Information System
including analysis, design and programming.

Components of CASE tools

 Upper CASE tools: tools that support software development activities from implementation
 Lower CASE tools: tools that support direct programming and integration tasks. Supports
database schema generation, program generation, implementation testing and configuration
management.
 Integration CASE tools: tools that integrate both upper and lower CASE tools.

Example: making it possible to design a form and build the database to support it at the same time.

It is an automated system development that provides numerous tools to create diagrams forms and
reports.

It offers analysis reporting and code generation facilities.

Types of CASE tools

 Diagramming tools: enables system processes, data and control structures to be represented
graphically.
 Report generators: helps to prototype how system looks like.
 Analysis tools: checks for inconsistency and incorrect specification in diagrams, forms and
reports.
 Documentation generators: helps to produce technical and user documentation in standard
format.
 Code generators: enable automatic generation of program and database definition code directly
from design documents program forms and reports.

FUNCTIONS OF CASE TOOLS

 Analysis: CASE analysis tools automatically checks for incomplete, inconsistency or incorrect
specification in diagrams and reports.
 Design: tools that enable the design of a blue print/model by designing the technical
architecture.
 Code generation: tools that enable automatic generation of program code directly from the
document forms, diagrams and reports.
 Documentation: tools that enable production of technical and user documentation in standard
format.

Advantages of CASE tools

  Increased speed: provide automation and reduce the time to complete many tasks.
 Increased accuracy: enable error checking and debugging services.
 Better documentation: by using CASE tools, it produces vast amount of documentation.

Limitations of documentation

 Cost: the cost of fitting every system developer with appropriate CASE tool kit can be costly.
 Training: A lot of time is needed to train a person who has no knowledge of CASE tool concept.

CHAPTER 9

EMERGING TRENDS IN SYSTEM ANALYSIS AND DESIGN

 Connectivity and collaboration: software development teams do not occupy the same physical
space when working on a project.
 Re-usable components: components can be used in other systems other than the original
systems.
 Use of CASE tool: CASE tools have reduced system development time considerably
 OOAD methodology: development methodology that approaches Information system
development from object point of view.

Decision Tables
A matrix representation of the logic of a decision which specifies the possible conditions for the
decision and the resulting actions.
It has three parts
• Condition stub - list the conditions relevant the decision
• Action stub – That part of the decision table that list the actions that result for a given
set of conditions.
• Rules – Specify which actions are to be followed for a given set of conditions.
• Indifferent conditions - a condition whose value does not affect which actions taken for
two or more roles.
Example
The Decision Table showing a generic payroll system

Conditions AND Rules

Course of action 1 2 3 4 5 6
Condition Employee type Salaried Hourly Salaried Hourly Salaried Hourly
Stub Hours worked <40Hrs <40Hrs 40Hrs 40Hrs >40Hrs >40Hrs
Pay Basic Salary   
Calculate Hourly   
Action Stub
Calculate Overtime 
Absence Report  

Basic procedures in constructing the decision table

 1. Name the conditions and the values that each condition can assume, determine all the
conditions that are relevant to your problem. The conditions may be of limited entry
(Yes/No) or extended answers.
2. Name all possible actions that can occur
3. List all possible rules
4. Define the actions for each rule
5. Simplify the decision table.

Entity Life Histories

The purpose of an information system is to provide up-to-date and accurate information. The
information held on the system is constantly changing - the number and names of the patients on
a hospital ward, for example, or the price of electronic components. The system must be able to
keep track of such changes. An entity life history (ELH) is a diagrammatic method of recording
how information may change over time, and models the complete catalogue of events that can
affect a data entity from its creation to its deletion, the context in which each event might occur,
and the order in which events may occur. The ELH represents every possible sequence of events
that can occur during the life of the entity. Remember that, although data is changed by a system
process, the occurrence of that process is triggered by some event.

It would obviously be an overwhelming task to model the all of the events that could affect the
system data at the same time, so instead we examine just one entity within the logical data
structure at a time. An entity life history will be produced for each entity in the logical data
structure. Information from the individual life histories can be collated at a later time to produce
an entity/event matrix.

The diagram below shows how we might model the life history of a bank account entity.
An entity life history for the "Bank Account" entity

The entity life history for "Bank Account" should accommodate any possible occurrence of that
entity. All bank accounts must be opened, and money is either paid in or withdrawn. The diagram
itself is read from left to right. If the structure branches downward, the branch must be followed
down before moving on towards the right-hand side of the diagram. The first event to affect any
occurrence of "Bank Account" will be the opening of the account. The account will have a life,
which will consist of a series of transactions. Transactions can include the deposit or withdrawal
of funds, direct payments, or the cashing of cheques. After an unspecified number of transactions
have occurred, the account will be closed, and eventually deleted. The entity life history elements
featured in the above example are:

 Sequence - activities are undertaken in strict sequence, from left to right (for example, an
account must be opened before any other event that will affect it can occur, and account
closure must occur before account deletion).
 Iteration - the asterisk in the top right-hand corner of the Transaction box signifies that a
transaction is an event that can occur repeatedly.
 Selection - boxes with small circles in their top right-hand corner represent alternative
forms of transaction. A single transaction may be a deposit or a withdrawal of funds, a
direct payment, of the cashing of a cheque.

" In the same way that an entity may be affected by several different events, a single event may
affect more than one entity. When an instance of "Bank Account" is created, for example, an
instance of "Customer" must also be created. The interaction between an event and an entity is
called an effect. Notice that elements that have an effect on an entity have no other elements
below them in the entity life history diagram. Elements that do have other elements below them
are called nodes. They have no significance other specifying the sequence in which events may
occur within the context of the entity's life history. The name of each element (shown as a label
inside the box representing the entity) reflects the event affecting the entity (if the element is an
effect) or a particular stage within the life history (if the element is a node).

Although an entity life history can be constructed using only the elements sequence, iteration
and selection, the representation of certain complex scenarios can be greatly simplified using two
additional element types:

 parallel structures
 quit and resume

Sequence

A sequence consists of a series of nodes and/or effects reading from left to right, as shown below.

Boxes A, B, C, and D represent a sequence

In the above example, effect A will always occur first, followed by B, then C, then D. This is the
only possible sequence. Although these sequential events will take place over a period of time,
the time intervals involved are unspecified, and could range from a few seconds to many years.

Selection

A selection defines a number of nodes or effects that are alternatives to one another at a
particular point in the entity's life history. A circle in the top right hand corner of the box
representing the element indicates that it is one of several elements that could be chosen.
Boxes E, F and G represent the available options

Because node A is the first element in the entity life history of "Entity X", an occurrence of the
entity can only be created by event E, F or G. If we want to represent the fact that none of the
available options have to be selected, we can include a null box, as shown below.

A null box indicates that an option does not need to be selected

Iteration

If an event or node can occur repeatedly at the same point within an entity's life history, the fact
is signified by an asterisk in the top left-hand corner of the box representing the event or node.
The only restriction on iterations is that a single occurrence of the iteration must be complete
before the next one starts.
Event H may occur repeatedly

Once "Entity X" has been created by event E, F or G under node A, event H can affect the entity
zero or more times The iteration symbol must not be used for events or nodes that occur only
once, or not at all (use the null box instead).

Parallel structures

A parallel structure can be used if the sequence in which two nodes or events can occur is
unpredictable, or where they may occur concurrently. Such a structure is shown as two nodes or
events connected by parallel horizontal lines, as illustrated below.
Nodes I and J form a parallel structure

In the entity life history above, the events K, L and M may occur, in that order, under node I. At
the same time event N, under node J, may occur zero or more times. Nodes I and J (representing
the sequence and the iteration respectively) are connected by a parallel bar to signify possible
concurrency. The same situation could be modelled using only sequence, iteration and selection
elements, but the resulting diagram would be far more complex and consequently more difficult
to interpret.

Quit and resume

Occasionally, a situation can arise that cannot easily be modelled using the entity life history
elements already described. In order to accommodate such situations without making the entity
life history diagram unduly large or complex, the quit and resume facility allows the sequential
progress of nodes or events to quit at one point in the entity life history and resume at another
point. This concept is illustrated below.
Following event F, activity will continue at node C

In the above example, event F has the label "Q1" immediately to its right, and node C has the
label "R1" immediately to its right. Using this notation, we can signify that the event or node that
will follow event F is whichever element has the label R1 to its right, which in this case is node
C. As with parallel structures, the same situation could be modelled using only sequence,
iteration and selection elements, but the resulting diagram would be more complex and difficult
to interpret.

The example below shows how we can model a situation in which a bank account has been
closed (but not deleted), and is then re-opened. The event Account Reopened (labelled Q1)
causes a quit back to the node Account Life (labelled R1).
Two possible uses of quit and resume

The quit and resume facility also allows us to quit from the main structure altogether, and resume
at a point in a stand-alone structure. This can be used in situations where an event that can occur
at any time will alter the normal sequence of the life history. Since it is impossible to predict
exactly where such an event might occur within the entity's life history, an appropriate
instruction should be added to the diagram indicating the circumstances under which the quit
might occur, and from where. In the above example, the death of a customer may occur at any
time after an account is opened, triggering an immediate quit, followed by a resume at R2
(Death Structure). In circumstances such as the death of a customer, the normal sequence will no
longer apply.

Note that it is also possible to quit from a stand-alone structure back to the main structure in an
entity life history. To avoid ambiguity, while there may be more than one quit point with the
same identifier, there cannot be more than one resume point with that identifier.

What is Data Dictionary

A data dictionary contains metadata i.e data about the database. The data dictionary is very
important as it contains information such as what is in the database, who is allowed to access it,
where is the database physically stored etc. The users of the database normally don't interact with
the data dictionary, it is only handled by the database administrators.

The data dictionary in general contains information about the following:

1. Names of all the database tables and their schemas.

2. Details about all the tables in the database, such as their owners, their security constraints,
when they were created etc.
3. Physical information about the tables such as where they are stored and how.
4. Table constraints such as primary key attributes, foreign key information etc.
5. Information about the database views that are visible.

This is a data dictionary describing a table that contains employee details.

Field Name Data Type Field Size for display Description Example

Employee
Integer 10 Unique ID of each employee 1645000001
Number

Name Text 20 Name of the employee David Heston

Date of Birth Date/Time 10 DOB of Employee 08/03/1995

Phone Number Integer 10 Phone number of employee 6583648648

The different types of data dictionary are:

Active Data Dictionary

If the structure of the database or its specifications change at any point of time, it should be
reflected in the data dictionary. This is the responsibility of the database management system in
which the data dictionary resides.

So, the data dictionary is automatically updated by the database management system when any
changes are made in the database. This is known as an active data dictionary as it is self
updating.

Passive Data Dictionary

This is not as useful or easy to handle as an active data dictionary. A passive data dictionary is
maintained separately to the database whose contents are stored in the dictionary. That means
that if the database is modified the database dictionary is not automatically updated as in the case
of Active Data Dictionary.
So, the passive data dictionary has to be manually updated to match the database. This needs
careful handling or else the database and data dictionary are out of sync.
Compiled by Samuel Theuri