Comparison Of Methodologies

1. Chapter 13
Comparison of
Methodologies
. – p.41/192

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

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

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

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

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

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

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

9. Theoretical Model(2)
Comparison of methodologies should be done similarly:
Comparisons of components and inter-component
relations
Components should be classified by their functions
(what problems they address)
Components should then be characterized by their
structures
Problem: methodologies and their components are
often not rigorously defined
Methodologies and their components themselves need
to be modeled
. – p.49/192

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

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

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

13. Step 2: Classify Components
Having identified components, they are now classified
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

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

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

16. Step 3: Select Comparison Topics
Topics should be selected based upon goals of a
specific comparison
Two general criteria can always be used:
Components should be comparable
Comparison between them should help in showing
key differences
. – p.56/192

17. Select Comparison Topics(2)
Classification 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 find the artifacts, representations, and
actions that could be compared
. – p.57/192

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

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

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

21. 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 findings of scientists
. – p.61/192

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

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

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

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

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

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

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

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

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

31. Mental Constructs of Problem Solver(3)
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

32. Mental Constructs of Problem Solver(4)
Experience, knowledge, and skills
Acquired from education, training, and practical work
Have to match requirements of the methodology to
be used
. – p.72/192

33. Mental Constructs of Problem Solver(5)
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

34. Mental Constructs of Problem Solver(6)
Roles
In the development process, persons take on
different roles
Advisor
Analyst
Consultant
Designer
Implementer
...
Conflicts between expected role behavior and
natural behavior of a person results in stress
. – p.74/192

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

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

37. Stage 1: Understanding situation
Deriving a boundary of concern
Mental construct
Problem Solver
Client
Boundary of concern
. – p.77/192

38. Boundary of Concern
If we do not subject mental constructs to self-critical
examination, we may end up
accepting predefined 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

39. Boundary of Concern(2)
Why is boundary so important?
It excludes many elements from subsequent steps
If causes for identified 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

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

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

42. Physical Level
Describes physical characteristics of a situation (“who”
or “how” issues)
Details include actual products, specific individuals,
documents, computers (performance, memory
capacities, etc.)
Expressed in descriptive of tabular form
. – p.82/192

43. Stage 3: Defining 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

44. Stage 4: Defining 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

45. Stage 5: Deriving Notional Systems
Specifying requirements of a system
If such a system is built, we
eliminate the identified problems
change from current state to described state
. – p.85/192

46. Phase 2: Solution Design
Here we fill prognosis with content
Starting point is notional system
Consists of two stages:
Stage 6: Conceptual/logical design
Stage 7: Physical design
. – p.86/192

47. 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
flows/processes and/or ER-diagrams ignoring
roles/functions of individuals
. – p.87/192

48. 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:
Efficiency
Reliability
Accuracy
Security/Safety
Availability
. – p.88/192

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

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

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

52. Evaluation
Methodology should not be a simple execution of steps
Should help bring about an efficient 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

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

54. Applying NIMSAD
MIMSAD is not a methodology itself (does not provide
content to different stages)
It is about finding 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

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

56. 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 identified problems, implement an
already designed solution)?
. – p.96/192

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

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

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

60. Problem-solving process(3)
Stage 3: Prognosis
Is this stage supported at all?
How does methodology offer help in defining
prognosis?
How are desired states established?
. – p.100/192

61. Problem-solving process(4)
Stage 4: Defining 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

62. Problem-solving process(5)
Stage 5: Deriving notional systems
Does methodology derive notional systems from
identified problems?
Does it offer help in formulating notional systems?
. – p.102/192

63. Problem-solving process(6)
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 fill these
gaps?
How experienced is user to be expected in the
solution domain?
Who decides on which solution to take?
. – p.103/192

64. Problem-solving process(7)
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

65. Evaluation
Does methodology provide techniques for evaluating
itself and its outputs for
problem situation?
problem solver?
problem-solving process?
. – p.105/192

66. Evaluating Methodologies
We are going to look at two methodologies in the
framework of NIMSAD:
SSADM
SSM
. – p.106/192

67. 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 flow
diagrams
Irregular and changing patterns often left out of domain
of SSADM
. – p.107/192

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

69. SSADM: Problem-solving Process
Stage 1: Understanding situation of concern
Boundary construction is trial and error within
SSADM
Assumes that data flow diagrams can help construct
boundary
This often establishes an implicit boundary (anything
that cannot be captured in DFDs remains outside)
. – p.109/192

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

71. SSADM: Problem-solving Process(3)
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 file left. . .
Regular and frequent patterns get modeled, special
cases may be forgotten
. – p.111/192

72. SSADM: Problem-solving Process(4)
Stage 3: Prognosis
Defining 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 benefits
outweigh costs
Rationale of clients’ desired states may not become
clear (it is assumed that clients know what they want)
. – p.112/192

73. SSADM: Problem-solving Process(5)
Stage 4: Defining problems
There is an explicit problem definition 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

74. SSADM: Problem-solving Process(6)
Stage 5: Deriving notional systems
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

75. SSADM: Problem-solving Process(7)
Stages 6 and 7: Design
SSADM distinguishes between logical and physical
design
We are going to look at these in turn
. – p.115/192

76. SSADM: Problem-solving Process(8)
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

77. SSADM: Problem-solving Process(9)
Stages 7: Physical Design
SSADM provide mainly generic guidelines
Many decisions depend on technical issues specific
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

78. SSADM: Problem-solving Process(10)
Stages 8: Implementation
Completely missing (one of the weakest points)
. – p.118/192

79. SSADM: Evaluation
Completely missing (the other of the weakest points)
. – p.119/192

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

81. 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 (identifies relevant systems), problem
solver (uses SSM to resolve client’s concerns)
. – p.121/192

82. SSM: Problem Solver
SSM recognizes the need for reflection
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

83. SSM: Problem-solving Process
Stage 1: Understanding situation of concern
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

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

85. SSM: Problem-solving Process(3)
Stage 3: Prognosis/Stage 4: Defining problems are
skipped (details later)
Are handled a little differently in SSM
. – p.125/192

86. SSM: Problem-solving Process(4)
Stage 5: Deriving notional systems
SSM does not derive notional systems from
identified problems (see Stage 4)
Attempts to develop many potentially relevant
notional systems
Formulates notional systems with root definitions
(CATWOE)
. – p.126/192

87. SSM: Problem-solving Process(5)
Stage 6/7: Design
No distinction between logical and physical design
Uses root definitions 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 definition
. – p.127/192

88. SSM: Problem-solving Process(6)
Stage 8: Implementation
Missing
. – p.128/192

89. SSM: Problem-solving Process(7)
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 definition implies a particular desired state
There are many potentially relevant notional systems
. – p.129/192

90. SSM: Problem-solving Process(8)
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

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

92. 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 refinement to meet valid
criticism
. – p.132/192

93. Framework by Avison/Fitzgerald
Has seven basic elements:
Philosophy
Model
Techniques and Tools
Scope
Outputs
Practice
Product
. – p.133/192

94. Philosophy
The principle (or set of principles) that underlies a
methodology
Several areas are distinguished
Paradigm
Objectives/Domain
Target
. – p.134/192

95. 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
Simplified this means
Science paradigm ≡ “hard” thinking
Systems paradigm ≡ “soft” thinking
. – p.135/192

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

97. 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, field studies,
etc.
. – p.137/192

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

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

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

101. Paradigm(3)
Positivism
Objectivist
Epistemology
Interpretivism approaches
Subjectivist
approaches
Realism Nominalism
Ontology
. – p.141/192

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

103. Target
For what
types of problems
environments
types or sizes of organizations
is methodology applicable?
. – p.143/192

104. Model
What constructs does methodology use to model the
real world?
Verbal
Analytic/mathematical
Iconic/pictorial/schematic
Simulation
. – p.144/192

105. Techniques and Tools
What techniques and tools are provided to support user
of methodology?
. – p.145/192

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

107. Outputs
What is methodology producing in terms of
deliverables?
This can range from feasibility studies, requirements
and analysis specifications up to working
implementations of IS
When are these outputs generated?
. – p.147/192

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

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

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

111. Philosophy
Paradigm
SSADM
Follows science paradigm
Belongs to objectivist approaches
SSM
Clearly follows systems paradigm
Belongs to subjectivist approaches
. – p.151/192

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

113. Philosophy(3)
Target
SSADM
Data flow 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

114. Model
SSADM
Main modeling concept: data flow diagrams
SSM
Very flexible “rich pictures”
. – p.154/192

115. Techniques and Tools
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 specific tools
. – p.155/192

116. Scope
SSADM includes
(Strategy), feasibility, analysis, logical design,
physical design
SSM includes
Strategy, (feasibility), analysis, (logical design)
. – p.156/192

117. Outputs
SSADM
Basically follows SDLC, so in each phase certain
documents are produced (e.g. feasibility study,
requirements specification, design documents)
SSM
Divided into seven stages, at the end of which
certain documents are produced (e.g. rich pictures,
root definitions)
. – p.157/192

118. Practice
SSADM
Commercial background
“Traditional” participants: analysts, designers,
(programmers)
SSM
Academic background
Participants: much greater role of client and problem
owner
. – p.158/192

119. Practice(2)
Difficult 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

120. Product
SSADM
Large store of manuals, books, etc.
Certificate of proficiency can be acquired
SSM
A set of academic papers and books
. – p.160/192

121. 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 five levels, level 5 being the best one
. – p.161/192

122. Overview
Improving Optimizing
process
Predictable Managed
process
Standard Defined
process
Disciplined Repeatable
process
Initial
. – p.162/192

123. Initial (Level 1)
Development is characterized as being ad hoc or even
chaotic
Processes are not defined
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

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

125. Defined (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

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

127. Optimizing (Level 5)
Entire organization is focused on continuous process
improvement
Organization can identify weaknesses and prevent
potential defects beforehand
Cost/benefit analyses of new technologies base on data
on effectiveness of current process
. – p.167/192

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

129. Chapter Summary
Comparing methodologies is a very difficult task
Unfortunately, no silver bullet for doing so has been
found yet
As many views as writers on the subject
. – p.169/192