Sad Notes

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.
 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.
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.
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.

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.
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.

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

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.

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.
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.

 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

 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
 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

 MANAGERIAL LEVEL
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

 OPERATIONAL LEVEL
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
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.

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

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

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
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
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

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

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
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
 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.
 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 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 TOOLS
The analyst begins by creating a model / representation of reality
i.e. facts, relationships, procedures, processes of the system.

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
 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
 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
 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
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

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

 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

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
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

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
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

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
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

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
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.

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.
 Example: draw a network and find the critical path for the
following project
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

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

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
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 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
 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 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

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.
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.
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
.
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
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


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

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

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


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
 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.
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.
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.
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.
 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.


 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.

Prototyping is comprised of the following steps:

 Requirements Definition/Collection
 Design
 Prototype Creation/Modification
 Assessment
 Prototype Refinement
 System Implementation
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
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
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
 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


 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

 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.

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
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


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
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.

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.
 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:
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
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
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
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

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

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

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

DEVELOPMENT
 The traditional approach focuses on the following
 Cost benefit analysis
 Project management
 Feasibility study and analysis
 Hardware and Software selection
 Personnel consideration
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
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
DEVELOPMENT
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
DEVELOPMENT
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
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

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
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)
DEVELOPMENT
EXAMPLE OF DATA FLOW DIAGRAM (DFD)
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
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
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
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
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
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

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

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
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
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
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
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.
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

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

 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
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

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 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
 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
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
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
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
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 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 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

 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
 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

Sad Notes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sad Notes

Uploaded by

Copyright:

Available Formats

SYSTEMS ANALYSIS AND

 A system is an ordered grouping of independent components

 Organizations are complex systems that consist of inter-related

 The systems theory is concerned with tendency towards the

Systems concepts has the following implications:

Interrelationships and interdependences exist among the

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

 All Systems have inputs, processes, and outputs.

 Communication - Also feed-forward and feedback which are

 Organization – implies structure and order of arrangement of the

 Integration – concerned with how parts of a system work

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

actions, objects etc

alphabetical, numeric or special symbols

symbols for the purpose of converting them into data structures

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

human personnel, facilities and equipment.

purposeful intelligence and can be used in decision making

finished products in the sense that an IS processes data into

indeed gain value through credibility added by its use.

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

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

 Automating operation has negative impact such as:

 Decreased morale of personnel who were not consulted about the

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

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

operational structure in an organizational context.

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

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

management, especially in making unstructured decisions

implementation and control, resource allocation and

established by data processing systems-produces management

 Transaction Processing System (TPS) - is applications that

 System owners - sponsors and advocates responsible for funding

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

all potential users are permitted access.

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

the database grows.

Weaknesses of Traditional file approach

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

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

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

Advantages of Database approach

there is reduced replication on data.

data stored. This is an aspect of data integrity.

passwords, and assignment of user rights and their subsequent

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

Advantages of Database approach

database is designed around the organization rather than specific

independence and consequently database adaptability, there are

Advantages of Database approach

encourages management of data as an organization resource thus

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

Disadvantages of database approach

entire organization is usually too complex.

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

development is very complex.

organization can be great since its operations may get totally

Disadvantages of database approach

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

new DBMS are quite high.

 Application specific files approach- otherwise know as the

departments/applications. For example, Accounting department