Comparison Of Methodologies

Chapter 13

Comparison of
Methodologies

. – p.41/192

Picking a Methodology
You’ve got a team of 10-12 developers eagerly awaiting
your instructions.
Which methodology do you pick?
Usually one of the following things is done
Choice dictated by the methodologies used
previously by the developer’s boss
Using a new “hyped” methodology
“Heard from a friend of my brother’s wife that it’s
good.”
There was this lecturer at the College. . .
Comparing methodologies is like comparing apples to
oranges

. – p.42/192

Comparing Apples to Oranges
Has been done before (using a Nicolet 740 FTIR
spectrometer)
In Annals of improbable research (Scott A. Sandford)

Result: the two are very similar

. – p.43/192

Comparing Apples to Oranges(2)
Other people might have different opinions
Biologist points to taxonomy, describing similarities and
differences
Nutrition expert has still another opinion...
Observation: depending on who you ask, you get
different answers

. – p.44/192

Comparing Methodologies
Same with methodologies:
Computer scientist: tries to develop general
(theoretical) framework for comparing methodologies
Developer: tries to judge situation from prior
experiences and case studies
Senior management: tries to ﬁnd out, if methodology
will give certain quality assurances
Vendor: tries to sell own product (so you have to
read between the lines)

. – p.45/192

Comparing Methodologies(2)
So, how can we compare methodologies?
1. Describe “ideal” methodology, then compare to other
methodologies
Who determines what’s ideal?
If we ﬁnd ideal methodology, why use other
methodologies?
2. Construct general comparison tool by selecting
appropriate features
3. Develop a contingency framework to map
appropriate methodology to a particular environment
4. Develop a common frame of reference for viewing
different methodologies (provides a
“meta-language”)

. – p.46/192

Comparing Methodologies(2)
We are going to look at:
Theoretical model for comparison (Song and
Osterweil) (2.)
Checklists (3.)/Frameworks (4.)
Capability Maturity Model (CMM levels)
We are not going to look at:
Brochures of vendors

. – p.47/192

Theoretical Model
Song and Osterweil criticize that previous comparison
methods have been very unscientific
Analysis and comparisons are activities common to
many scientific fields
E.g. comparing animals in biology in a systematic and
objective way:
Comparison of organs and inter-organ relations
Usually organs (e.g. eyes) are classified by their
functions (e.g. vision)
Using this classification, organs having the same or
similar functions can be identified and compared
One compares structures (e.g. shape) and relations
to other organs (e.g. brain)
. – p.48/192

Theoretical Model(2)
Comparison of methodologies should be done similarly:
Comparisons of components and inter-component
relations
Components should be classiﬁed by their functions
(what problems they address)
Components should then be characterized by their
structures
Problem: methodologies and their components are
often not rigorously deﬁned
Methodologies and their components themselves need
to be modeled

. – p.49/192

Overview
Modeling
Methodology 1 Formalism Methodology 2

Build Base Build
Process Model Framework Process Model

Process Model Process Model

Classify
Components

Classification

Develop Select Develop
Process Code Comparison Topics Process Code

Topics

Process Code Process Code
Make
Comparison
Topics Topics
Difference

Summarize
Differences

Summary

. – p.50/192

Step 1: Build Process Model
Develop a model, a more formalized description, of
each of the two methodologies
After doing so, methodology can hopefully be
decomposed into components
Problem: many components (e.g. guidelines,
rules-of-thumb) lack precise semantics
Model must be at higher abstraction level, yet be
compact and clear
A number of Software Process Modeling Formalisms
(SPMF) have been developed for this

. – p.51/192

Build Process Model(2)
SPM by Williams is a typical SPMF
Development process is described as a set of activities:
SPM = {activity}
An activity is described by a set of preconditions, an
action, a set of postconditions, and a set of messages:
activity = {{precond.}, action, {postcond.}, {msg}}
Activities may be composed of other activities and may
be performed in parallel
Messages provide a means of communication and
synchronization among various activities

. – p.52/192

Step 2: Classify Components
Having identiﬁed components, they are now classiﬁed
This is done within a comparison framework, identifying
components that address similar issues
Typical issues are
How is problem modeled?
How is solution modeled?
How is design documented?

. – p.53/192

Describing Comparison Issues
Concept:
Understanding problems of IS development
General principles of coping with these problems
Concrete strategies that guide development
Artifact:
A description involved in the development process
(e.g. code, diagrams)

. – p.54/192

Describing Comparison Issues(2)
Representation:
Means for representing artifacts (e.g. document
templates, design/modeling languages)
Action:
Physical and/or mental behaviors during
development
May create or modify an artifact

. – p.55/192

Step 3: Select Comparison Topics
Topics should be selected based upon goals of a
speciﬁc comparison
Two general criteria can always be used:
Components should be comparable
Comparison between them should help in showing
key differences

. – p.56/192

Select Comparison Topics(2)
Classiﬁcation may illustrate that two concepts address
similar issues
If so, one can select these two concepts for comparison
and trace
artifacts supporting the concepts
representations representing the artifacts
actions creating or modifying the artifacts
And eventually ﬁnd the artifacts, representations, and
actions that could be compared

. – p.57/192

Step 4a: Develop Process Code
Process model developed in step 1 may be too abstract
We have to identify detailed differences between
compared components
This more detailed modeling is called process code (to
distinguish it from process model)
This step is optional

. – p.58/192

Step 4b: Make Comparison
Typical criteria for comparing process code/model
(again this depends on goal of comparison)
Inter-component dependency
Degree of human involvement
Development procedure/order
Scope of issues that methodology addresses

. – p.59/192

Step 5: Summarize
Aims at providing readers with an overview and a
conclusion
Should be organized around the comparison topics
Should help indicate the main differences between
components

. – p.60/192

Summary of Theoretical Model
Tries to help compare methodologies more
systematically and objectively
Has limitations
It is almost impossible to capture all details of a
methodology in a formal, rigorous model
Modeling a methodology is a non-trivial task (ranging
from hours to weeks)
Conclusion: is probably not going to be used by
practitioners, but helps understand ﬁndings of scientists

. – p.61/192

Checklists/Frameworks
Lots of checklists for choosing a methodology exist
Contain many questions of the following or similar form
How big is project? (small/medium/large)
How much experience does project manager have
(little/medium/much)
What tool support is expected (no/partly/full)
etc.
After evaluating answers according to a certain
scheme, an answer is delivered

. – p.62/192

Checklists(2)
This approach has many drawbacks:
Methodologies (and their context) are much too
complicated to be forced into simple recipes
Answer materializes in a “magic” way, no knowledge
about the rationale of the checklist creator

. – p.63/192

Frameworks
Frameworks are a more systematic way for evaluating
methodologies
Potential user (of a methodology) does not just check
boxes and waits for answer
Still somewhat subjective, will not satisfy everyone
Frameworks raise important questions that user has to
answer for him-/herself
We are looking at two frameworks:
NIMSAD: Normative Information Model-based
System Analysis and Design
Framework by Avison/Fitzgerald

. – p.64/192

NIMSAD
Aims:
Help understand the area of problem solving (in
general)
Help evaluate methodologies, their structures, steps,
form, nature, etc.
Help in drawing conclusions
Before presenting actual comparison, we take a look at
how IS development (or problem solving in general) is
perceived under NIMSAD

. – p.65/192

Rationale
NIMSAD framework has four essential elements
Problem situation (methodology context)
Intended problem solver (methodology user)
Problem-solving process (methodology itself)
Evaluation of the above

. – p.66/192

Problem Situation

Client

Organizations serve as context for information systems
This context is important for methodologies:
Effectiveness of IS can only be judged in this context
Interaction with organizational members during
development
Interpersonal relationships formed in this context
. – p.67/192

Problem Solver

Problem Solver Client

However powerful, useful, and effective a methodology
may be, success often depends on personal
characteristics of problem solver:
What does he/she select as relevant or dismisses as
irrelevant?
What are the implications of this selection?

. – p.68/192

Mental Constructs of Problem Solver
Perceptual process:
One of the most influential characteristics
Acts as a filter to determine what is perceived as
significant
Each person perceives reality differently
Problematic if perception of problem solver does not
match that of stakeholder

. – p.69/192

Mental Constructs of Problem Solver(2)
Values/Ethics:
Beliefs that we consider to be “good”
Help pass judgment on situations
Example: participation
High economic values: participation is a waste of
time
High social values: highly effective

. – p.70/192

Motives/Prejudices
Personal needs that we try to satisfy
Opinions that we form from our values and
experiences
Becoming conscious of these is helpful

. – p.71/192

Experience, knowledge, and skills
Acquired from education, training, and practical work
Have to match requirements of the methodology to
be used

. – p.72/192

Reasoning ability/Structuring processes
Ability to abstract essential aspects and structure
them in a meaningful way
Thinking in different ways helps to gain new insights
Communicating those thoughts in a clear way helps
other people to understand reasons

. – p.73/192

Roles
In the development process, persons take on
different roles
Advisor
Analyst
Consultant
Designer
Implementer
...
Conﬂicts between expected role behavior and
natural behavior of a person results in stress

. – p.74/192

Problem-solving Process
Methodology is a way of problem solving
Needs to help perform three essential phases:
Phase 1: Problem formulation
Phase 2: Solution design
Phase 3: Design implementation

. – p.75/192

Phase 1: Problem Formulation
Stage 1: Understanding the “situation of concern”

Mental construct

Problem Solver Client

Mental construct can have several effects on grasping
the situation
. – p.76/192

Stage 1: Understanding situation
Deriving a boundary of concern

Mental construct

Problem Solver
Client

Boundary of concern

. – p.77/192

Boundary of Concern
If we do not subject mental constructs to self-critical
examination, we may end up
accepting predeﬁned boundaries of client
construct implicit boundaries (where there are none)
not identifying relevant elements
A methodology should support this structuring of
problem by supplying appropriate methods of
investigation

. – p.78/192

Boundary of Concern(2)
Why is boundary so important?
It excludes many elements from subsequent steps
If causes for identiﬁed problems lie outside of
boundary,
it doesn’t matter how well content of boundary is
redesigned
actual problem will not be solved

. – p.79/192

Stage 2: Performing Diagnosis
Where are we now?
Stage 1 is more or less a description of situation
Diagnosis aims at understanding reasons for current
situation
Helps identify gaps of knowledge or misunderstandings
Helps in communicating with clients in deriving agreed
understandings
Two levels of expression:
Conceptual/logical level
Physical level

. – p.80/192

Conceptual/Logical Level
Describes general and situation-specific information on
an abstract level (“what” issues)
Details include information flows, people’s tasks, roles,
functions, etc.
Expressed with the help of rich pictures, variance grids,
data flow diagrams, actigrams/datagrams, bubble
charts, etc.

. – p.81/192

Physical Level
Describes physical characteristics of a situation (“who”
or “how” issues)
Details include actual products, speciﬁc individuals,
documents, computers (performance, memory
capacities, etc.)
Expressed in descriptive of tabular form

. – p.82/192

Stage 3: Deﬁning Prognosis
Where do we want to be and why?
Client wants to change current state
Prognosis is expression of desired state
Focus is not to create content of future state (that is role
of design), but to understand rationale for change
Depending on outcome of this stage, project may not be
started at all

. – p.83/192

Stage 4: Deﬁning Problems
What is preventing realization of desired state?
Analyzing the gap between current and desired state
Identify and critically examine the absence and/or
relationships of elements
Results in identifying problem areas (written down in
concrete problem statements)

. – p.84/192

Stage 5: Deriving Notional Systems
Specifying requirements of a system
If such a system is built, we
eliminate the identiﬁed problems
change from current state to described state

. – p.85/192

Phase 2: Solution Design
Here we ﬁll prognosis with content
Starting point is notional system
Consists of two stages:
Stage 6: Conceptual/logical design
Stage 7: Physical design

. – p.86/192

Stage 6: Conceptual/Logical Design
Design system on an abstract level (similar to the level
used for conceptual/logical analysis)
Most structured methodologies construct data
ﬂows/processes and/or ER-diagrams ignoring
roles/functions of individuals

. – p.87/192

Stage 7: Physical Design
Selection of ways and means to realize logical design
Usually a range of different realizations are possible
Additional criteria may play a role in selection:
Efﬁciency
Reliability
Accuracy
Security/Safety
Availability

. – p.88/192

Phase 3: Implementation
This phase determines success of whole development
process
Demonstrates validity of all previous steps
Consists of several tasks (that we are going to look at)

. – p.89/192

Tasks
Strategy and planning
Identify and adapt a strategy for sequencing all
activities
Management and control
Set up management and control functions to help
supervise activities

. – p.90/192

Tasks(2)
Environment Preparation
Adjust surrounding for future system (e.g make
changes to buildings, cabling, train users)
System development
Identify activities and needed resources (e.g.
recruitment of new personnel, acquisition of
hard-/software, coding of programs, testing)
Changeover
Integrate the new system (and introduce other
changes) into the prepared environment

. – p.91/192

Evaluation
Methodology should not be a simple execution of steps
Should help bring about an efﬁcient and effective
transformation of situations
Role of (evaluation) framework is to question
methodologies as to
what they attempt to transform
why they try to transform it
how they help in undertaking the transformation

. – p.92/192

Evaluation(2)
Evaluation of the three elements problem situation,
problem solver, problem-solving process
Before the project:
Initial assessment of the three elements
During the project:
Changes may alter the use of methodology
After the project:
Evaluate if problems were solved and how
methodology helped in doing so

. – p.93/192

Applying NIMSAD
MIMSAD is not a methodology itself (does not provide
content to different stages)
It is about ﬁnding out what elements in the framework a
methodology addresses
in what order
and how
Methodology does not have to be an exact one-to-one
mapping to framework

. – p.94/192

Applying NIMSAD(2)
NIMSAD provides important questions to check
Answers have to be found by potential users of a
methodology∗
Questions for all elements of NIMSAD
More complete list in NIMSAD book, here just an
excerpt of most important ones
∗
The following might be disturbing for some students: lots of questions
without answers

. – p.95/192

Problem Situation
Who are the clients?
How strong is their commitment?
Does methodology help in identifying clients and their
concerns?
What’s the situation like? (well-structured, less
well-structured, ill-structured)
For which situation is methodology suitable?
What does situation demand (identify problems, design
solutions for already identiﬁed problems, implement an
already designed solution)?

. – p.96/192

Problem Solver
What level of abstract and technical thinking does
methodology demand from user?
Do philosophical views advocated by methodology
match user’s view?
What knowledge sets and skills does methodology
require from user?
Are mental constructs of user considered?

. – p.97/192

Problem-solving process
Stage 1: Understanding situation of concern
Does methodology offer assistance for boundary
construction?
What is role of client (inclusion/participation or
external)?
Does methodology discuss particular methods of
investigation?

. – p.98/192

Problem-solving process(2)
Stage 2: Diagnosis
What techniques does methodology offer for
expressing situation characteristics?
What level of expression is advocated
(conceptual/logical and/or physical)
What environmental (context) information is
captured?
What tools and techniques are available?

. – p.99/192

Stage 3: Prognosis
Is this stage supported at all?
How does methodology offer help in deﬁning
prognosis?
How are desired states established?

. – p.100/192

Stage 4: Deﬁning Problems
What problems or problem types are of concern to
the methodology?
How does it help in deriving problem statements?
Are problem statements evaluated (or just
accepted)?

. – p.101/192

Stage 5: Deriving notional systems
Does methodology derive notional systems from
identiﬁed problems?
Does it offer help in formulating notional systems?

. – p.102/192

Design (Stage 6: Conceptual/Logical Design, Stage 7:
Physical Design)
Does methodology accept client’s notional system as
starting point?
Does it distinguish between logical and physical
design stages?
Does it help in formulating design solutions?
What aspects cannot be captured by methodology?
Is a user on his/her own when trying to ﬁll these
gaps?
How experienced is user to be expected in the
solution domain?
Who decides on which solution to take?

. – p.103/192

Stage 8: Implementation
What steps does methodology offer for developing
the IS?
What does it offer in terms of tools and techniques?
How does it help in handling major changes in the
notional system at this time?

. – p.104/192

Evaluation
Does methodology provide techniques for evaluating
itself and its outputs for
problem situation?
problem solver?
problem-solving process?

. – p.105/192

Evaluating Methodologies
We are going to look at two methodologies in the
framework of NIMSAD:
SSADM
SSM

. – p.106/192

SSADM: Problem Situation
Organizational context has higher priority than in other
structured methodologies
Commitment of users is checked (partially) during
feasibility study
Still SSADM is mainly concerned with formal
descriptions of data and processes via data ﬂow
diagrams
Irregular and changing patterns often left out of domain
of SSADM

. – p.107/192

SSADM: Problem Solver
SSADM does not alert its users to their mental
constructs
E.g. two different (competent) SSADM users may arrive
at two different sets of data ﬂow diagrams
Most dominant knowledge and skills required are of
technical nature
In practice, however, users also need social skills to
make methodology effective (not made explicit by
methodology)

. – p.108/192

SSADM: Problem-solving Process
Boundary construction is trial and error within
SSADM
Assumes that data ﬂow diagrams can help construct
boundary
This often establishes an implicit boundary (anything
that cannot be captured in DFDs remains outside)

. – p.109/192

SSADM: Problem-solving Process(2)
Stage 2: Diagnosis
SSADM makes most useful contribution to this stage
Use of DFDs provide clear ways of expressing flows
of formal data
Starts with physical data flows (describing how data
is processed)
Then tries to extract underlying meaning into a
logical data model and logical data flow model
Does so by removing physical elements of
elementary processes and then
reconstructing/regrouping transformed processes

. – p.110/192

Stage 2: Diagnosis
Logicalization may be problematic, as physical
constraints may disappear
Example: agent updates customer record on
laptop, later this is synchronized with headquarters
After logicalization there may only be one
customer record ﬁle left. . .
Regular and frequent patterns get modeled, special
cases may be forgotten

. – p.111/192

Stage 3: Prognosis
Deﬁning prognosis is not really possible in SSADM
Although better than in other structured approaches,
as clients get to choose among different Business
Systems Options (BSO)
Feasibility study also helps in deciding if beneﬁts
outweigh costs
Rationale of clients’ desired states may not become
clear (it is assumed that clients know what they want)

. – p.112/192

Stage 4: Deﬁning problems
There is an explicit problem deﬁnition phase during
feasibility study
At this point things are still vague, however
As there is no real prognosis, problems cannot be
derived by looking at differences between diagnosis
and prognosis

. – p.113/192

Strength of SSADM is in formalizing requirements of
client
Achieved by modeling the data flows of the required
system with help of DFDs
Functions and user interfaces of the system can be
specified
Developing specification prototype helps in getting
feedback from client
Again, assumes that client knows what he/she wants

. – p.114/192

Stages 6 and 7: Design
SSADM distinguishes between logical and physical
design
We are going to look at these in turn

. – p.115/192

Stages 6: Logical Design
Most useful and rigorous techniques offered by
SSADM are DFDs
Designs are usually created by modifying logical
diagnosis diagram using requirements and feasibility
study as guideline
SSADM also very useful for structuring dialogues
Does not take any interest in how design decisions
will affect environment (BSO only looks at
requirements)

. – p.116/192

Stages 7: Physical Design
SSADM provide mainly generic guidelines
Many decisions depend on technical issues speciﬁc
to chosen environment
Environment is chosen in Technical System Option
(TSO) phase of SSADM
In TSO technical alternatives drawn up from
requirements are presented to clients for decision
Better than other structured approaches (where
there is no TSO)
Still problems for non-computerized areas of design

. – p.117/192

Stages 8: Implementation
Completely missing (one of the weakest points)

. – p.118/192

SSADM: Evaluation
Completely missing (the other of the weakest points)

. – p.119/192

SSADM: Summary
SSADM is/was popular methodology for formal design
of IS
Better in “soft”, non-technical aspects than other
structured approaches
However, still a technical methodology with weak points
in “soft” aspects of IS development, the implementation
phase, and self-evaluation
At least, does not claim to cover “soft” aspects
adequately

. – p.120/192

SSM: Problem Situation
SSM is one of the few methodologies that makes
comments about problem situation
SSM is applicable to ill-structured situations
In contrast to structured methodologies (which seek a
“single” truth), SSM considers many different views
Encourages its users to develop new perceptions of
organizations through systems thinking
SSM recognizes three roles: client (initiates study),
problem owner (identiﬁes relevant systems), problem
solver (uses SSM to resolve client’s concerns)

. – p.121/192

SSM: Problem Solver
SSM recognizes the need for reﬂection
Considers mental constructs of its users
Methodology user takes on role of debate facilitator and
learner
However, SSM relies on its users to have considerable
conceptualization, abstraction, philosophical, and
political skills

. – p.122/192

SSM: Problem-solving Process
SSM provides insightful contributions to boundary
construction
Boundaries, problem ownership, problem content,
and context issues are all open to question
Context of a problem situation can be captured in
rich pictures

. – p.123/192

SSM: Problem-solving Process(2)
Stage 2: Diagnosis
SSM does not prescribe particular form of
expression to capture essential aspects of an
organization
Any technique may be used: graphs, text, animation,
pictures, charts, tables, etc. (“rich pictures”)
This is a strength and a weakness:
Gives users a lot of freedom
But also a lot of responsibility (user has to know
what he/she is doing)
SSM does not distinguish between logical and
physical diagnosis descriptions

. – p.124/192

Stage 3: Prognosis/Stage 4: Deﬁning problems are
skipped (details later)
Are handled a little differently in SSM

. – p.125/192

SSM does not derive notional systems from
identiﬁed problems (see Stage 4)
Attempts to develop many potentially relevant
notional systems
Formulates notional systems with root deﬁnitions
(CATWOE)

. – p.126/192

Stage 6/7: Design
No distinction between logical and physical design
Uses root deﬁnitions as guide for design process
Design is not a strong point of SSM
Not quite clear how to derive at an activity-based
design from system-based root deﬁnition

. – p.127/192

Stage 8: Implementation
Missing

. – p.128/192

Stage 3: Prognosis
SSM operates in environment where there are
multiple desired states
clients who are unsure of their desired states
SSM does not attempt to construct clear prognosis
outline
Each root deﬁnition implies a particular desired state
There are many potentially relevant notional systems

. – p.129/192

Stage 4: Defining problems
As there is no clear prognosis, it is difficult to derive
problem statements from mapping diagnosis to
prognosis
SSM maps design models against diagnosis to
determine relevance
Decision on relevance is carried out by conducting
debate with participants
Practically, Stage 4 is deferred until design is finished

. – p.130/192

SSM: Evaluation
SSM does not have an explicit step for evaluation
Nevertheless, it propagates learning
When evaluation is done, usually focus on
problem-solving process
Mostly done through SSM case studies (UK Health
Service, Shell, IS planning)

. – p.131/192

SSM: Summary
SSM is a methodology for ill-structured problem
situations
Allows discussions on different viewpoints of
participants
Author of SSM also encourages debate and
discussions about SSM
SSM is in constant process of reﬁnement to meet valid
criticism

. – p.132/192

Framework by Avison/Fitzgerald
Has seven basic elements:
Philosophy
Model
Techniques and Tools
Scope
Outputs
Practice
Product

. – p.133/192

Philosophy
The principle (or set of principles) that underlies a
methodology
Several areas are distinguished
Paradigm
Objectives/Domain
Target

. – p.134/192

Paradigm
Science paradigm vs. systems paradigm
Science paradigm explains world through reductionism,
repeatability, refutation
Systems paradigm is concerned with whole picture,
interrelationships between parts of the whole
Simpliﬁed this means
Science paradigm ≡ “hard” thinking
Systems paradigm ≡ “soft” thinking

. – p.135/192

Paradigm(2)
Debate has been extended to
Epistemology: study of knowledge, how we acquire
knowledge
Ontology: study of being (or what “is”)
Let’s make a short excursion into philosophy

. – p.136/192

Epistemology
The two extreme positions are positivism and
interpretivism
Positivism
There is an objective reality beyond the human mind
Ideas and theories need to be tested against this
reality
This is done via experiments, surveys, ﬁeld studies,
etc.

. – p.137/192

Epistemology(2)
Interpretivism
Knowledge of world is constructed through a
person’s lived experience
Reality is constructed socially
Interpretivists use case studies, hermeneutics,
phenomenology, etc.
Hermeneutics: theory and practice of
interpretation∗
Phenomenology: study of phenomena
(appearance of things) from a ﬁrst person point of
view
∗
Hermeneutic cycle is process by which we return to a text (or the world),
and derive a new interpretation – perhaps a new one every time or a new
one for every interpreter . – p.138/192

Ontology
The two extreme positions here are realism and
nominalism
Realism
There are universal entities and universal terms to
describe them
E.g. many individual horse entities, but there is also
general concept of an “ideal” horse
Nominalism
There are no universal entities, we can only refer to
concrete, individual entities
E.g. many individual horse entities, speaking of
horses in general is mere convenience for speaking
of many things at once
. – p.139/192

Excursion into Philosophy
Usually extreme positions not encountered in pure form
A positivist confronted with a loaded gun will not start
calculating trajectories, possible areas of impact, he will
experience strong (subjective) emotions
An interpretivist paying £1000 into his bank account will
not accept the teller’s subjective point of view that
crediting £800 is close enough

. – p.140/192

Paradigm(3)

Positivism
Objectivist
Epistemology
Interpretivism approaches

Subjectivist
approaches

Realism Nominalism
Ontology
. – p.141/192

Objectives/Domain
What is methodology trying to achieve within an
organization?
Development of a purely “computerized” IS?
Does it take wider view including other tasks?
Does it try to reengineer whole business
processes/change strategy of organization?

. – p.142/192

Target
For what

types of problems
environments
types or sizes of organizations

is methodology applicable?

. – p.143/192

Model
What constructs does methodology use to model the
real world?
Verbal
Analytic/mathematical
Iconic/pictorial/schematic
Simulation

. – p.144/192

What techniques and tools are provided to support user
of methodology?

. – p.145/192

Scope
Which phases of life cycle of IS development does
methodology cover?
strategy, feasibility, analysis, logical design, physical
design, programming, testing, implementation,
evaluation, maintenance
Problematic if methodology does not follow life cycle

. – p.146/192

Outputs
What is methodology producing in terms of
deliverables?
This can range from feasibility studies, requirements
and analysis speciﬁcations up to working
implementations of IS
When are these outputs generated?

. – p.147/192

Practice
What is the background of methodology (commercial or
academic)?
What is the user base (numbers and types of users)?
Who are the participants and what are their required
skill levels (can users apply methodology themselves or
are highly skilled consultants necessary)?

. – p.148/192

Product
What do you get for your money, i.e. when purchasing
methodology, what is included?
Software tools
Written documentation
Training
Help service

. – p.149/192

Applying Avison/Fitzgerald Framework
We are looking at SSADM and SSM in light of
Avison/Fitzgerald framework
Some arguments have already been presented in
NIMSAD framework
Therefore, this is kept shorter

. – p.150/192

Philosophy
Paradigm
SSADM
Follows science paradigm
Belongs to objectivist approaches
SSM
Clearly follows systems paradigm
Belongs to subjectivist approaches

. – p.151/192

Philosophy(2)
Objectives/Domain
SSADM
Has objective of developing computerized IS
Neglects organizational aspects
SSM
Tries to capture a broader view, including
organizational context

. – p.152/192

Philosophy(3)
Target
SSADM
Data ﬂow diagrams not applicable for all types of
problems (decision support systems, web
applications)
Targets large organizations (although there is
slimmer version called MicroSSADM)
SSM
Applicable in human activity situations with
ill-structured problems

. – p.153/192

Model
SSADM
Main modeling concept: data ﬂow diagrams
SSM
Very ﬂexible “rich pictures”

. – p.154/192

SSADM
Main technique: structured approach to modeling
and design
Tools like drawing tools, tools for project
management, code generation seen as useful, but
not essential
SSM
Organizational techniques
Does not advocate or mention speciﬁc tools

. – p.155/192

Scope
SSADM includes
(Strategy), feasibility, analysis, logical design,
physical design
SSM includes
Strategy, (feasibility), analysis, (logical design)

. – p.156/192

Outputs
SSADM
Basically follows SDLC, so in each phase certain
documents are produced (e.g. feasibility study,
requirements speciﬁcation, design documents)
SSM
Divided into seven stages, at the end of which
certain documents are produced (e.g. rich pictures,
root deﬁnitions)

. – p.157/192

Practice
SSADM
Commercial background
“Traditional” participants: analysts, designers,
(programmers)
SSM
Academic background
Participants: much greater role of client and problem
owner

. – p.158/192

Practice(2)
Difﬁcult to evaluate user base, some numbers:
Fitzgerald 1999: 57% of organizations use
methodologies: 11% purely commercial ones, 30%
adopted commercial ones, 59% unique ones
Russo/Wynekoop 1995: of 132 organizations using a
methodology, 77% used structured approach, 8%
prototyping/iterative approach, 5% RAD approach

. – p.159/192

Product
SSADM
Large store of manuals, books, etc.
Certiﬁcate of proﬁciency can be acquired
SSM
A set of academic papers and books

. – p.160/192

Capability Maturity Model (CMM)
Created by the Software Engineering Institute at
Carnegie Mellon
Originally aimed at helping Department of Defense
assess capabilities of vendors and sub-contractors
Not so much about methodologies themselves, but
about how well an organization organizes its processes
Has ﬁve levels, level 5 being the best one

. – p.161/192

Overview

Improving Optimizing
process

Predictable Managed
process

Standard Defined
process

Disciplined Repeatable
process

Initial

. – p.162/192

Initial (Level 1)
Development is characterized as being ad hoc or even
chaotic
Processes are not deﬁned
Everything depends on skilled individuals to get their
act together
Software is typically delivered late and over budget
Little effective management and control
Unfortunately, too many organizations are still at this
level

. – p.163/192

Repeatable (Level 2)
Basic project management processes are established
Allows tracking of costs, schedules, functionality
Somme process discipline is in place
Earlier success on projects with similar applications can
be repeated

. – p.164/192

Deﬁned (Level 3)
Management and engineering activities are
documented, standardized, and integrated into a
standard process
All projects use an approved, tailored version of the
organization’s process
Training programs are implemented to ensure that staff
has necessary skill

. – p.165/192

Managed (Level 4)
Detailed measures of the process and product quality
are collected and analyzed
Process and products are quantitatively understood and
controlled
Risks in moving to new application domains are known
and carefully managed

. – p.166/192

Optimizing (Level 5)
Entire organization is focused on continuous process
improvement
Organization can identify weaknesses and prevent
potential defects beforehand
Cost/beneﬁt analyses of new technologies base on data
on effectiveness of current process

. – p.167/192

Summary
CMM is based on manufacturing and product-building
view of systems development
This is not always appropriate as often IS development
is more of a creative art than a science
CMM is mainly concerned with (technical) aspects of
software development, not the wider area of IS
development
High levels in CMM do not always lead to high quality
software, just well-documented processes

. – p.168/192

Chapter Summary
Comparing methodologies is a very difﬁcult task
Unfortunately, no silver bullet for doing so has been
found yet
As many views as writers on the subject

. – p.169/192

Comparison Of Methodologies

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Comparison Of Methodologies (20)

More from guestc990b6 (12)

Recently uploaded (20)

Comparison Of Methodologies