Transcript Document

What Is System Analysis
• systems analysis: The analysis of the role of a
proposed system and the identification of a set of
requirements that the system should meet, and
thus the starting point for system design.
• The systems analysts are responsible for
identifying a set of requirements (i.e. systems
analysis) and producing a design. The design is
then passed to the programmers, who are
responsible for actual implementation of the
system.
Structured Systems Analysis and Design
Methodology (SSAD)
• structured systems analysis A specific technique
for systems analysis that covers all activities from
initial understanding of the problem through to
specification and high-level design of the software
system.
• is a methodology (Def. a system of ways of doing
things especially regular and orderly procedures),
used in the analysis and design stages of systems
development.
Structured Systems Analysis and Design
Methodology (SSAD)
• The success of SSADM may lie in the fact that it
does not rely on a single technique. Each of the
three system models provides a different
viewpoint of the same system, each of which are
required to form a complete model of the system.
• SSADM revolves around the use of three key
techniques, namely
– Logical Data Modeling,
– Data Flow Modeling
– Entity/Event Modeling.
Structured System Analysis
• Logical Data Modeling; This is the process of
identifying, modeling and documenting the data
requirements of a business information system. A
Logical Data Model consists of a Logical Data
Structure (LDS - The SSADM terminology for an
Entity-Relationship Model) and the associated
documentation. LDS s represent Entities (things
about which a business needs to record
information) and Relationships (necessary
associations between entities).
Structured System Analysis
• Data Flow Modeling; This is the process of
identifying, modeling and documenting how data
flows around a business information system
•
A Data Flow Model consists of a set of integrated
Data Flow Diagrams supported by appropriate
documentation. DFDs represent processes
(activities which transform data from one form to
another), data stores (holding areas for data),
external entities (things which send data into a
system or receive data from a system and finally
data flows (routes by which data can flow)
Structured System Analysis
• Entity Event Modeling; This is the
process of identifying, modeling and
documenting the business events which
affect each entity and the sequence in
which these events occur. An
Entity/Event Model consists of a set of
Entity Life Histories (one for each
entity) and appropriate supporting
documentation.
Data Modeling
• Logical Versus Physical Database
Modeling
After all business requirements have been gathered for a
proposed database, they must be modeled. Models are
created to visually represent the proposed database so that
business requirements can easily be associated with database
objects to ensure that all requirements have been completely
and accurately gathered.
Different types of diagrams are typically produced to illustrate
the business processes, rules, entities, and organizational
units that have been identified. These diagrams often include
entity relationship diagrams, process flow diagrams, and
server model diagrams.
Two types of data modeling are as follows:
• Logical modeling
• Physical modeling
Data Modeling
• Logical modeling deals with gathering business
requirements and converting those requirements into a
model. The logical model revolves around the needs of
the business, not the database, although the needs of
the business are used to establish the needs of the
database.
• Logical modeling involves gathering information about
business processes, business entities (categories of
data), and organizational units.
• After this information is gathered, diagrams and reports
are produced including entity relationship diagrams,
business process diagrams, and eventually process flow
diagrams.
Data Modeling
• Logical modeling(cont)
• The diagrams produced should show the processes and data
that exists, as well as the relationships between business
processes and data. Logical modeling should accurately render
a visual representation of the activities and data relevant to a
particular business.
• Typical deliverables of logical modeling include
– Entity relationship diagrams
– Business process diagrams (hierarchical view of processes)
– User feedback documentation
• Note
Logical modeling affects not only the direction of database
design, but also indirectly affects the performance and
administration of an implemented database. When time is
invested performing logical modeling, more options become
available for planning the design of the physical database.
Data Modeling
• Physical modeling involves the actual design of a
database according to the requirements that were
established during logical modeling
• Logical modeling mainly involves gathering the
requirements of the business, with the latter part of
logical modeling directed toward the goals and
requirements of the database. Physical modeling deals
with the conversion of the logical, or business model,
into a relational database model.
• When physical modeling occurs, objects are being
defined at the schema level. A schema is a group of
related objects in a database. A database design effort
is normally associated with one schema.
• During physical modeling, objects such as tables and
columns are created based on entities and attributes
that were defined during logical modeling.
• Constraints are also defined, including primary keys,
foreign keys, other unique keys, and check constraints.
Data Modeling
• Physical modeling(cont)
• The implementation of the physical model is dependent
on the hardware and software being used by the
company.
• Some database software might only be available for
Windows NT systems, whereas other software products
such as Oracle are available on a wider range of
operating system platforms, such as UNIX.
Typical deliverables of physical modeling include the
following:
– Server model diagrams
The server model diagram shows tables, columns, and
relationships within a database.
– User feedback documentation
– Database design documentation
Hard vs Soft Systems Analysis
Hard systems
• – Easy to define
• – concerned with how we deal with the problem(s)
Soft system
• – Not well defined
• – Concerned with what shall we do
• – Organizations and businesses are typically soft
systems
Hard Systems Analysis
• Hard systems (HS) involves simulations, often using computers and
the techniques used in operations research. Hard systems look at the
“How?” meaning, how to best achieve and test the selected option of
development and analysis
• HS have an explicit objective governed by fixed rules such as those
encountered in decision making.
• Operational Research is a hard, well defined system. Examples of
areas that apply hard systems methodology are:
• Project Management
• Forecasting
• Simulation
• Mathematical Programming
• Decision Theory
• Another characteristic of hard systems that it is:
• Stochastic – Statistically based on probability.
• Deterministic – fixed inputs and known outputs
Soft System Analysis
• Soft systems methodologies (SSM) are used to tackle systems that
cannot easily be quantified, especially those involving people
interacting with each other or with "systems".
• Useful for understanding motivations, viewpoints, and interactions but,
naturally, it doesn't give quantified answers.
• Soft systems looks at the “What?” of the system; What to do to achieve
an improvement, Usually analysis before application or
implementation
• SSM Considers the following:
• Systems that could be envisaged
• Human activity
• Clarification of the problem
• Improve the understanding
• Based on Ideas:
• Examine
• Learn about and Study
• Understand
• Select and Focus
Hard And Soft System Analysis
In summary, hard systems analysis addresses those parts of
enterprise that have a tangible form. These techniques
address those problems:
• Identify cost/savings
• Improve methods
• Develop User Requirements
whereas soft system analysis attempts to:
• Understanding complexity
• Promote learning
• Identifying weakness
• Understanding relationships
Soft Systems Methodology
• Soft Systems Methodology (SSM) was developed by
Peter Checkland in the late 60’s at the University of
Lancaster in the UK.
• The real world is usually complex and messy. Many
different factors may contribute to an issue, and there may
be many different perspectives to consider while resolving
it. This means that it's often difficult to understand the real
problem or find the root cause.
• With so much confusion often surrounding problems,
determining an appropriate solution can sometimes seem
almost impossible.
• To deal with issues like these, you need a problem-solving
approach that first lets you clearly see what's happening and then helps you think about how the situation could be
improved.
• Soft Systems Methodology (SSM) is just such an
Soft Systems Methodology
• Although SSM develops models, the models
are not supposed to represent the “real
world”, but by using systems rules and
principles allow you to structure your thinking
about the real world. The models are neither
descriptive or normative, though they may
carry elements of both.
• One of the interesting things about SSM is
that it constrains your thinking in order for you
to expand your thinking.
Key Features of SSM
• The primary focus of SSM is on THE
PEOPLE INVOLVED WITH THE PROBLEM
and the secondary focus is on THE
PROBLEM. It is a
User-Centered Design Approach.
• SSM supports analysis of the problem from
different perspectives.
• Technical problems are dynamic over time.
• The idea is to keep the project vague and
wide ranging for as long as possible.
Seven Stages Of SSM
1. Examination of the problem situation
the researcher is immersed in the problem situation
2. Problem situation expressed - Analysis of the ingredients (using a
rich picture method)
the problem systems and their immediate context are defined
3. Relevant systems and Root definitions are defined
coming to a root definition of significant facets of the system of interest
4. Conceptualization and modeling
the conceptual models of the systems, intended as improvements, are
developed
5. Comparison of models
the conceptual models of the system are compared to reality
6. Debate about change - definition and selection of options
feasible and desirable changes are identified
7. Design of action program
the actions required to improve the situation are outlined
SSM – overview (seven stage
model)
situation
1 considered
problematic
2
problem
situation
expressed
7
action to
improve the
problem situation
6
changes:
systemically desirable,
culturally feasible
comparison of
models and
real world
5
real world
3
root definition
of relevant systems
systems thinking
about real world
conceptual models
of systems described
in root definitions 4
source: Checkland: Systems Thinking, Systems Practice
Stage 1 of 7
• Stage 1: The problem situation unstructured
So first we decide what it is we are actually
exploring. At this stage we don’t define the
problem but assess the general area that
interests us.
• Find about the problem situation,
• Who are the key players? What is their
perception
of the situation?
• What processes are going on and how?
• What the organizational structures are?
Stage 2
• Stage 2
In Stage Two the issue is “expressed” in some way. Checkland
calls this a rich picture
for two reasons.
Firstly the situation needs to be expressed in all its richness.
Checkland provides some guidelines as to what should be
included. These are
• Structures
• Processes
• Climate
• People
• Issues expressed by people
• Conflicts
Secondly, Checkland suggests that the best way of doing this is in
a picture form.
Stage 2 (cont.): Tools used to gather
information
about the problem situation
Workplace Observations
identify tasks
performed
produce logs
“day in the life of”
descriptions
video recording
Workshops and Discussions
future workshops
review workshops
conflict resolution
workshops
mock ups and
simulations
Interviewing
unstructured interviews, informal interviews
semi-structured interviews, highly structured
interviews
audio recording, critical incidents
Stage 2
All the information collected in stage 1 and
stage 2 is
put in pictorial format called Rich Pictures.
Rich pictures should show
• Power structure within the system
• Power hierarchy within the system
• Reporting system within the system
• Pattern of communication
Stage 2
Graphical representation of the organization or work area
• Self explanatory and easy to understand
• A subjective process: there is no “correct” picture
• “Hard” facts:
e.g. activities, departmental boundaries, physical and
geographical layout, product types, resources,
• “Soft” facts:
e.g. concerns, conflicts, socio-organizational roles, political
issues, relationships, employee needs,
• Rich pictures help:
- to identify what is really important in the situation
- people understand their role in the organization
- to define aspects of the organization to be addressed by
the information system
Stage 2
Stage 2
• Rich Pictures
• – People involved
• – Problem areas
• – Controlling bodies
• – And sources of conflicts
• The rich pictures can also include detail about the
system environment such as human activities, like
processes, cross-organizational boundaries.
Stage 2 (cont.): Warnings: pitfalls to avoid
during
early stages of SSM
• Don't narrow the scope of investigation down
too early
• Assemble richest picture without imposing a
particular
structure and solution on the problem situation
• People have difficulty to interpret the world in
a loose way and
often show the over-urgent desire for action
• Should realize that there will be many
possible versions of the system
Stage 3 : Selection of Relevant Systems and
Root Definitions
“‘The root definition is a concise, tightly constructed
description of a human activity system which states what
the system is’ (Checkland 1981)”
• A relevant system is one which is thought to be helpful in
learning about the situation - for any situation there may
(will) be several possible relevant systems
• A Root Definition is the name of a relevant system.
• The core of a relevant system is the transformation it
performs
Input
T
Output
Stage3 Root definitions of the relevant
systems are defined
• Who is doing what for whom?
• Whom are they answerable to?
• What assumptions are being made?
• What environment is it happening?
• One root definition might be ‘to provide a service
which gives the highest possible safety standards
whilst balancing the need for customer care with
annual spending’
Stage3 Root definitions of the relevant
systems are defined
Transformation
• The input must be transformed by the process and
the output must be a product of the transformation
– e.g. for a public library
unread books
books read
need for knowledge
need met
unspent budget
spent budget
but not
repository of knowledge
educated public
Stage3 Root definitions of the relevant
systems are defined
CATWOE (1)
C Customer(s) beneficiary(s)/victim(s) of the system
A Actor(s) those who do T
T Transformation of input to output
W Weltanschauung the specific “world view” that makes T
meaningful (assumptions)
O Owner(s) those who could stop (or change the nature of) T
E Environment constraints on the system that are outside its
scope
• How do you know if your Root Definition is “complete”?
• CATWOE is a useful mnemonic for structuring or
manufacturing root definitions
Stage3 Root definitions of the relevant
systems are defined
Root Definitions
• Short textual statements which define the important
elements of the relevant system being modeled rather like mission statements
a system to do X by (means of) Y in order to do Z
what the system does - X
how it does it - Y
why it’s being done - Z
Stage3 Root definitions of the relevant
systems are defined
• Root definition examples
A university owned and operated system to award degrees and
diplomas to suitably qualified candidates (X), by means of suitable
assessment (Y), (in conformance with national standards), in order
to demonstrate the capabilities of candidates to potential
employers (Z).
Express the RD as "a system to do X, by Y, in order to
achieve Z"
A university owned and operated system to implement a quality
service (X), by devising and operating procedures to delight its
customers and control its suppliers (Y), in order to improve its
educational products (Z).
Stage3 Root definitions of the relevant
systems are defined
C candidate students
A university staff
T candidate students transformed into degree
holders
W the belief that awarding degrees and
diplomas is a good way of demonstrating the
qualities of candidates to potential employers
O the University governing body
E national educational
Stag4 Conceptualization and
modeling
Conceptual Model
• Is a human activity model which
rigorously matches the root definition
• The activities can be derived from the
verbs in the root definition
• The model shows the dependencies
between these activities
activity models - symbols
verb + noun
phrase
A
B
activity - ‘do something’
logical dependency arrow - activity A must
come before B, or if activity A is done badly
- so will B
boundary
study BIT
cook dinner
example use
eat
dinner
take BIT
examination
Stag4 Conceptualization and
modeling
Guidelines for building Conceptual Model
• Select activities from the root definition which
would have to take place, in order for the
described system to function properly
• Express each of these functions as a single
phrase using a single verb
• Incorporate the activities into a conceptual
model, showing where each activity is
dependent on another
• Incorporate the three E’s (see later)
Stag4 Conceptualization and
modeling
• E1 - efficacy (does the system work, is the
transformation effected)?
• E2 - efficiency (the relationship between the
output achieved and the resources
consumed to achieve it)
• E3 - effectiveness (is the longer term goal
(Z) achieved)
Stage 4 (cont.): Evaluation / monitoring:
example
(university)
• E1 (efficacy) - are degrees and diplomas awarded?
• E2 (efficiency) - how many degrees and diplomas, of what
standard, are awarded for the resource consumed?
• E3 (effectiveness) - do employers find the degrees and
diplomas a useful way of assessing the qualities of
potential employees?
activity model - example
enrol students
educate
students
award
degrees + diplomas
to students reaching
acceptable levels
design
education
programmes
allot
resources
appreciate
national
standards
design
and carry out
assessment
A university owned and operated system to award degrees and
diplomas to suitably qualified candidates (X), by means of
suitable assessment (Y), (in conformance with national
standards), in order to demonstrate the capabilities of
candidates to potential employers (Z).
the complete conceptual model From Stag 1 to 4
•
•
•
•
root definition
CATWOE
activity model
measures of performance
The complete conceptual model From Stag 1 to 4
example
enroll students
design
education
programmes
educate
students
allot
resources
award
degrees + diplomas
to students reaching
acceptable levels
design
and carry out
assessment
A university owned and operated system to award
degrees and diplomas to suitably qualified candidates (X),
by means of suitable assessment (Y), (in conformance with
national standards), in order to demonstrate the
capabilities of candidates to potential employers (Z).
appreciate
national
standards
W
monitor for
E1, E2, E3
•
•
•
C
A
T
take control
action
O
E
candidate students
university staff
candidate students
degree holders and diplomates
the belief that awarding degrees and
diplomas is a good way of demonstrating
the qualities of candidates to potential
employers
the University governing body
national educational and assessment
standards
E1 (efficacy) - are degrees and diplomas awarded?
E2 (efficiency) - how many degrees and diplomas, of what standard, are awarded for the
resource consumed?
E3 (effectiveness) - do employers find the degrees and diplomas a useful way of assessing the
qualities of potential employees?
Stage 5: Comparison with real
world
• The activities in the conceptual model
are now compared with what happens
in the real world. For each activity, the
following questions are asked:
• Is this activity carried out in the real
world?
• How is it done?
• How is performance measured?
• Is the activity carried out effectively?
Stage 6 (cont.): Guidelines for identifying
feasible
and desirable changes
• Take the possibilities for changing the situation generated in
stage 5
• For each proposed change write down as clearly as possible
The reason for change
The nature of the change
The means of bringing about the change
• Asses the political feasibility by considering
• From whose point of view the expected outcome will be positive
• The individuals likely to oppose the change and why they
oppose it
• The relative power of the individuals or groups for and against
the
change
• Asses the feasibility of the proposed changes by examining
• Cost implications of implementation, relative to the other options
Stage 7: Recommended Actions to Improve the
Situation
The purpose of this stage is to recommend changes
and tactics for implementation of those changes
Guidelines
• From the list of options from stage 6, select the one
which is expected to have the greatest positive effect
• Be clear as to whose point of view the ‘positive effect
is from’
• Make notes about how likely the opposition to
changes should be dealt with
• Present the findings to the client in the form of report
Rules for SSM
Tactical Rules
1. Each stage , 2 - 6, has a defined output.
– Stage 2 - Rich pictures, Relevant Systems
– Stage 3 - Root Definitions (CATWOE)
– Stage 4 - Conceptual Models built from Root Definitions
– Stage 5 - Agenda for possible changes derived from comparisons
– Stage 6 - Agreement on desirable and feasible change
2. Conceptual Models should be derived from Root Definitions and
from nothing else
3. Conceptual Models should be checked against Root Definitions
4. Conceptual Models are not descriptions of systems to be engineered
5. Don't look for systems in the problem situation - the systems are
created as (conceptual) tools for learning