Information Systems Development Methodologies: Making the right choice

1
Information Systems Development Methodologies
Making the right choice
Taken from Avison, D.E. Fitzgerald, G. (1995).
Information Systems Development Methodologies,
Techniques and Tools. 2nd Edition.
Any comparison will be subjective
DANGER
setting up a framework may identify a set of
idealised features
then the follow up check list correctly scores
your methodology the highest!
Like selling cars...
2
Information Systems Development Methodologies
Making the right choice
Why compare methodologies?
Academic better understanding of their nature
to be able to classify them
Practical to choose one (or part of one) for a
particular application or an organisation as a
whole

• Methodologies vary greatly in what you get
• details of every stage in the life cycle or vague
  outline principles
• coverage may vary from more strategic to the
  details of implementation
• problem-specific or all-encompassing,
  general-purpose methodology
• may be useable by anyone (including users) or
  only by highly trained specialists
• require a big team to operate it sensibly or may
  not specify tasks at all
• may or may not include CASE tools

3
Information Systems Development Methodologies
Making the right choice
Variability in development results WHY? is
this good or bad?
developers may be given lots of leeway in terms
of how they perform the tasks, have varying skill
levels, but the tighter, more specific the
methodology the more reproducible the results,
particularly where exact techniques and tools to
be employed are specified
However, lack of repeatability is the hallmark of
IS development methodologies - all of them
it is impossible to create exactly the same
environment in an organisation for two sets of
developers to develop systems which can be
compared. Checkland challenged developers of
systems perceived to be successful to prove that
another methodology would not have been better -
they couldnt, of course!
often used to suggest that information systems
is not really an engineering discipline (Avison
Fitzgerald, p 433, para 3)
4
Information Systems Development Methodologies
Making the right choice
the best methodology?
the methodology should embody a best way of
developing systems
whether this is true is rarely asked
the more usual questions are

• whether it fits in with the organisations way of
  working
• whether it specifies what deliverables are
  required at the end of each stage
• whether it enables better control and improved
  productivity
• whether it supports a particular set of CASE tools

a best way - not the best way because there
are always trade-offs between quality, quantity,
skill levels, reliability, generality ...
5
Information Systems Development Methodologies
Making the right choice
Bjørn-Andersens framework for comparison of
methodologies
1. What research paradigms form the foundation
for the methodology? 2. What are the underlying
value systems? 3. What is the context where a
methodology is useful? 4. To what extent is
modification enhanced or even possible? 5. Does
communication and documentation operate in the
users dialect, either expert or not? 6. Does
transferability exist? 7. Is the societal
environment dealt with, including possible
conflicts? 8. Is user participation really
encouraged or supported?
this check list focuses attention on some wider
issues but remains subjective why is user
participation desirable?
6
Information Systems Development Methodologies
Making the right choice
Davis contingency approach to selecting an
appropriate methodology
Measure the level of uncertainty in a system
using
1. System complexity or ill-structuredness 2. The
state of flux of the system 3. The user component
of the system, for example, the number of people
affected and their skill level 4. The level of
skill and experience of the analysts
once the level of uncertainty has been
determined, the appropriate approach to
determining the requirements can be made
prototype or evolutionary approach
HIGH
UNCERTAINTY
work out from existing system
LOW
interviewing users
7
Information Systems Development Methodologies
Making the right choice
Davis contingency approach accentuates the
problem content
Avison Taylor identified 5 classes of situation
and appropriate approaches
traditional methodology (SSADM) data or process
model (JSD or STRADIS) soft systems approach
(SSM) a people-focussed, like ETHICS a
contingency approach (Multiview)
Class 1 well-structured, defined problems, clear
requirements Class 2 as above but unclear
requirements Class 3 unstructured, unclear
objectives Class 4 high user-interaction
systems Class 5 very unclear situations
However
methodologies are NOT stable there are a variety
of versions out there and practice is often
different to that prescribed
8
Information Systems Development Methodologies
Making the right choice
Avison Fitzgeralds framework for comparison of
information systems development methodologies

• 1. Philosophy
• Paradigm
• Objectives
• Domain
• Target

2. Model
3. Techniques and tools
4. Scope
5. Outputs

• 6. Practice
• Background
• User base
• Players

7. Product
SPEED? QUANTITY? USER MODIFICATION?
not addressed
9
Information Systems Development Methodologies
Making the right choice
Philosophy
distinguishes a method from a methodology
may be explicit but in most methodologies is
implicit
a set of principles that underlie the methodology
NOT just wishing to improve the world of
information systems development
this is perhaps the most important aspect when
comparing methodologies - nearly ALL the features
are highly dependent upon the philosophy and
without this understanding, the methodology is
difficult to explain
10
Information Systems Development Methodologies
Making the right choice

• Philosophy
• paradigm

a specific way of thinking about problems
science
systems
reduce the complexity of the variety of the real
world in experiments whose results are validated
by their repeatability, and thereby build
knowledge by the refutation of hypotheses
Checkland argues that human activity systems
do not display such characteristics, they have
emergent properties (that is the whole is
greater than the sum of the parts)
systems paradigm concern is with the whole
picture, the emergent properties and
inter-relationships
implies that breaking things down into smaller
parts does not disrupt the system
HARD
SOFT
THINKING
11
Information Systems Development Methodologies
Making the right choice

• Philosophy
• paradigm

the theory of knowledge
the study of the nature and essence of things
ONTOLOGY
EPISTEMOLOGY
Positivism
Interpretivism
Realism
Nominalism
Positivism
Objectivist Approaches
EPISTEMOLOGY
Subjectivist Approaches
Interpretivism
Realism
Nominalism
ONTOLOGY
12
Information Systems Development Methodologies
Making the right choice
Realism
postulates that the universe comprises
objectively given, immutable objects and
structures. These exist as empirical entities,
on their own, independent of the observers
appreciation of them
Nominalism
reality is not a given immutable out there,
but is socially constructed. It is the product
of the human mind. Social relativism is the
paradigm adopted for understanding social
phenomena and is primarily involved in
explaining... the social process of reality
construction
Positivism
implies the existence of causal relationships
which can be investigated using scientific method
Interpretivism
implies there is no single truth that can be
proven by such investigation. Different views
and interpretations are potentially legitimate
and the way to progress is not to try and
discover the one correct view but to accept the
differences and seek to gain insight by a deep
understanding of such complexity.
13
Information Systems Development Methodologies
Making the right choice
Objectivist
Objectivist Approaches
largely embodied in techniques such as entity
relationship modelling or data flow diagrams
Subjectist
most areas involving peoples lives may include
facts, like sales targets which are negotiated
Subjectivist Approaches
it is clear SSM adopts the systems paradigm - the
subjectivist approach. The participative
approach of ETHICS analyses the work system
without decomposition. ISAC, though it is also
participative, is reductionist
the only way to solve complex problems is to
divide them into sub-problems until they become
manageable. A requirement for this to work is
that the solution to the sub-problems gives the
solution for the problem as a whole, that is,
that the division in sub-problems is coherent.
STRADIS, YSM, IE, SSADM, Merise, JSD, OOA are all
reductionist, accept the ontological position of
realism and so firmly belong in the science
paradigm
14
Information Systems Development Methodologies
Making the right choice

• Philosophy
• objectives
• domain
• target

determines the boundaries of the area of concern
the problem with concentrating only on aspects
to be computerised is that this is an artificial
boundary in terms of the logic of the business.
There is no reason why the solution to a
particular problem should reside only in the area
that can be automated.
is it aimed at particular types of application,
types of problem, size of system or
environment? what is the reality of the
methodology being general purpose?
in choosing and understanding a methodology, it
might be a good idea to ask the question could
the use of this methodology lead to the
implementation of a purely organisational or
manual solution? It is interesting to note that
most of the widely-used commercial methodologies
would give No, whereas most academic
methodologies would probably give Yes,
excepting BPR.
15
Information Systems Development Methodologies
Making the right choice
Model
basis of the methodologys view of the world - an
abstraction
4 categories of models

• Verbal
• Analytic
• Iconic
• Simulation

IS methodology models of this type
this dominance is because of the perceived
importance of communication between users and
analysts
abstraction
stripping an idea or a system of its concrete or
physical features - provides a way of viewing
important aspects of the system at various levels
the essence
without compromise
the detail
the process of abstraction loses information and
so a model should only lose that information
which is not part of the essence of the system.

• Abstraction is closely related to hierarchical
  decomposition. Natural levels of
  decomposition, are
• conceptual
• logical
• physical

16
Information Systems Development Methodologies
Making the right choice

• Natural levels of decomposition
• conceptual
• logical
• physical

a description of the universe of discourse
Concept the definition of the problem
structure of an IS, like a map defines the
problem structure of a transport system.
Logical level a description of the IS without
any reference to the technology that could be
used to implement it - its scope is the IS itself
not the UoD mainly to provide requirements
specification of the IS
Physical level a description of the IS
including the technology of the particular
implementation
17
Information Systems Development Methodologies
Making the right choice
Techniques Tools
Chapter 4 Techniques 4.1 Introduction 4.2
Rich Pictures 4.3 Root definitions 4.4
Conceptual models 4.5 Entity modelling 4.6
Normalisation 4.7 Data flow diagramming 4.8
Decision trees 4.9 Decision tables 4.10
Structured English 4.11 Action diagrams 4.12
Entity life cycle 4.13 Object orientation 4.14
Structure diagrams 4.15 Matrices
Chapter 5 Tools 5.1 Introduction 5.2
Project management tools 5.3 Database
management systems 5.4 Data dictionary
systems 5.5 Systems repositories 5.6 Drawing
tools 5.7 CASE tools
18
Information Systems Development Methodologies
Making the right choice
Techniques Tools
many methodologies include techniques as part of
them- STRADIS, YSM, SSADM and JSD
some, like ISAC, do not rely on particular
techniques
some, like IE, explicitly suggest that techniques
are not a fundamental part of the methodology and
that recommended techniques can be replaced as
better ones come along
SSADM, Merise and IE stress a separation between
data and processes so these methodologies would
not fit well with an object-oriented modelling
technique which integrates the two
19
Information Systems Development Methodologies
Making the right choice
Techniques Tools
SSM does not even MENTION tools, let alone
recommend the use of particular ones. However,
many methodologies do - YSM, IE, SSADM, Merise,
JSD, OOA and Process Innovation
they range from simple drawing tools to those
which support the whole development process,
including prototyping, project management and
code generation
IE, like RAD, suggest developments shouldnt
proceed with the use of tools
SSADM and OOA suggest tools are helpful but not
essential
20
Information Systems Development Methodologies
Making the right choice
Scope
STRADIS
ETHICS
SSADM
Merise
ISAC
YSM
OOA
SSM
JSD
IE
PI
Strategy
Feasibility
Analysis
Logical design
Physical design
Programming
Testing
Implementation
Evaluation
Maintenance
SCOPE OF METHODOLOGIES
Strategy is used to indicate any aspects which
relate to organisation-wide context and deals
with overall IS strategy, purpose and planning
Comparisons do not include Multiview (a
combinational methodology), RAD (similar to IE),
KADS (applied to expert systems only) or
Euromethod (simply a framework)
21
Information Systems Development Methodologies
Making the right choice
Outputs
Can vary from being an analysis specification to
a working implementation of the system
Can be considerable variation not only in terms
of what should be produced but also in the level
of detail that the methodology specifies
blueprint for action
Related to whether the methodology is a
framework within which analyst has much
discretion
outputs also help direct the analyst - let them
know that they are proceeding correctly some
outputs may be described in great details but not
how to generate them viz. ISACs analysis of
change using A-graphs
this may be the creative part!
22
Information Systems Development Methodologies
Making the right choice

• Practice
• background
• user base
• players

the use of the methodology
commercial
Origins?
academic
Wasserman et al (1983). Characteristics of
software development methodologies. In Olle et
al. (1983). Information systems design
methodologies A feature analysis. Pub. North
Holland, Amsterdam.
Vendors would have you believe anyone who
enquired about the methodology was actively using
it!
Of 24 methodologies investigated nearly half had
been used in 10 or fewer projects
19 SSADM 12 JSD 9 IE 8 YSM 11 in-house
Informatics survey of 60 users in 1990
In France Merise is used in between 20-61 of
cases
23
Information Systems Development Methodologies
Making the right choice

• Practice
• background
• user base
• players

Who is supposedly involved with the use of the
methodology?
What roles do they perform?
traditional view is that of a specialist team of
professional systems analysts and designers
professional programmers - STRADIS, YSM, IE,
SSADM, Merise, JSD and OOA
in ETHICS the users themselves perform the
analysis and design and consultants are used when
required and a facilitators are central to the
methodology
SSM, ISAC, PI and ETHICS have a different view
users have a more proactive role
some level of skill is always required
Some methodologies also require considerable user
skills
but training may not be explicitly included for
users - ETHICS does so
24
Information Systems Development Methodologies
Making the right choice
Product
What is supplied when purchasing a methodology?
likely to be a minimum set
with extras add-ins

• Software
• development support tools
• written documentation
• agreed number of training hours
• telephone help service
• consultancy

maybe a large set of manuals, the recipes, like
SSADM
or a set of academic articles, like SSM
some come with certificated training courses,
consultants and facilitators
25
Information Systems Development Methodologies
Making the right choice
Why using a methodology of any sort can be a
problem itself
1. Can apparently slow down productivity -
specification of tasks and modelling can seem a
burden 2. Many are complex to use and always
seemed designed for large projects only 3. Often
all requirements treated with equal intensity
whereas they are not equally important - gilding
the lily and encourages wish lists 4. Require
significant level of skills applied to the
methodology rather than to organisation or the
problem 5. Tools often difficult to use and do
not supply the supposed benefits - can shift the
focus from analysis and design to
documentation 6. No contingency w.r.t. project
size or type 7. Often one-dimensional approach
used - that may be its strength but underlying
issues often ignored 8. Some methodologies too
inflexible and do not allow changes of
requirements 9. Invalid assumptions made, such as
stable external or competitive environt and
alignment of IS with business 10. Application of
an accepted methodology may lead to goal
displacement - focus of procedures rather than
real needs of the project 11. Seen as restricting
the freedom of developers 12. Ultimately has not
resulted in better systems