Systems development
Methodologies
IN364
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
1
Agenda
• What is systems development
• Theories, methodologies, process models
and tools for systems development
• Different process models
• A mixed approach
• Prototyping
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
2
What is systems development?
• Efforts concerning the product and the
efforts concerning the process
• Reflective efforts and efforts resulting in
changes
• Reflective efforts concerning the existing
and visions
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
3
Different perspectives on SD
•
•
•
•
A process of construction
A process of organisational change
A process of learning
A political process
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
4
Theory in Systems Development
• We need an independent understanding of
system development – enable us to
understand the situation and compare and
select properly between different
approaches
17.03.2003
Properties Task/problem
Situation
“Solution”
Routine
Known
Known
Problem solving
Known
Unknown
Problem definition
Unknown
Unknown
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
5
Methodology
• Method:
– Experiences in the form of a recipe
– Gives practical advices – how to approach the task
• Methodology: In addition built on a philosophy
• Definition
“A collection of procedures, techniques, tools and documentation aids
which will help the systems developers in their efforts to implement a new
information system. A methodology will consists of phases, themselves
consisting of sub-phases, which will guide the systems developers in their
choice of the techniques that might be appropriate at each stage of the
project and also help them plan, manage, control and evaluate information
systems projects” (Avison and Fitzgerald (2003))
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
6
Objectives of methodologies
• Examples:
– Accurately recording of user needs
– Systematic method for effectively monitoring
of the process
– To provide indications of changes as early as
possible in the process
– Produce a well documented and easy to
maintain IS
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
7
Techniques and tools
• A technique is the doing of a particular
activity
– Elicit user needs
– Describe analytical results
• A technique may involve the use of one or
more tools
– Rational rose to draw UML diagrams
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
8
Software process models
• Process model:
“Determine the order of the phases/stages
involved in a software development process
and establish the transition criteria for
progressing from one stage to the next”
• The wrong order of phases can jeopardize
a project
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
9
Different process models
• Ad-hoc and native process model
• Specification/documentation driven
process model
• Implementation/representation driven
process model
• Risk driven process model
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
10
Why different models?
• Evolution – maturization
• Experiences with failures
• Historical development
• More sophisticated tools
• From only appreciation only the programmer to
also include analysts and designers
• Changing relation between users and developers
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
11
Process models
Code and fix
• Write some code
• Fix the problems in the code
• Requirement, design, test and maintenance at later
stage – and after system in use
• Primary/fundamental problems
– Unstructured code after multiple changes makes changes very
expensive: Design is needed before coding
– Poor match with user needs: Requirements eliciting is needed
before design
– Expensive fixing because of poor preparation for testing and
modification: Preparation is needed
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
12
Process models II
Stagewise
• Stagewise models
– To meet the problems of codeand-fix by introducing
successive stages, as for
example:
– The Waterfall model (1970)
with two enhancements to the
stagewise model:
• Feedback loops, but only to
successive stages
– Primary/fundamental problems
• Documents as completion
criteria for early requirement
and design phases –
elaborated documents for
poorly understood usages:
Stages are pursued in the
wrong order
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
13
Process models III
Evolution
• To meet the problems of the stagewise models
– By expanding increments of operational software
directed by operational experience
• Primary/fundamental problems
– Difficult to distinguish from the code-and-fix model
– It is difficult to follow any evolutionary path due to
interdependencies
– Stages are pursued in the wrong order, as much hard
to change code is developed before
interdependencies are taken care of
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
14
Process models IV
Spiral model
• A general and pragmatic model
• Each cycle is basically identical
1. Identification of objectives of the
product, alternative means of
implementation and constraints imposed
2. Evaluate the alternatives of 1, and
identify uncertainty and plan how to
solve them
3. Develop
4. Plan next cycle
• Allows a varying degree of
completeness, formality and granularity
of specifications
• Primary/fundamental problems
• Best suited for in-house development
• A great reliance on risk management
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
15
Risk management
• Identify risk items
• Plan how to resolve each risk, and
maintain a list as the project proceeds
• Initiate appropriate corrective actions
Effects/
Consequences
Probability
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
16
A Mixed approach
• Complexity:
– The amount of relevant and available information for making
design decisions
• Uncertainty:
– The availability and reliability of other information that could be
relevant
• Abstraction and decomposition to reduce complexity:
Specifying
• Prototypes to reduce uncertainty
• Combination of analytical and experimental approaches
to handle both complexity and uncertainty
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
17
The experiments
• Students at UCLA and AU
• Simple functionality, uncertain GUI
• Rated after functionality, robustness, ease of
use, ease of learning
17.03.2003
Specifying
Prototyping
Mixed approach
Functionality
+
-
+
Robustness
+
-
+
Ease of use
-
+
+
Ease of learning
-
+
+
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
18
Mixed approach II
• Specification: Analytical mode of operation
–
–
–
–
Abstraction to reduce complexity
Relies on available and reliable information
Simplification
No possibility for user to learn about the system
• Prototypes: Experimental mode of operation
– Meets some of the limitation of specification
– But communication and involvement of users gives
raise to other challenges as more information
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
19
Mixed approach III
• Mode of operation:
– Analytical (simplifying by abstraction)
– Experimental (generating information by learning)
• Means of expression:
– Specification (abstract description)
– Prototypes (concrete behavior)
• Complexity and uncertainty are not independent
– Analytic approach introduces new uncertainties by
simplification of the world
– Experiments produces information introducing new
sources of complexity
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
20
Principle of limited reduction
Experimental
and prototyping
Uncertainty
Analytical
and specifying
Complexity
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
21
Mixed approach IV
Analytical
Mode of Operation
Approach
Experimental
Specifications
Means of expression
Prototypes
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
22
Mixed approach V
• The Principle of limited reduction:
“Relying on analytical behavior to reduce complexity introduces
new sources of uncertainty requiring experimental countermeasures.
Correspondingly, relying on experimental behavior to reduce
uncertainty introduces new sources of complexity requiring analytical
countermeasures.” (pp. 69)
• Means of expression require a certain mixture of
analytical and experimental approach
– Plans are analytical countermeasures to an
experimental approach based on prototypes
– Quality assurance as walkthroughs are experimental
countermeasures to an analytical approach
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
23
Methodology in practice
• The concepts underpinning most methodologies
origins from the 1967 – 1977 (prototyping,
stagewise, user-participation)
• Most methodologies favors large-scale
development, with a long development time – in
conflict with continuous change and focus on
short term requirements of the market
• Survey, 776 named individuals in different
organizations “who were likely to be directly
involved or responsible for system development”
(Fitzgerald 1998 and 2000)
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
24
Methodology usage in practice II
• Type of projects:
47
Per cent development inhouse
40
Per cent development
outsourced
Per cent
use/customisation of
packages
13
• Average number of developers: 3.47
• Average duration (in months): 5.72
17.03.2003
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
25
Methodology usage in practice III
Profile of current development environment
Organizations not using
any methodology
Organizations using a
formalised commercial
methodology
14
12
14
17.03.2003
60
Organizations using
internal methodology
based on a commercial
one
Organizations using
internal methodology not
based on a commercial
one
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
26
Methodology usage in practice IV
Average percentage of development time allocated to
development activities
35
30
25
20
Using methodology
Not using methodology
15
10
5
17.03.2003
O
th
er
Sy
st
em
Sy s p
la
st
e m nn
in
s
g
Sy ana
ly
st
sis
em
s
de
sig
Pr
og
n
ra
m
m
in
g
Te
st
in
In
g
st
al
la
t
Ev ion
al
ua
tio
n
0
Petter Nielsen (pnielsen@ifi.uio.no)
Information Systems/IFI/UiO
27