SYSTEMS ANALYSIS AND

DESIGN

WILLLIAM MUNYIRI
Lesson 1
Systems Theory

Objectives
 System concept and the Organization
 System Theory/Concept
 Types of Systems
 System Components
 Characteristics of Systems
 Data and Information
 SYSTEM THEORY / CONCEPT

 A system is an ordered grouping of independent components

linked together according to specifications so as to achieve
defined objectives of a business org.
 A system in its broadest form is a group of components that
interact to achieve a purpose.
 A system comprises elements namely people, resources, concepts
and procedures intended to perform a function towards a common
goal.
SYSTEMS CONCEPT AND ORGARNIZATION

 Organizations are complex systems that consist of inter-related

and interlocking subsystems
 Changes in one subsystem has anticipated consequences in other
parts of the systems.
 Systems analysis concerns the application of the system approach
to the study and finding solution of problems using computer-
based systems.
 System analysis provides a framework for visualizing the
organizational and environment factors that operate on system.
 Computerizing operations of an org improves performance,
efficiency, effectiveness, satisfaction, quality information
processing and results.
 SYSTEM THEORY / CONCEPT

 The systems theory is concerned with tendency towards the

fragmentation of knowledge and the increasing complexity of the
organizations
 Systems concepts relate to the organizations by viewing an on going
system / operations as a processor of information for making
decisions, in which information and communication provide
connecting links for unifying various components
 Generally, systems theory is concerned with developing a systematic,
theoretical framework upon which to make decisions by considering
all activities of the org. and its external environment.
 SYSTEM THEORY / CONCEPT

Systems concepts has the following implications:

A system is designed to achieve a predetermined objective

Interrelationships and interdependences exist among the

components
Objectives of an org. have higher priority than objectives of its sub-

systems
 TYPES OF SYSTEMS

 Physical – systems that are tangible entities that may be static or

dynamic in operation
 Abstract – conceptual (non physical) entities implemented as
models that help to visualize relationships of the system under
study
 Open – allow for inputs for processing and producing outputs
 Closed – system that isolates itself from others in the environment
 Formal IS – a system based on the org. with a representation
chart and documentation.
 TYPES OF SYSTEMS
 Informal system – a power structure designed to achieve the company
goals / objectives. Not represented by chart or documentation.
 Deterministic – also mechanistic system is one whose outputs can be
predicted by examining its inputs e.g accuracy of electronic calculator
 Probabilistic – also stochastic system is one whose outputs cannot be
predicted with complete accuracy but mainly by chance
 Adaptive – also cybernetic is a system that responds to changes in the
environment and modifies its operations accordingly
 Hard system – has explicit objectives & is governed by fixed rules
and procedures
 Soft system – operates in a relatively unpredictable environment where
conditions may be uncertain or liable to rapid changes
SYSTEM COMPONENTS

 All Systems have inputs, processes, and outputs.

 A system is defined in relation to its Boundary and
Surrounding (environment)
 SYSTEM COMPONENTS

 Inputs –elements that enter the system e.g. data entered into
comp. raw materials to a plant,
 Processes – operations necessary to convert / transform inputs to
outputs. Computer processing involves activating commands,
execution, computations and storage
 Control – elements that guide the system in decision making by
monitoring pattern of activities that govern input, processing
and output e.g. OS, management etc
 Outputs – Describes finished products / services as consequences
of inputs being in the system
 SYSTEM COMPONENTS

 Communication - Also feed-forward and feedback which are

Connections / flow of info and materials among sub-systems.
Reports on Operations & performance of systems for decision –
making modification of inputs/process
 Boundary – Physical/non-physical confinement that separates a
system from its environment
 Environment – Comprises elements outside a system that can
impact on a system’s performance ie The business environ includes
competitors, suppliers, customers, regulation agencies,
demographic, social & economic conditions
 CHARACTERISTICS OF A SYSTEM

 Organization – implies structure and order of arrangement of the

components that help to achieve the objectives.
 A business system has a defined authority structure, specifies the formal
flow of communication and formalizes the chain of command; whose info.
Is processed by an IS
 Interaction – concerns the functions of systems’ components set
to realize efficient and effective performance
 Interdependence – parts of org. or computer system depend on
one another but are linked together and coordinated to a plan,
whereby the output of one sub system may be an input of another,
all aimed at proper functioning
 CHARACTERISTICS OF A SYSTEM

 Integration – concerned with how parts of a system work

together within the system even though each part performs a
unique function
 Common objective – The main objective of a computer
application.
 DATA AND INFORMATION

 Data – Raw facts about an organization and its business transactions

 Groups of non – random symbols which represent quantities,

actions, objects etc

 In IS data items are formed from characters that may be

alphabetical, numeric or special symbols

 Data processing involves collecting and organizing the data items /

symbols for the purpose of converting them into data structures

and databases.
 Data relevant to the processing of Information and decision

making may also be in the form of text, images or voice.

 For effective processing of data resources are necessary such as

human personnel, facilities and equipment.

 DATA AND INFORMATION
 Information – data that has been processed into a form that is
meaningful to the recipient and is of real / perceived value in the
current / prospective actions and decisions.
 organized ideas or facts obtained through processing data in a

purposeful intelligence and can be used in decision making

 The relation of data and Information is that of raw materials to

finished products in the sense that an IS processes data into

information, diagrammatically
 Information resources are reusable, don’t lose value and may

indeed gain value through credibility added by its use.

 The value of information become meaningful in the context of

decision, since if there were no current / future choices or

decisions then information would be unnecessary.
 QUALITY OF INFORMATION

 Utility – evaluating info in terms of utilities / applications that

may facilitate or retard info use and includes form, time, place and
possession utility
 Satisfaction – degree to which a decision maker is satisfied with
the output of the informal IS
 Errors– errors causes variation of info, where improvement in
quality is more important than an increase in the quantity of info.
 Bias - is caused by individual’s ability to exercise discretion in
info presentation
 SYSTEMS CONCEPT AND ORGARNIZATION

 Automating operation has negative impact such as:

 Possible threat to employment due to redundancy

 Decreased morale of personnel who were not consulted about the

installation
 Feeling of intimidation by users who have limited training in

Computer skills.

 Discussion Exercise:
 List other potentially negative impacts of automating operations.
 For each of the above give ways on how the negative impacts can be
minimized.
End Lesson 1
Lesson 2
INFORMATION SYSTEM

Objectives
 Categories of IS
 IS Stakeholders
 Database Systems Approach
 Systems Organizational levels
 Definitions

 Information System –is a set of devices, procedures and

Operating Systems designed around user-based criteria to produce
info and communicate it to the user for planning, control and
performance
 Information System - an arrangement of people, data, processes
and communication technology that interact to support and
improve operations in a business in a view of problem-solving and
decision making needs of management and users
 Definitions

 Information System - it is a term that describes the combination

of computer technology (HW / SW) with communication
technology (data, images and voice networks).
 Thus an IS comprises of computer technology and the

operational structure in an organizational context.

 A system that uses resources to convert data into the information

needed to accomplish the purposes of the business.
 CATEGORIES OF INFORMATION SYSTEMS

 Management Information System (MIS) - an IS that provides

for management oriented reporting in predetermined format
according to levels:
 Strategic - relates to long range planning policies and upper

management, especially in making unstructured decisions

 Managerial - info that helps middle management in policy

implementation and control, resource allocation and

coordination
 Operational - daily info needed to operate the business and is

established by data processing systems-produces management

reports required for planning, monitoring and control.
 CATEGORIES OF INFORMATION SYSTEMS

 Transaction Processing System (TPS) - is applications that

capture and process data about business transactions especially the
operational level.
 Decision Support System (DSS) - is application that provides its
users with decision oriented information whenever unstructured
decision making situation arises.
 Expert Systems (ES) - programmed IS that captures and
reproduces the knowledge and expertise of an expert problem
solver-decision maker by simulating thinking or actions of an
expert.
 INFORMATION SYSTEM STAKEHOLDERS

 System owners - sponsors and advocates responsible for funding

into develop, operate and maintain an IS i.e. pay for the system to
be built and maintain.
 System users - use the system to perform or support the work to
completion by capture, validate, enter, store and exchange data
and info.
 System Designers - design a system to meet the user’s
requirements
 System Engineers - translate users or business requirements and
constraints into technical solutions.
 INFORMATION SYSTEM STAKEHOLDERS

 System Builders - construct, test and deliver the new system into
the operation.
 Vendors / Consultants – sell system hardware, software and
services to business for incorporation into their information
systems.
 System Analyst - facilitator to the development of IS and
computer applications by bridging the communication gap that
exits between non technical system owners and users as well as
the technical system designers and builders.
 DATABASE SYSTEMS APPROACH

 A database is a single organized collection of structured data,

stored with a minimum duplicated data so as to provide a
consistent and controlled pool of data.
 This data is common to all users of the system, but is independent
of programs that use the data.
 DATABASE SYSTEMS APPROACH
Features that characterize a database approach:
Shareability of data - Data is stored in a centralized database to which

all potential users are permitted access.

Centralized control - The database is managed and controlled by a

Database Administrator.
 Centralization enables DBA to be impartial toward individual

departments needs and to make decisions that are to the best of the
interest of the organization.
Adaptability - Database approach is adaptable to change.

 It allows users to easily relate existing data items quickly to others

that emerge.
 New requests are easily assimilated into the existing database as

the database grows.

 DATABASE SYSTEMS APPROACH

Weaknesses of Traditional file approach

Data redundancy - These files are likely to have some data in

common, i.e. duplication of data. This is called data redundancy. This

makes it expensive to store and update such files.
Lack of data integrity - Since the files are maintained separately

data about one record may bear inconsistent values, thus leading to
inaccurate reporting.
Incapable of ad hoc reporting - Since the files are not related easily

it would take much time to get an unplanned-for report involving data

analysis from all the functional files.
Security risks - The data is owned by the departments that use it and

therefore it is not easily to control the data as an organization resource.

This makes data possible to be subject to fraud.
 DATABASE SYSTEMS APPROACH

Advantages of Database approach

Redundancy control - Data items are stored ideally once therefore

there is reduced replication on data.

Improved data integrity - There are therefore no inconsistencies in

data stored. This is an aspect of data integrity.

Improved data security - This done using user names and

passwords, and assignment of user rights and their subsequent

revoking when necessary
Data independence - The data in the database is independent of the

programs that access it and the storage media in which it is stored.

Therefore programs that access the data can change without need to
change the database or even the storages.
 DATABASE SYSTEMS APPROACH

Advantages of Database approach

Multiple external database / sub schemas /user views - Since the

database is designed around the organization rather than specific

applications it is possible to have many user views or sub schemas
according to users needs.
Reduced overall cost - Due to reduced redundancy, data

independence and consequently database adaptability, there are

substantial cost reductions by use of database approach.
Data Shareability - Data in a database is widely available for all

users
 DATABASE SYSTEMS APPROACH

Advantages of Database approach

Data as Organization resource - Installation of a database

encourages management of data as an organization resource thus

fostering the achievement of organizations objectives.
Ease in auditing - Data is centrally managed and controlled so it

makes it easy to audit the system for it efficiency and effectiveness.

 DATABASE SYSTEMS APPROACH

Disadvantages of database approach

Complex conceptual - Developing a conceptual database for an

entire organization is usually too complex.

High acquisition costs – Need to hire database related employees,

An organization must hire a DBA and other related staff, system

development time, acquisition of DBMS software, file conversion,
database operations: such as back-ups
Complex programmer environment - Testing a DBMS during its

development is very complex.

Potentially catastrophic - If DBMS fails the loss to the

organization can be great since its operations may get totally

impaired.
 DATABASE SYSTEMS APPROACH

Disadvantages of database approach

Longer running time for applications - As programs complexity

increases, so does the amount of time required to run the program.

Therefore applications using DBMS may take longer to run unless
installed on very fast CPUs or disk drives and remain memory
resident.
High costs of operations - The costs of converting applications to a

new DBMS are quite high.

 DATABASE SYSTEMS APPROACH
 Other Data Management Approaches

 Application specific files approach- otherwise know as the

traditional file processing approach.
 Focus is on informational needs of individual

departments/applications. For example, Accounting department

has its own application, similarly Sales,
 Functional files approach – Based on functional areas such as
Production, Purchases department and others each have their own
application.
 This means there is a set of files dedicated to each business

function with each set being accessed by a different program.

 SYSTEMS IN ORGANIZATIONAL LEVELS

 Information is categorized in relation to the managerial levels for

the respective decision making processes
 Strategic info - relates to the long range planning policies that

are of direct interest to the top management

 Managerial info – mainly used for the implementation and

control e.g. sales analysis, cash flows projections annual

financial statements etc
 Operational info – used to operate departments and enforces

daily rules and regulations of the business

 SYSTEMS IN ORGANIZATIONAL LEVELS

 The lack of structure and incomplete information make it difficult

to secure computer support.
 Thus an analyst has to determine the following
 Type of information required at different managerial levels

 Application of information at its respective level

 Structure and format of representing information

 Generally, the decision making at operational level is highly

structured, at managerial level is semi-structured and at the
strategic level it is unstructured
 SYSTEMS IN ORGANIZATIONAL LEVELS

 STRATEGIC LEVEL
The characteristics of the information at the strategic level is as
follows
 Unstructured - concerned with long term goals of an

organization and that decisions will provide guidelines on which

the firm will run
 Source – the information is obtained from both internal and

external sources and help in the policy formulation

 Complex - high uncertainty requiring experience and good sense

of judgement for the strategic planning and allocation of resources

 Summarized – info usually in the form of reports and records and

less qualitative and quantitative

 SYSTEMS IN ORGANIZATIONAL LEVELS

 MANAGERIAL LEVEL
The characteristics of the information at the strategic level is as
follows
 Semi-structured - concerned with medium range goals of an

organization
 Source – usually of medium quality and obtained from restricted

range of sources
 Largely quantitative – based on routine operations and non

procedural decision making process

 Less summarized – information is obtained from both internally

and less externally and helps in resource allocation

 SYSTEMS IN ORGANIZATIONAL LEVELS

 OPERATIONAL LEVEL
The characteristics of the information at the strategic level is as
follows
 Structured – decisions associated with activities that are routine

and cover short time frame

 Source – info derived internally and is relevant in short term

 Highly quantitative – information is obtained from quantitative

data, highly detailed and help in the daily routines and procedures
End Lesson 2
Lesson 3
SYSTEM ANALYSIS

Objectives
 Context of System Analysis
 Information System Analyst
 System Requirements
 System Analyst
 System Investigation and Analysis
 System design techniques
 SYSTEM ANALYSIS

 System Analysis – is a problem – solving technique that

decomposes a system into its component pieces for the purpose of
studying how well those component parts work and interact to
accomplish their purpose.

 Information System Analysis - involves those development

phases in a project that primarily focus on the business problem,
independent of any technology that can or will be used to
implement a solution to that problem.
 SYSTEM ANALYSIS

 System design - is the process of defining the architecture,

components, modules, interfaces, and data for a system to satisfy
specified requirements.

 System analyst - studies a problem, recommends on the need to

organize people, data, processes and communication in the best
manner possible to accomplish improvements on the operations of
a business.
 SYSTEM ANALYSIS

A system analyst is responsible for:

Efficient capture of data from its business source

Flow of the data to the computer

Processing and storage of data –info by the computer

Flow of useful, accurate and timely info back to the Business and its

people
 SYSTEM ANALYSIS

Scenarios that lead to system analysis include:

Problems – Actual / situations that are real / anticipated problem

that may require corrective action

Opportunities – new ways to improve a situation despite absence

of complaints
Directives - priorities to change a situation regardless of any / no

complaint about the current system

 SYSTEM ANALYSIS

The general problems-solving approach involves

Identify the problem

Analyze and understand the problem

Identify solution requirements and expectations

Design and implement the best alternative

Evaluate the results for appropriate conformity

 INFORMATION SYSTEM ANALYSIS

 Information System Analysis concerns development phases in a

project that focus on the business problem independent of the
technology that can/will be used to implement a solution to that
problem
 The system analyst has to learn about the setting of the existing
system, prepare an organization chart listing all the functions and
the people who perform them.
 During analysis needs or requirements of the user and the
information flow that will satisfy those needs or requirements are
determined
 INFORMATION SYSTEM ANALYSIS

However, it is difficulty to determine precisely and accurately

user requirements because:
User requirements change and the system must be modified to

accommodate such changes.

Articulation of the requirements is difficult except in the case of

experienced users.
Heavy user involvement and motivation is difficult

Patterns of interaction between users and analysts in designing

information requirements are complex.

 INFORMATION SYSTEM ANALYSIS

However, it is difficulty to determine precisely and accurately

user requirements because:
Humans have problems in specifying information requirements and

their contribution towards a candidate system may not yield accurate

and complete requirements.
 SYSTEM REQUIREMENTS

System requirements are descriptions of function, features,

attributes and constraints on the needs and desires for an IS.
Requirements discovery - is a technique used by the system

analyst to identify / extract system problems and solutions

requirements from the user community.
Cause and effect analysis - is a technique in which problems are

studied to determine their causes and effects

Other requirements are classified as nonfunctional and include

description of activities and services a system must provide.

The objective of an Information System Analysis is a measure of

success with regard to something one expects to achieve given

sufficient resources.
 SYSTEM REQUIREMENTS

Criterion for defining the system requirements is as follows:

 Consistent - in all similar system aspects without disparity

 Complete - considering the whole range of the system

scenario.
 Feasible - narrowing to the realizable requirements

 Required - requirements that conform to the system needs

 Accurate - should have no errors or ambiguous situations

 Traceable - correct working code in all stages either forward or

backward
 Verifiable - formatting into formal styles
SYSTEM ANALYST

 A system analyst is the person who conducts a study, identifies

activities, assesses objectives and determines the procedure to
achieve the objectives
 In computing the analyst assumes the role of a problem solver
by specializing in and developing computer applications
 Success in system analysis requires interpersonal skills which
emphasize the communication and the interface with the user;
and technical skills which are used during system design phase
 SYSTEM ANALYST

The interpersonal skills relevant to the systems anayst include

among others:-
Communication – having the ability to articulate and speak the

language of the user through listening, talking, feeling and reacting

to one another
Understanding – identifying problems and assessing their

ramifications, having a grasp of goals and objectives and showing

sensitivity to impact of system on the people at work
Knowledgeable – educating people in the use of computer systems,

acceptance as their property and giving support when needed;

concerning the basics of the computer and the business functions
 SYSTEM ANALYST

The interpersonal skills relevant to the systems worker include

among others:-
Innovation – selling of ideas and promoting innovations in the

problem solving using computers

The technical skills include:

Creativity – helping users to model ideas into concrete plans and

developing candidate systems to match user requirements

Problem solving - reducing problems to their elemental levels for

analysis, developing alternative solutions to problems and reduce the

disadvantages of the candidate system
 SYSTEM ANALYST

The technical skills include:

Project management – performing well under schedule, time

constraints, coordinating team efforts and managing costs and

expenditures
Dynamic interface – blending technical and non-technical

considerations into functional specifications and the general design

Skills enhancement – questioning altitude and an inquiring mind to

knowing all the aspects of the system’s work

 SYSTEM ANALYST

 The interpersonal skills deal with the user training and selling the
user the benefits and potentials of the candidate system.
 During system analysis there is a greater need for interpersonal
skills since it concerns analyst working with the user to determine
requirements and translate them into design criteria.
 The analyst has to capture the inner working of a business and
have competence in system tools and methodologies
 SYSTEM ANALYST

ROLE OF SYSTEM ANALYST

Change agent – a new system is designed to introduce changes and

orientations in how the user organization handles information or

makes decisions. To overcome the problem of resistance to new
systems being effected there need to be a careful plan, monitor and
implement change into the user domain
Investigator - in defining problem, the analyst puts together the

information gathered to determine why the present system does not

work well and what changes will correct the system
Monitor – follow up of programs in relation to time, cost and

quality to successfully complete the project

 SYSTEM ANALYST

ROLE OF SYSTEM ANALYST

Designer – reconcile the user’s logical design requirements and the

detailed physical design by assisting users to formalize abstract ideas

and by providing the details of the new system
Communicator – effective manner in which the system analyst

reaches the system users, interprets thoughts, assess behaviour and

draws conclusions from these interactions
Sales person - the oral presentation of the system to the user’s

acceptance through skills and persuasiveness of the analyst to the

success of the system
 SYSTEM ANALYST

ROLE OF SYSTEM ANALYST

Motivator - system acceptance is achieved through user

participation, effective user training and proper influence to the use

of the system
Diplomacy – fineness to deal with the user improves the acceptance

of the system where their thinking and ideas are revealed in the
achieved goals and objectives
In conclusion, an analyst has to be orderly, pay attention to details

and approach a problem in a logical and methodical way. The analyst

is to concentrate on the objective data, be highly perceptive and seek
the best method
 SYSTEM ANALYST

CHALLENGES FACED BY ANALYST

Complexity - ambiguity in the process of analysis and design in

which picking the best design out of the many alternatives is a

difficult task
Integration – difficulty in choosing the appropriate analysis and

design tools since each project has a different intelligence that needs
to be tackled differently
Currency - keeping track of the latest HW and SW for appropriate

recommendations
Modification – adjusting to suit changes to the requirements after a

project has began, may be changes due to evolving technology

 SYSTEM ANALYST

CHALLENGES FACED BY ANALYST

Personality – problem of working with individual personalities

which is usually time consuming

Dynamism – problem of working with group dynamics in which

people have different goals and personality conflicts

Affiliation - tendency to be wooed to a political situation in which

politics can affect the implementation of a new system

 SYSTEM INVESTIGATION AND ANALYSIS

 Planning for an Information System is important because

information is a vital resource and a business asset established on
the basis of databases and networking.
 Planning for an Information System has a time frame that
specifies the range of plan and the focused dimensions that relates
the concerns on the strategic, managerial and operational systems
 SYSTEM INVESTIGATION AND ANALYSIS

Conditions and dimensions of planning that dictates the business

strategies are:
Resource shortage impede expansion

Inflation when it occurs puts pressure on profits

Guaranteed employment suggests that costs are becoming fixed

High interest rates make it important that a business has a good

return on investment
 SYSTEM INVESTIGATION AND ANALYSIS

SYSTEM INVESTIGATION
The initial investigation has the objective of determining the

validity of the user’s request for a candidate system and whether a

feasibility study should be conducted.
Recommendation is reached to do nothing, improve or modify the

existing system or build a new system.

The success of system depends largely on how accurately a problem

is defined, thoroughly investigated and properly carried out through

the choice of a solution.
The objectives of the problem situation must be understood within

the framework of the organization’s Management Information

System
 DETERMINING INFORMATION REQUIREMENTS

General strategies or approaches for determining or eliciting

information regarding user requirements include the following:
ASKING
Probing users about the requirements assuming that the users are

well informed and can overcome biases in defining their problems

Questions – closed or open ended questions that allow the

respondent to formulate a response

Brainstorming – technique for generating new ideas eliciting non

conventional solutions to the problems, by allowing participant to

define ideal solutions and then select the feasible best one
Group consensus – ask the participants for their expectations

regarding specific variables

 DETERMINING INFORMATION REQUIREMENTS

DATA ANALYSIS
 This approach involves getting information from the existing

Information System by asking the user about the information

currently received and any other required.
A drawback is lack of established rules for obtaining and validating

information needs that are not linked to organization objectives

 DETERMINING INFORMATION REQUIREMENTS

PROTOTYPING
Prototyping is an approach of building a model to represent the new

system on which to base requirements and help in visualizing the

candidate system.
It is Applicable in formulating a concrete model and for defining

information requirements especially where the info needs of the user

are evolving.
This strategy is appropriate for high uncertainty information

requirements determination
 DETERMINING INFORMATION REQUIREMENTS

COST – BENEFIT ANALYSIS

Cost – benefit analysis involves listing all costs and benefits of the

proposed information system

Estimates are done on both quantifiable costs and benefits, which

are then compared to enable decision making

Feasibility report is prepared containing the background, terms of

reference, reasons for the study, current situation and its overview,
identified problems and requirements, proposed situation (with
technical, operational and cost implications), cost – benefit analysis
and its recommendations
 FEASIBILITY STUDY
Is a fact –finding process to show or reveal the viability and the
ability to successfully complete a proposed system project
Economic feasibility – concerns the financial assessment of

benefits of the project that may be tangible or Intangible

Technical feasibility – assessing the availability of HW and SW in

the market for the technical expertise needed to develop, operate and
maintain the system
Operational feasibility – assessing whether the system will meet the

user’s operational and functional requirements and win their opinion

and feeling towards the system
 FEASIBILITY STUDY
 Organizational feasibility – assessing the likelihood that the
project will attain its desired objective and its impact on the
organization
 Schedule feasibility – assess whether the project can achieve a
specified deadline, its impact and the attributes for a possible
delay
 Political feasibility – assesses how the stakeholders in an
organization view the proposed system, impact on the distribution
of power within the organization or institution
 Contractual feasibility – legal ramifications related to the
development of the system (e.g. copyrights infringement)
intellectual property rights, antitrust legislation, reporting
standards
End Lesson 3
Lesson 4
SYSTEM DEVELOPMENT LIFE
CYCLE

Objectives
 System Development Life Cycle
 Feasibility Techniques
 Fact – Finding Techniques
 Analysis and Design Tools
 SDLC:
 A system development process is a set of activities, methods, best
practices, deliverables and automated tools that stakeholders use
to develop and maintain IS and SW
 A system development methodology is a very formal and precise
system development process that system developers and project
managers are to use to develop and maintain IS and SW
 A system life cycle divides the life of an IS into stages:-
 System development using development methodology
 System operation, support and maintenance using IT
 SDLC:

 System Development Life Cycle (SDLC) involves stages that a

system analyst must traverse as he progresses from one stage to
the other methodically answering questions and achieving results
in each stage.
 The life cycle activities or stages are only isolated theoretically;
but in reality they overlap and are highly interrelated
 SDLC:

The principles of system development includes:

Get the owners and users involved

Use a problem solving approach noting causes and symptoms

Establish phases, activities and tasks (SDLC)

Establish standards to be observed in the development process

Justify the system as a capital investment especially with feasibility

study
Do not be afraid to cancel or revise the scope

Divide the activities into manageable process

Design systems for growth and change

 SDLC:

CONTEXT OF SYSTEM ANALYSIS

Information System Analysis is a representation of the various

stages or phases that are followed in the complete process of system

analysis and design
Involves step by step activities for each phase, roles, deliverables

and quality standards, tools and techniques

All methodologists are derived from a logical problem solving

process called System Development Life Cycle (SDLC)

SDLC is a logical process that is used by System Analyst, SW

engineers / programmers and end users to build system and solve

business problems; and involves the following stages
 SDLC STAGES:

 Preliminary investigation - Involves identifying problems,

opportunities and directives on project requests assignments and
problem statements.

 Feasibility study - Evaluation of the existing system

demonstrating user’s needs, effective use of resources, workability
and the impact of the proposed system to the organization.
 Procedures, cost estimates and analysis of the alternatives of the
candidate system in the view of redefining the problem and
assessing the problem worth solving.
 SDLC STAGES:
 Analysis of the System- A detailed evaluation of the current system
stating operation and ways to solving the problems where a logical
model of the system is made Data collection is carried out concerning
the facts and the processes which are then presented in the data flow
diagrams and the data dictionary
 System Design - Generally, detailed design specification on inputs,
procedures, outputs and files
 Here alternative solutions are designed through final cost benefit
analysis; cost estimates, hardware and implementation specifications.
 System development
 A program is constructed, modules combined and tested for the users
acceptance and the approval of the system, based on the test plans,
security, audit and the operating procedures
 SDLC STAGES:

 Implementation- Through the system and file conversion, as well

as user training stating actual operations guided by ready user
manuals.
 The training program and documentation should be user friendly
catering for prompt responses, delays or malfunctions e.g. in
loading and manipulation of files

 Operations and Maintenance-These involve evaluation of

performance and any necessary modifications to the
enhancements towards the system running and safeguard.
 The user requirements are checked and met to the expected
standards and satisfaction
 SDLC STAGES:
 Project termination - A system project can be dropped at any
stage prior to the implementation although it becomes costly and
difficult when it goes past design phase.
 Generally, after the review process a project may be dropped on
the following reasons
 The project greatly exceeds the time and cost schedule

 Sudden change in the users’ budget usually by being inflated

 Increase in design costs beyond the estimate made during

feasibility study
 User changing requirements / objectives that can not be met by the

existing design
 Benefits realized from the proposed system do not justify

commitment to implementation
 IMPORTANCE OF PROJECT SCHEDULING

 The project manager musts know the duration of each activity, the
order in which the activities must be performed, the start and end
times for each activity, and who will be assigned each specific
task.
 The scheduling allows for a balanced activity time estimate,
sequences and personnel assignments to achieve a workable
schedule, which is essential for project success
 The schedule provides:
 Effective use of estimating processes

 Ease in project control

 Ease in time or cost revisions

 Allows for better communication of project tasks and deadlines

 CRITERIA FOR DEFINING PROJECT SUCCESS

Successful Project:
 Within the allocated time
 Within the budgeted cost
 At the proper performance or specification level
 With acceptance by the customer/user
 With minimum or mutually agreed upon scope changes
 Without disturbing the main work flow of the organization
 Without changing the corporate culture
 Within required quality and standards thus use the customer’s
name as a reference
 POTENTIAL BENEFITS OF PROJECT
MANAGEMENT
 Identification of functional responsibilities to ensure that all
activities are accounted for regardless of personnel turnover
 Minimizing the need for continuous reporting
 Identification of time limits for scheduling
 Measurement of accomplishment against plans
 Early identification of problems so that corrective action may
follow
 Improved estimating capability for future planning
 Knowing when objectives cannot be met or will be exceeded
 ESTABLISHING SYSTEM REQUIREMENTS

 Definition - Systems requirement is a detailed statement of the

(systems) needs that a new system solution must satisfy, identify
who needs it, where, when and how.
 It defines objectives of the new/ modified system

 It develops a detailed description of the functions the new

system must perform

 It must consider economic, technical and time constraints

 It must also consider goals, procedural and decision process of

the origin
 ESTABLISHING SYSTEM REQUIREMENTS

 Faulty/ poor requirements analysis is leading cause of system

failure and high system development costs.
 It is difficult to attain the requirements if the user is unsure of what
they want/ need.
 Information requirements involve identifying who needs what
information, where, when, and how.
 They define the objectives of the new or modified system and
contain a detailed description of the functions the new system must
perform.
 Gathering information requirements is perhaps the most difficult
task of the systems analyst, and faulty requirements analysis is a
leading cause of systems failure and high systems development
costs.
 ESTABLISHING SYSTEM REQUIREMENTS

 Information requirements are difficult to determine because

business functions can be very complex and/or poorly defined.
 A manual system or a routine set of inputs and outputs may not
exist.
 Procedures may vary from individual to individual, and users may
disagree on how things are or should be done.
 Defining information requirements is a laborious process,
requiring a great deal of research and often many reworking by
the analyst.
 SYSTEMS DESIGN

 Systems Design details how a system will meet the information

requirements as determined by the systems analysis i.e. how it
will fulfill the objectives
 It is the overall plan or model for the system.
 It consists of all specifications that give the system its form and
structure
 An exacting and creative task demanding imagination sensitivity
to detail and expert skills
 SYSTEMS DESIGN

 System designer is responsible for:

 Considering alternative technology configurations for carrying out
and developing the system as described by the analyst”- by
analyzing performance of different hardware, software, security,
changeability, portability etc of hardware
 Management and control of the technical realization, testing and
training
 Also actual procurement of Hardware, consultants, Software
needed by the system
 SYSTEMS DESIGN

 Detail system specification that will deliver the functions

identified during system analysis, which should address all
components of the system solution.
 The main principle of structured design is that a system should be
designed from the top down in hierarchical fashion and refined to
greater levels of detail.
 TYPES OF SYSTEM DESIGN

 Logical design - lays out the components of the system and their
relationship to each other, as they would appear to user.
 Show what the user would do not how

 Describes input and outputs, processing functions procedures

and controls

 Physical Design - is the process of translating the abstract logical

model into the specific technical design for the new system.
 Produces actual specifications for Hardware, Software, physical

database, input/output media, manual procedure and specific

control
 TYPES OF SYSTEM DESIGN

 End users must participate to specify requirements (that drive its

system building efforts), give the priorities, needs and biases.
 This increases acceptance, and reduces unfamiliarity, power

transfer and inter-group conflicts.

 SYSTEM PROGRAMMING

 Programming is the process of translating system specifications

prepared during design stage into (program code (solution)) a full
operational system.
 Programming is the process of translating system specification
into program code.
 SYSTEM PROGRAMMING

 Software tools required by the developer and should have: -

 Language translators – compilers and assemblers

 Module linkers and libraries

 Error reporting features

 Specification requirements and validation features

 Documentation processing and production

 Estimation, planning and process monitoring tools

 Testing tools
 SYSTEM PROGRAMMING

 Structured programming extends the principles of structured

design to the writing of programs to make software program easy
to understand and modify.
 It is based on the principle of modularization, which follows from
top down analysis and design.
 SYSTEM TESTING

 The exhaustive and thorough process that determines whether the

system produces the desired results under known conditions, 50%
of budget is in testing.
 Test date must be carefully prepared, results reviewed and
corrections made in the system.
 SYSTEM TESTING

 Testing is divided into three activities:

 Unit testing - This is the process of testing each unit (sub-system)

separately in the system (program testing)

 System testing - It tests the functioning of the system as a whole

(integrated system) to determine if discrete units (sub-systems)

will function together as planned
 Acceptance testing - Provides the final certification that the

system is ready to be used in a productive setting.

 To ensure testing is clear and comprehensive a systematic test
plan must be employed
 The development team and users prepare Test plan with details
on how tests will be carried out.
 REASONS FOR SYSTEM FAILURE
 The new system was not user friendly
 Users of the system changed their requirements
 Poor user training for system acceptance
 The user staff being hostile and resistant to change
 User requirements were not clearly defined, understood or met
 The Analyst, programmer or both were inexperienced
 Lack of involving users directly in the crucial phases of the system
development
 Existing hardware proved deficient to handle the new applications
 System analyst doing the work under stringent time constraints hence
poor feasibility and design
 Lack of integration of the info and the various departments that the old
system had provided
 REASONS FOR SYSTEM FAILURE
Assignment:
Propose ways to combat each of the aforementioned system

failures.
End Lesson 4
Lesson 5
SYSTEM ANALYSIS METHODOLOGY

Objectives
 System Models
 System Tools
 CASE
 GANT
 PERT
 SYSTEM ANALYSIS METHODOLOGY

System development structure includes methodologies, techniques

and tools:
Methodologies are formalized, comprehensive and multi-step

approaches that guide the system development process

Techniques are the particular processes that are used to complete

the work of the systems development by describing the activities and

tasks that will be employed to achieve the defined deliverables
Tools are the objects, programs and any other necessities that help

to accomplish tasks.
 Thus techniques are the procedure that apply tools in carrying out a

methodology and includes Project selection process and Project plan,

System requirement definition and System models
 SYSTEM ANALYSIS METHODOLOGY

SYSTEM TOOLS
The analyst begins by creating a model / representation of reality

i.e. facts, relationships, procedures, processes of the system.

 SYSTEM ANALYSIS METHODOLOGY

System models show the benefits of abstracting complex systems,

and includes

Schematic Tools - this is a two dimensional chart depicting the

system elements and their linkages e.g. banking environment with
elements: human resources, payroll, applicant report, loan
department, book keeping department, teller department etc
 SYSTEM ANALYSIS METHODOLOGY

 Flow system Tools – this shows the flow of materials, energy and
information that hold the system together.
 In it there is orderly flow of the logic, manipulation of specific
values to determine the critical path, interpret the relationships
and relay them back as a control
 Project Evaluation and Review Technique (PERT) models show
the schedule for the completion time in relation to resources and
the performance specifications
 SYSTEM ANALYSIS METHODOLOGY

 Static system Tools – exhibits one pair of relationships e.g.

activity – time or cost – quantity e.g. Gantt charts
 Dynamic system Tools – approximates the type of organization
that the analyst deal with i.e. depicts an on-going, constantly
changing system.
 Consists of inputs, processes for the inputs and outputs resulting
from the processing
 SYSTEM ANALYSIS METHODOLOGY

 CASE TOOLS FOR SYSTEM MODELLING

 Computer Aided Software Engineering (CASE) Tools is a
software package that supports construction and maintenance of a
logical system specification model.
 Designed to support rules and interactions of models defined in a
specific methodology.
 Also permit software prototyping and code generation
 Aim to automate document production process by ensuring
automation of analysis and design operations
 SYSTEM ANALYSIS METHODOLOGY

Advantages of CASE Tools

Make easy construction of the various analysis and design logical

elements e.g. DFD, (Program Evaluation and Review Technique )PERT.

Integration of separate elements allowing software to do additional

tasks e.g. rechecking and notifying on defined data and programs

Streamline the development of the analysis documentation allowing

for use of graphics and manipulation of the data dictionaries

Allow for easy maintenance of specifications which in turn will be

more reliably updated

 SYSTEM ANALYSIS METHODOLOGY

Advantages of CASE Tools

Enforce rigorous standards for all developers and projects making

communication more efficient

Check specifications for errors, omissions and inconsistencies

Provide everyone on the project team with easy access to the latest

updates and project specifications

Encourage iterative refinements resulting to higher quality system

that better meets the needs of the users

 SYSTEM ANALYSIS METHODOLOGY

 Disadvantages
 CASE products can be expensive

 CASE technology is not yet fully evolved so its software is

often large and inflexible

 Products may not provide a fully integrated development

environment
 There is usually a long time for learning before the tools can be

effectively used i.e. no soon benefits realized

 Analysts must have a mastery of the structured analysis and

design techniques if they are to exploit CASE tools

 Time and cost estimates may have to be inflated to allow for an

extended learning period of CASE tools

 SYSTEM ANALYSIS METHODOLOGY

GANTT CHARTS
A Gantt chart is a horizontal bar chart that illustrates a project task

against a calendar.
The horizontal position of the bar shows the start and end of the

activity, and the length of the bar indicates its duration.

For the work in progress the actual dates are shown on the

horizontal axis
A vertical line indicates a current or reporting date
 SYSTEM ANALYSIS METHODOLOGY

GANTT CHARTS
To reduce complexity a Gantt chart for a large project can have a

master chart displaying the major activity groups (where each

activity represents several task) and is followed by individual Gantt
charts that show the tasks assigned to team members.
The chart can be used to track and report progress as it presents a

clear picture of project status

It clearly shows overlapping tasks- tasks that can be performed at

that same time

 SYSTEM ANALYSIS METHODOLOGY

GANTT CHARTS
Popular due to its simplicity – it is easy to read, learn, prepare and

use
More effective than PERT/CPM charts when one is seeking to

communicate schedules
They do not show activity dependencies.

One cannot determine from the Gantt chart the impact on the entire

project caused by single activity that falls behind schedule.

The length of the bar only indicates the time span for completing an

activity not the number of people assigned or the person days

required
 SYSTEM ANALYSIS METHODOLOGY

PERT/CPM
Program Evaluation and Review Technique (PERT), (Also Critical

Path Method – CPM) is a graphical network model that depicts a

project’s tasks and the relationships between those tasks.
The project is shown as a network diagram with the activities

shown as vectors and events displayed as nodes.

Shows all individual activities and dependencies

It forms the basis for planning and provides management with the

ability to plan for best possible use of resources to achieve a given

goal within time and cost limitations
It provides visibility and allows management to control unique

programs as opposed to repetitive situations

 SYSTEM ANALYSIS METHODOLOGY

PERT/CPM
Helps management handle the uncertainties involved in programs

by answering such questions as how time delays in certain elements

influence others as well as the project completion.
This provides management with a means for evaluating alternatives

It provides a basic structure for reporting information

Facilitates what if exercises

It allows one to perform scheduling risk analysis

Allows a large amount of sophisticated data to be presented in a

well organized diagram from which both the contractor and the
customer can make joint decisions
 SYSTEM ANALYSIS METHODOLOGY

PERT/CPM
Allows one to evaluate the effect of changes in the program

More effective than Gantt charts when you want to study the

relationships between tasks

Requires intensive labour and time

The complexity of the charts adds to implementation problems

Has more data requirements thus is expensive to maintain

Is utilized mainly in large and complex projects

 SYSTEM ANALYSIS METHODOLOGY

NOTE:
Gantt Charts and PERT/CPM are not mutually exclusive techniques

project managers often use both methods.

Neither handles the scheduling of personnel and allocation of

resources
 SYSTEM ANALYSIS METHODOLOGY

NETWORK ANALYSIS
Network analysis is a generic name for a family of related

techniques developed to aid management to plan and control

projects.
It provides planning and control information on time, cost and

resource aspects of a project.

It is most suitable where the projects are complex, large or

restrictions exist.
The critical path method is applied most where a network is drawn

either an activity on arrow or activity on node network.

 SYSTEM ANALYSIS METHODOLOGY

NETWORK ANALYSIS
In the network analysis a project is broken down into consistent

activities and their presentation in a diagrammatic form.

In the CPM one has to analyze the project, draw the network,

estimate the time and cost, locate the critical path, schedule the
project, monitor and control the progress of the project and revise the
plan.
 SYSTEM ANALYSIS METHODOLOGY

 Example: draw a network and find the critical path for the
following project
 SYSTEM ANALYSIS METHODOLOGY

ADVANTAGES OF PROJECT MANAGEMENT TOOLS

Easier visualization of relationships – a produced network

diagram shows how the different tasks and activities relate together
making it easier to understand a project intuitively, improving
planning and enhancing communication details of the project plan to
the interested parties
More effective planning – CPM forces the management to think

the project through for it requires careful detailed planning and high
discipline that justifies its use
Better focusing on the problem areas – the technique enables the

manager to pin-point likely bottle-necks and problem areas before

they can occur
 SYSTEM ANALYSIS METHODOLOGY

ADVANTAGES OF PROJECT MANAGEMENT TOOLS

Improve resource allocation – resources can be directed where

most needed thus reducing costs and speeding up completion of the

project, e.g. overtime can be eliminated or confined to those tasks
where it will do most good
Strong alternative options – management can simulate the effect

of alternative causes of action; and gauge the effect of problems in

carrying out particular tasks and making contingency plans
 SYSTEM ANALYSIS METHODOLOGY

ADVANTAGES OF PROJECT MANAGEMENT TOOLS

Management by exception – CPM identifies those actions whose

timely completion is critical to the overall timetable and enables the

leeway on other actions to be calculated.
This enables the management to focus their attention on important

areas of the project

Improve project monitoring – by comparing the actual

performance of each task with the expected the manager can

immediately recognize when the problems are occurring, identify
their causes and take appropriate action in time to rescue the project.
End Lesson 5
Lesson 6
SYSTEM DEVELOPMENT
MODELS

Objectives
 Types of models
 Benefits of System models
 System Development Process
 System Development Models
 SDLC
 Waterfall
 Prototyping
 Spiral Development Models
 SYSTEM DEVELOPMENT MODELS

 A model is a simplified pictorial representation or abstraction of

reality where information is recorded in an unambiguous and
concise manner using diagrams and limited amount of text
 However reality is generally too complex to copy exactly even
though the complexity may be irrelevant in problem solving
 System modeling is use of pictorial / diagrams as structured
techniques to develop and record information which is universally
accessible and applicable by other system analysts / designers /
developers
 SYSTEM DEVELOPMENT MODELS

TYPES OF MODELS
Logical models - Also known as essential conceptual or business

models
Show what a system is / does disregarding its technical

implementation
Physical models - Also known as implementation \technical

models
Show what the system is / does and its technical implementation

reflecting on the choices and their limitations

 SYSTEM DEVELOPMENT MODELS

 System analysis relies much on the logical models due to the

reasons
 Eliminate biases on the implementation of the new system to

the current one

 Reduce risks of omitting business requirements due to much

attention to the technical details

 Allow communication of the stakeholders in a less technical

language
 SYSTEM DEVELOPMENT MODELS

 BENEFITS OF SYSTEM MODELS

 Can model risk and uncertainty

 Allow easy model manipulation

 Lead to low cost of system construction

 Enhance and reinforce learning and training

 Reduce time for system analysis and implementation

 Facilitate efficiency through low cost of execution especially

that of errors
 Can model large and extremely complex systems with possibly

infinite solutions
 SYSTEM DEVELOPMENT MODELS

SYSTEM DEVELOPMENT PROCESS

Any System Development process can be represented by a model

called System Development Life Cycle (SDLC)

It contains 5 stages that flow from one to the next in order (hence

the 'waterfall' imagery).

There are alternatives to SDLC that includes:

 Waterfall model

 Prototyping

 Iterative Development

 Spiral Model of the SDLC

 SYSTEM DEVELOPMENT MODELS

WATERFALL MODEL
The waterfall model (sometimes called the classic life cycle or the

linear sequential) was the first explicit model of the software

development process.
Prior to this time there had been a number of significant failures of

systems projects.
The main reasons for the failures appeared to be a lack of formality

in the design and control of those projects.

In the waterfall model system design is broken down into a number

of sequential stages, with each stage being as a separate box in the

model.
 SYSTEM DEVELOPMENT MODELS

WATERFALL MODEL
The development process was not allowed to move onto the next

stage until work on the previous stage had been completed.

The outputs from each stage form the inputs of the next stage;

therefore each stage had to be completed to maintain the links

between the outputs and inputs.
The traditional lifecycle is useful for large projects that need formal

specification and tight management control over each stage of

system building.
However, the lifecycle is very rigid, and costly for developing a

system.
 SYSTEM DEVELOPMENT MODELS

WATERFALL MODEL
Volumes of new documents must be generated and steps repeated

if, requirements and specifications need to be revised.

Because of the time and cost to repeat the sequence of lifecycle

activities, the methodology encourages freezing of specifications

early in the development process, discouraging change.
It is not well suited for unstructured, decision-oriented applications

where requirements cannot be immediately visualized.

It is difficult to accommodate changes after the process is underway

.
 SYSTEM DEVELOPMENT MODELS

WATERFALL MODEL
Real projects rarely follow the sequential model that the model

proposes.
The customer must be patient as a working version will only be

available late in the project time span and does not accommodate
customer uncertainty.
The model is only appropriate when the requirements are well-

understood
 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

1. Preliminary investigation

 Concerns problem specification, scoping and feasibility study

 Identify the need to base decisions and address certain

problems
 Identify constraints on time and project resources

 Establish objectives by determining system outlook

 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

2. Requirements analysis

 Basically, specify the problem in concrete terms without being

overly specific
 Define detailed requirements necessary to assist in the

performance of the software

 The information domain for the system is analyzed to identify

data flow characteristics, key data objects and overall data

structure
 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

3. System design

 Top – Down approach - this approach decomposes the main

task into sub-tasks and even smaller sub-tasks resulting in a tree

of tasks and components
 Bottom – up approach – this anticipates useful system

building tools. Combines the tools to construct application

specific tools, thus a final application is build out of the
existing tool boxes
 Hybrid Approach – build library of general purpose and

application specific
 Decomposes main task into sub-tasks with available tools
 Reuse the existing code whenever possible to save time and effort
 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

4. System Implementation

 Essential to keep internal documentation up to date

 Need to code and debug each component of the system

 Implement code algorithms for each component incrementally

5.System testing and Installation

 Verify that the whole system meets design specifications

 Find problems based on program specifications

 Document the tests run for each program revision

 SYSTEM DEVELOPMENT MODELS

Waterfall model contains the following stages

6. Operation and Maintenance

 Make necessary system improvements e.g. debugging

 May use prototype in refining the system by enabling the re-

capture of user requirements and feedback prior to the real

system
 SYSTEM DEVELOPMENT MODELS

 This is the most widely used approach to software engineering.

 It leads to systematic, rational software development, but like any
generic model, the life cycle paradigm can be problematic for the
following reasons:
 Do these potential problems mean that the life cycle paradigm
should be avoided?
 Absolutely not!
 They do mean, however, that the application of this software
engineering paradigm must be carefully managed to ensure
successful results.
 SYSTEM DEVELOPMENT MODELS

PROBLEMS OF WATERFALL MODEL

Assumes the perfect specifications

Too prescriptive i.e. sequential and limited iterations

Late detection of errors

Exclusion of the end –user or client

Little guidance on project management

Aggravated for knowledge based systems due to incomplete and

changing specifications
The rigid sequential flow of the model is rarely encountered in real

life. Iteration can occur causing the sequence of steps to become

muddled.
 SYSTEM DEVELOPMENT MODELS

PROBLEMS OF WATERFALL MODEL

It is often difficult for the customer to provide a detailed

specification of what is required early in the process.

 Yet this model requires a definite specification as a necessary building block
for subsequent steps.
Much time can pass before any operational elements of the system
are available for customer evaluation.
 If a major error in implementation is made, it may not be uncovered until
much later.
 SYSTEM DEVELOPMENT MODELS

Prototyping Development Model

 Developed on the assumption that it is often difficult to know all of

your requirements at the beginning of a project.

 Typically, users know many of the objectives that they wish to

address with a system, but they do not know all the nuances of the
data.
 Nor do they know the details of the system features and capabilities.

 Prototyping Model allows for these conditions, and offers a

development approach that yields results without first requiring all

information up-front.
 SYSTEM DEVELOPMENT MODELS
Prototyping Development Model
 The developer builds a simplified version of the proposed system

and presents it to the customer for consideration as part of the

development process.
 The customer in turn provides feedback to the developer, who goes

back to refine the system requirements to incorporate the additional

information.
 Often, the prototype code is thrown away and entirely new

programs are developed once requirements are identified.

 SYSTEM DEVELOPMENT MODELS

Prototyping Development Model

 The approaches that may be followed:

 Creation of the major user interfaces without any substantive

coding in the background in order to give the users a “feel” for

what the system will look like,
 Development of an abbreviated version of the system that

performs a limited subset of functions

 Use of an existing system or system components to demonstrate

some functions that will be included in the developed system.

 SYSTEM DEVELOPMENT MODELS

Prototyping is comprised of the following steps:

 Requirements Definition/Collection

 Design

 Prototype Creation/Modification

 Assessment

 Prototype Refinement

 System Implementation
 SYSTEM DEVELOPMENT MODELS

BENEFITS OF PROTOTYPING
Shorter development time by accelerating some phases

More accurate user requirements are captured

Greater user participation and support

Active model that interfaces users’ experience

Working equivalent to paper design specifications

Enable early detection of any errors

Increase creativity allowing quicker user feedback that may lead to

better solutions
 SYSTEM DEVELOPMENT MODELS

BENEFITS OF PROTOTYPING
Facilitates rapid development of the system

User gets hands –on experience of the system before it becomes fixed

Facilitates communication between the user and the developer

Reduces training costs and time on the use of the system

Facilitates user awareness of the project progress and reduces user

frustrations
 SYSTEM DEVELOPMENT MODELS

Problems/Challenges of Prototype Model

 Prototypes can lead to false expectations.

 Can lead to poorly designed systems

 False expectations where the customer sees a working version of the

software unaware of possible lack of supporting structure

 Poor design which often the prototype can end up being thrown away

 Design can suffer due to layering approach

 Process is not visible and thus system is poorly structured

 Lack of documents, reports, milestones, reviews to monitor and the

control of progress
 Maintenance is more costly and difficult
 SYSTEM DEVELOPMENT MODELS

 LIMITATIONS TO SYSTEM DEVELOPMENTS

 Resource intensive – much time is spent gathering info, setting

specifications and documentation, installation, use of money and

putting the system into operation
 Inflexibility to changes – the approach is inflexible and inhibits

change requiring constant revisions so as to meet the requirements in

the event of errors, the sequence of life cycle are to be repeated
 Unsuitable to dynamic applications – where decision oriented

applications have to change due to requirements constantly changing

altering the defined models / procedures
 Rigidity in design – formal specifications of requirements inhibit

system builders from exploring and discovering the problem structure

 SYSTEM DEVELOPMENT MODELS

 LIMITATIONS TO SYSTEM DEVELOPMENTS

 Not maintainable - The user sees what appears to be a fully

working system (in actuality, it is a partially working model) and

believes that the prototype (a model) can be easily transformed
into a production system.
 Implementation problem - The developer often makes technical

compromises to build a "quick and dirty" model thus

compromises are propagated into the production system
 SYSTEM DEVELOPMENT MODELS

 LIMITATIONS TO SYSTEM DEVELOPMENTS

 Limited domain - Prototyping is applicable only to a limited

class of problems.
 In general, a prototype is valuable when heavy human-machine

interaction occurs, when complex output is to be produced or

when new or untested algorithms are to be applied.
 It is far less beneficial for large, batch-oriented processing or

embedded process control applications.

 SYSTEM DEVELOPMENT MODELS

SPIRAL DEVELOPMENT MODEL

Process is represented as a spiral rather than as a sequence of

activities with backtracking

Each loop in the spiral represents a phase in the process.

No fixed phases such as specification or design - loops in the spiral

are chosen depending on what is required.

SPIRAL DEVELOPMENT MODE
 SYSTEM DEVELOPMENT MODELS
SPIRAL DEVELOPMENT MODEL
The risks are explicitly assessed and resolved throughout the process:

 Progresses towards the final system

 Risk analysis based on the initial requirements

 User evaluation based on user reaction to the plan

 Go – no decision concerns risk assessment and user evaluation of the

increments
 Further planning based on the user comments; hence

 Initial gathering and project planning

 The system design / engineering

 System construction and testing

 Maintenance, requirements analysis and installations

 SYSTEM DEVELOPMENT MODELS

SPIRAL DEVELOPMENT MODEL

An effective design will meet general objectives which make the

system easier to build and maintain.

The design should meet specific objectives which should be phrased

in quantifiable and operational terms.

Design takes place in the context of constraints imposed by the user
 SYSTEM DEVELOPMENT MODELS

Spiral Model is made up of the following steps:

Project Objectives - Similar to the system conception phase of the

Waterfall Model
Objectives are determined, obstacles are identified and alternative

approaches are weighed

Risk Assessment - Possible alternatives are examined by the

developer, and associated

 Risks / problems are identified. Resolutions of the risks are

evaluated and weighed in the

 consideration of project continuation. Sometimes prototyping is

used to clarify needs.

 SYSTEM DEVELOPMENT MODELS

Spiral Model is made up of the following steps:

Engineering & Production - Detailed requirements are determined

and the software piece is developed.

Planning and Management - The customer is given an opportunity

to analyze the results of the version created in the Engineering step and
to offer feedback to the developer.
 SYSTEM DEVELOPMENT MODELS

 Problems/Challenges associated with the Spiral Model

 Due to the relative newness of the Spiral Model, it is difficult to
assess its strengths and weaknesses.
 However, the risk assessment component of the Spiral Model
provides both developers and customers with a measuring tool that
earlier Process Models do not have.
 The measurement of risk is a feature that occurs everyday in real-
life situations, but unfortunately) not as often in the system
development industry.
 The practical nature of this tool helps to make the Spiral Model a
more realistic Process Model than some of its predecessors.
End Lesson 6
Lesson 7
STRUCTURED APPROACHES TO
SYSTEMS DEVELOPMENT

Objectives
 Structured Methods Features
 Structured Analysis
 Structured Analysis Approaches
 Tools for Structured Analysis
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
 Originated from the observation that most Information Systems
development had gone wrong or had failed to meet the
requirements, goals or objectives, the condition coming from poor
system analysis
 There arose the need for the new methods of analysis and design
that would offer
 Greater formality of approach to bring system development to a
compact well functioning entity for example:
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
 More flexible design of the system
 Less scope for un ambiguity and understanding
 Specifications and finally into technical specifications
 Much more user involvement at all the stages off development
 Greater focus on identifying and satisfying business needs
 Ability to trace requirements through the initial analysis into the
business level
 Clarity of the stated requirements by the use of text and the
graphical representation
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
FEATURES OF STRUCTURED METHODS
Focus on the data structure

 Concentration on examining data requirements of the proposed

Information System; with reasons being Processing requirements

to have stable data for sound development process; and Bring
flexibility in the data structure eliminating constraints that may
hinder changes to match new requirements
Use of diagrams and structured English

 Information conveyed by the diagrams is easier for the people to

assimilate hence easy means of communication of the users and

the developers.
 Also DFD remove the ambiguity, are concise, precise and easy to

modify or complete
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
FEATURES OF STRUCTURED METHODS

Concentrate on business requirements

 Concerns separation of the logical and the physical aspects of the
analysis and design process done by the analysts and the
developers who focus on the business requirements and less on the
technical details of implementing a proposed Information System
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
ADVANTAGES
Delivering business benefits – from fulfilled requirements, goals

and objectives and the use of technology

Upgrades documentation – make the design suitable for

implementation in a number of environments

Complete and consistent documentation – greatly help in

maintaining and enhancing the system over time

Diversification – users can commission various developers to

separately do the analysis and produce designs

 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
ADVANTAGES
Concentrate on system data requirements – building a system

around a flexible data structure

Improved communication – increased chances of users getting the

system they really want from the developers

Reduce mistakes – thoroughness and cross-checking minimize

errors of omission in the analysis

 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
DISADVANTAGES
Long time wait by the users before actually getting concrete results

from the development

Time consuming on the explicit involvement of users at the various

stages that may require training

Restricted knowledge of the development to the designers /

developers who may not provide advice, training, consultancy and

support tools for use by users
Complexity of some CASE Tools that require computerized support

so as to be used in any system development process

 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT

STRUCTURED ANALYSIS
Structured analysis is a set of techniques and graphical tools that

allow the analyst to develop a new kind of system specifications that

are easily understandable by the user
Process modeling is a technique for organizing and documenting

the structure and the flow of data through a system process.

Also process modeling is the logic, policies and procedures to be

implemented by the system process

 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
 The traditional approach focuses on the following
 Cost benefit analysis

 Project management

 Feasibility study and analysis

 Hardware and Software selection

 Personnel consideration
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
 Structured analysis considers new goals and tools for analysis
where the goals specify
 Use of the graphics for the better communication with the user

 Differentiate between logical and physical systems

 Build logical system models to familiarize the user with system

characteristics
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
Structured analysis is basically a four-stage process carried out
during system analysis; and the phases include
1. Understand the current physical system
 Through fact-finding activities and recording of information about how the
current system operates.
 Need to construct a data flow model, processing sequence and
documentation requirements as described by the users of the system
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
Structured analysis is basically a four-stage process carried out
during system analysis; and the phases include
2. Describe the current logical system
 Show the logical functions carried out by the system without considering
how the current system is physically implemented i.e. state exactly what the
system is doing rather than how it is doing it

3. Define a required logical system

 State what the new system will do according to the requirements. Offer
alternatives of other logical systems for the new proposed system
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
Structured analysis is basically a four-stage process carried out
during system analysis; and the phases include
4. Describe the required physical system
 Specify in details exactly how the proposed system will work, with aid of
prototypes.
 Thus transform all the business requirements into a physical design for
implementation on specific Hardware and Software platforms
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
ATTRIBUTES OF STRUCTURED ANALYSIS
Graphics – use of diagrams and minimum text to present the

specifications in a conceptually easy to understand presentation of the

applications
Partition – processes are divided into activities and tasks for a clear

progression from general to specific in the system flow

Logical – the abstracted elements are specified in a precise, concise

and highly readable manner showing the workings of the system, save
its implementation
Thoroughness – calls for a rigorous study of the user for commitment

towards system analysis

Certainty – tasks are normally evaluated at analysis phase before

proceeding to other stages of SDLC

 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
TOOLS OF STRUCTURED ANALYSIS
Since the system flowcharts focus more on the physical than on the

logical implementation of the candidate system, structured tools are

being used for both logical and physical analysis
Structured analysis concerns building logical models to accentuate

the system characteristics and their inter-relationships before

implementation.
The structured analysis tools include:- Data flow diagrams DFD,

Data dictionary DD, Structured English, Decision tables and

Decision trees
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
DATA FLOW DIAGRAM (DFD)
DFD is a tool that expresses system’s requirements in a graphical

form by clarifying and identifying major transformations that will

become programs in the system design
DFD functionally decomposes the requirements specifications

down to the lowest level of details and describes what data flow
(logical model) rather than how data is processed (physical model)
i.e. independent of the hardware, software, data structures or file
organizations
DATA FLOW DIAGRAM (DFD)
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
EXAMPLE OF DATA FLOW DIAGRAM (DFD)
 STRUCTURED APPROACHES TO SYSTEMS
DEVELOPMENT
ADVANTAGES OF DD
Documentation – serves as a valuable reference in any organization

Improves communication - through established and consistent

definitions of various elements, terms and procedures

Common resource - stakeholders of system can compare, learn and

understand data descriptions

Integrity - cross reference of information maintain each data

element
Standardizing - an important feature necessary in building a

database
Helps simplify structure for meeting data requirements of a system
End Lesson 7
Lesson 8
SYSTEM DOCUMENTATION

Objectives
 Documents Produced
 Quality Control SWT
 Choosing SW and HW
 SYSTEM DOCUMENTATION

Items for documentation include:-

System Request – this is a written request that identifies

deficiencies in the current system besides requesting for change

Feasibility Report – this indicates the economic, legal, technical

and operational feasibility of the proposed project

Preliminary Investigation Report – this is a report to the

management clearly specifying the identified problems within the

system and what further action to be taken is also recommended
 SYSTEM DOCUMENTATION

Items for documentation include:-

System Requirements report – this specifies the entire end –user

and management requirements, all the alternatives plans, their costs

and the recommendations to the management
System Design Specification – it contains the designs for the

inputs, outputs, program files and procedures

User Manual – it guides the user in the implementation and

installation of the information system

Maintenance Report – a record of the maintenance tasks done
 SYSTEM DOCUMENTATION

SOFTWARE DOCUMENTATION
The typical items included in the software documentation are:
Introduction – shows the organization’s principles, abstracts for

other sections and notation guide

Computer characteristics – a general description with particular

attention to key attributes and summarized features

Hardware interfaces – a concise description of information

received or transmitted by the computer

Software functions – shows what the software must do to meet

requirements, in various situations and in response to various events

Timing constraints – how often and how fast each function must

be performed
 SYSTEM DOCUMENTATION

SOFTWARE DOCUMENTATION
The typical items included in the software documentation are:
Accuracy constraints – how close output values must be ideal to

expected values for them to be acceptable

Response to undesired events – what the software must do in

events e.g. sensor goes down, invalid data etc

Program sub-sets – what the program should do it if it cannot do

everything
Fundamental assumptions – the characteristics of the program

that will stay the same, no matter what changes are made
Software Code – this refers to the code written for the information

system
 SYSTEM DOCUMENTATION

SOFTWARE DOCUMENTATION
The typical items included in the software documentation are:
Test Report – this should contain test details e.g. sample test data

and results etc

Tutorials - a brief demonstration and exercise to introduce the user

to the working of the software product

Changes – the type of changes that have been made or are expected

Sources – annotated list of documentation and personnel, indicating

the types of questions each can answer

Glossary – most documentation is fraught with acronyms and

technical terms

 SYSTEM DOCUMENTATION

QUALITY CONTROL - STRUCTURED WALKTHROUGHS

Structured walkthrough is the review of the products at the end of

each stage in the development of a system by a group of relevant and

competent persons.
The prime objective of SWT is to identify problems and initiate the

necessary corrective measures / actions

 SYSTEM DOCUMENTATION

ROLES IN A WALKTHROUGH
Presenter – is a person who has done all the work and presents the

relevant documentation for the quality assurance

Chairperson – is the person responsible for circulating

documentation prior to the meeting, choosing the time and the

location and chairing the meeting
Secretary – person responsible for the documenting the problems

raised and then reading them back at the end of the meeting so that
priorities can be assigned and the follow-up action agreed
Reviewer – is the person from the same project as the presenter
 SYSTEM DOCUMENTATION
STAGES OF SWT
Preparation – presenter prepares documentation on the product to be

reviewed and passes the documentation to the chairperson who then

distributes the documentation and notifies the reviewers of the time and
location of the walkthrough
Meeting – is a short time meeting where the presenter walks the reviewer

through the product.

The purpose is to ensure that the products meets the requirements and

conforms to the appropriate standards. Defects are identified, and then

spread info, knowledge, ideas and new approaches
Follow-up Actions – there is acceptance and sign off the product. Minor

revisions are recommended without need for further review. Recommend

major revisions and schedule another walkthrough to review the revised
product
 SYSTEM DOCUMENTATION

Problems Associated with SWT

Inadequate preparation by the reviewers

To much time spent discussing solutions rather than identifying

defects
Author being defensive about his work

Walkthrough rambling on for too long

Tendency of people to forget important points and argue over the

inconsequential parts
Tendency to fix blame on others attempting to discredit their work
 SYSTEM DOCUMENTATION

Solution to problems of SWT

Enforcing a time limit

Ensuring walkthrough standards are adhered to

Careful selection of the team members

Reminding the attendees the importance of the preparation before

the meeting
Avail a checklist of specific topics for review to keep the team on

track
 SYSTEM DOCUMENTATION

CHOOSING SOFTWARE AND HARDWARE

Even though many analysts and programmers can design and build a
system from scratch, it is advisable economically to buy rather than
to build the software.
 SYSTEM DOCUMENTATION

CHOOSING SOFTWARE AND HARDWARE

Commercially available software has the following advantages:
Cheaper – cost of developing is distributed among many purchasers

rather than by on organization

Already debugged – most of the bugs have been found and fixed in

earlier applications
Available – software products can be obtained sooner from the market

Shorter time - user personnel can bring up the new system in less time

Easily applied - users can try out the product without investing a great

deal of money

 SYSTEM DOCUMENTATION

Disadvantages
Rarely meets user needs – users may have to adapt their procedures to

the structure of the software

Can be expensive – analyst may have to modify the software to suit

the requirements
Incompatible – product may not be compatible with the existing

software applications
User interface – different user interface may make it difficult for the

users to the software

Rigid – software may not be easily modified with changing needs of

users in the future

Lack of specialist – there can be missing expert on board when

application goes on to use

 SYSTEM DOCUMENTATION

 SOFTWARE SELECTION CRITERIA

 Consider software package whether it is the one needed and is it to be
modified
 Stability of the vendor to assist in case of problems
 Prompt response and reliable support of the vendor
 Provision by the vendor of enhancements and upgrades to the software
 Consider the modification of the supplied programs by the organization
 Consider the trial period after which the software can be returned for a full
refund
 Consider other installations which have used the software
 Consider the flexibility of the software along with the changing business
environment
 Consider the software being user friendly especially a compatible user
interface
 SYSTEM DOCUMENTATION

HARDWARE SELECTION CRITERIA

Consider the stability of the vendor

Existence of a trial period

Satisfaction of the users

Flexibility and the user friendliness

Machine compatibility allowing for upgrades

 SYSTEM DOCUMENTATION

HARDWARE SELECTION CRITERIA

Consider the stability of the vendor

Existence of a trial period

Satisfaction of the users

Flexibility and the user friendliness

Machine compatibility allowing for upgrades

End Lesson 8
Lesson 9
SYSTEM IMPLEMENTATION

Objectives
 Implementation Strategies
 System Evaluation
 SYSTEM IMPLEMENTATION

System implementation is the handing over the system

from the developers to the users or clients who will put the
system into its intentioned use
System testing - involves the completed software

programs being passed to the designer or programmer who

examines them and approves their interfaces with respect
to the rest of the system within the organization
 SYSTEM IMPLEMENTATION

 Unit / program testing – is a test whereby each program

module is tested
 System testing – is the test that ensures that programs
written in isolation work properly when they are
integrated into the operation of the total system
 User acceptance testing (UAT) – is the testing of the
system by the user department, after the system has
passed the systems test
 SYSTEM IMPLEMENTATION

IMPLEMTATION STRATEGIES
Also known as the system conversion or changeover methods; that
concerns the transformation from the old to new system with
minimum visible differences between the two systems

1. Direct changeover
The old system is stopped and the new system replaces it

immediately i.e. it is a quick transition that can be used when there

can be no disruptions on the organization operations
 SYSTEM IMPLEMENTATION

IMPLEMTATION STRATEGIES
2. Phased conversion
If the new system has several components, they can be introduced

one at a time
The staff can become accustomed to one change before facing the

next e.g. introducing modern communication – internet, email, video

conferencing, electronic ordering etc
 SYSTEM IMPLEMENTATION

IMPLEMTATION STRATEGIES
3. Pilot Conversion
 If the organization has several branches or departments where the

new system will be implemented; the organization may decide to try

the new system in one location first
Any faults and problems will be limited to that one location and

will not cripple the whole organization. Compatibility is the major

issue considered among the various location
 SYSTEM IMPLEMENTATION

IMPLEMTATION STRATEGIES
4. Parallel conversion
Involves keeping the old system running while the new system is

installed and starts to operate

This is possible if the old and the new systems are completely

independent and has the following benefits. One can directly

compare the effectiveness and efficiency of the new and old systems
If the new system fails, the old system will serve as a back up
 SYSTEM IMPLEMENTATION

SYSTEM EVALUATION
Evaluation of the systems to produce information about the system

at various stages of development and as a feedback to improve the

product under development
Post implementation evaluation is performed before and after

installation of the new system

 SYSTEM IMPLEMENTATION

SYSTEM EVALUATION

Purpose of the evaluation

To verify that the installed system meets user requirements

To provide feedback to the development personnel

To justify the adoption, continuation or termination of the installed

system
To clarify and set priorities for the needed modification

To transfer the responsibility for the system from the development

team to the users

 SYSTEM IMPLEMENTATION

 Areas to be evaluated
 Accuracy of the information
 Timelines and currency of the information
 User satisfaction
 Attitudes towards the system
 Internal controls of the system
 Project schedule compliance
 The quality of the programs
 The net operating costs
 Savings of the system
 Systems impact on the user and their jobs
 Quality and completeness of the system documentation
 SYSTEM IMPLEMENTATION

 BENEFITS OF EVALUATION
 Improvement of the systems development practice decisions to

adopt, modify or discard the information system

 Evaluation and the training of the personnel responsible for

system development
 Improvement in the effectiveness and the productivity of the

design
 Realization of the cost savings by modifying the system

through evaluation rather than after a real operation

End Lesson 9