Alternative approaches to
system development
Knut H. Rolland
Dept. of informatics
University of Oslo
©Knut H. Rolland 2002
Slide 1
Overview
●
●
●
Prototyping (Budde et al.);
Mixed approaches: spiral model (Bohem;
Mathiassen et al.)
Complexity and uncertainty (Mathiassen
et al.)
©Knut H. Rolland 2002
Slide 2
Why process models?
●
●
Determine the order of stages
Transition criteria for proceeding from one
stage to the next
•
•
●
●
●
●
What shall we do next?
How long shall we continue doing it?
Not the same as a method
Software development is a complex activity to
organize
Guidance on the order of the different tasks
Is there a need for alternative ways to software
development?
©Knut H. Rolland 2002
Slide 3
Software crisis? New challenges?
●
●
●
Only 16% of software projects are successful
53% of software projects exceeds their budget with over
189%
The aging “software plant”
•
●
Today’s software systems are not build from scratch
•
•
●
●
legacy systems
software components & architectures (COM)
Level of integration
•
•
•
●
even the smallest modification can cause the entire system to fail
(Ex: NSB created an ‘Y2001 problem’)
Internet technologies
interfaces to existing systems (Intranets, ERPs)
e-Commerce
Global diversity
Level of interaction
•
interactive web applications; groupware
©Knut H. Rolland 2002
Slide 4
Traditional models
●
Highly focused on planning
•
•
●
Engineering view
•
•
•
●
Business and strategy planning in the 1950s
Rational decision making processes
Software development deals with ‘hard problems’
Assume that problems are known and clearly defined
‘Divide and Conquer’
Transition criteria
•
•
Code-driven
Document-driven
©Knut H. Rolland 2002
Slide 5
Lessons...
●
●
●
●
Requirements do not become apparent
until a system is in use;
Specifications are seldom completed
during analysis;
Users and developers must learn from
each other;
Flexibility...
©Knut H. Rolland 2002
Slide 6
Experimental methods
●
Prototyping
•
●
●
●
●
●
●
1970s, Smalltalk and Prolog, interactive environments
Not the first specimen of a a large series of
products;
A prototype should demonstrate in practical
use features of the system and not a simulation
of it;
Based on an evolutionary view of software
development;
Produce early working versions;
Provides a communication basis;
Software development as a learning process
©Knut H. Rolland 2002
Slide 7
Types
●
Prototype proper
•
•
•
●
A breadboard
•
•
●
constructed in parallel with the domain model;
to clarify the problem at hand;
user-interface or part of the functionality;
to help clarify construction-related questions;
derived from the specification or model;
A pilot system
•
part of the finished system;
©Knut H. Rolland 2002
Slide 8
Different aspects of prototyping
●
●
●
●
●
A “tangible” idea of the problem solution;
Early evaluation;
Executable specification - better
understanding of the problem domain;
Technical feasibility of the system
design;
Giving the users a “foretaste”.
©Knut H. Rolland 2002
Slide 9
Horizontal vs. vertical
●
Horizontal prototyping
•
●
specific layers of the system are built (e.g. user
interface)
Vertical prototyping
•
•
a selected part of the target system is fully developed
appropriate when building a pilot
©Knut H. Rolland 2002
Slide 10
The spiral model
●
Background
•
•
●
based on experience with various refinements of the
waterfall model in large government projects;
combination of other models;
Features
•
•
•
•
Reducing uncertainties through a risk management
approach to systems development.
not detailed specifications before high-risk elements
of the design has stabilized;
prototyping as risk-reduction at any stage;
detail is not necessary unless the absence of such
detail jeopardizes the project;
©Knut H. Rolland 2002
Slide 11
“Stages”
●
●
●
●
Determine objectives, alternatives,
constrains;
Evaluate alternatives, identify and
resolve risks;
Develop, verify next-level product;
Plan next phases;
©Knut H. Rolland 2002
Slide 12
A typical cycle I
●
Each cycle begins with identification of
•
•
•
the objectives (performance, functionality, ability to
accommodate change...)
the alternative means of implementing the product
(design A, design B, buy product..)
the constrains imposed on the application of the
alternatives (cost, schedule...)
©Knut H. Rolland 2002
Slide 13
A typical cycle II
●
●
●
The spiral gets started by a hypothesis
that a particular operational mission
could be improved by a software effort
The spiral process involves a test of the
hypothesis - if it fails the spiral is
terminated
Each cycle is completed with a review
which covers all products (plans,
software, manning...)
©Knut H. Rolland 2002
Slide 14
Risk management (Bohem)
●
1.
2.
3.
4.
5.
The “situation” is presented as a list of
risks:
Identify the project’s top 10 risk items;
Present plan for resolving each risk item;
Update list of top risk items, plan, and
results monthly;
Highlight risk-item status in monthly
project reviews;
Initiate appropriate corrective actions.
©Knut H. Rolland 2002
Slide 15
Risk management - analysis
Effects of risk
Catastrophic
Serious
Tolerable
Insignificant
Probability of risk
Very low Low
Moderate High
Very high
(<10%)
(10-25%) (25-50%) (50-75%) (>75%)
©Knut H. Rolland 2002
Slide 16
Action...
●
Select an appropriate model according to
the “risk” situation, for example:
•
•
•
high risk in budget and schedule predictability and
control -> waterfall
requirements stable, presence of errors constitutes a
high risk -> detailed specifications
high risk in getting the wrong GUI -> prototyping,
evolutionary model
©Knut H. Rolland 2002
Slide 17
Advantages (Bohem)
●
●
●
It focuses on eliminating errors and
unattractive alternatives early;
Can be used for both re-designs and new
designs;
It provides a viable framework for
integrated hardware-software system
development;
©Knut H. Rolland 2002
Slide 18
Critique...
●
●
●
●
●
Too rational approach to risk
management and decision making;
New kinds of risks can be introduced
through prototyping, new techniques
etc.
Ignores the political context of software
development (e.g. list of risks have to be
legitimated in the focal organization)
Risks are part of the phenomena, not
something that can be eliminated.
Risks also mean opportunities.
©Knut H. Rolland 2002
Slide 19
Mathiassen et al.’s approach.
●
●
●
Systems development always involves
paradoxes;
Uncertainty (risk) always related to
complexity in systems development;
Complexity
•
•
●
amount of relevant information that is available for
making design decisions
abstraction and decomposition
Uncertainty
•
•
availability and reliability of the information used for
making design decisions
prototyping, alternative models
©Knut H. Rolland 2002
Slide 20
The UCLS experiments (1984)
●
●
7 student teams developed an interactive
system for supporting the COCOMO software
cost estimation model
4 teams -> specifying approach (waterfall)
•
•
●
3 teams -> prototyping approach
•
•
●
rated high on functionality and robustness
lower on ease of use and ease of learning
40% less code, 45% less effort
lower on functionality and robustness
Each approach focuses only on some of the
properties that characterize software of high
quality; Specifying and prototyping seem to
complement each other!!
©Knut H. Rolland 2002
Slide 21
New experiments… (Mathiassen)
●
●
●
●
●
●
Must be interpreted and adapted to the specific
conditions of the project
Supported the teams in distributing the effort more
evenly over phases
Difficult to use the model to manage time resources
during the project
Risk analysis was mainly based on intuition and
experience
During risk management, new risks were identified and
the conception of the original risks was modified
The model is a misleading metaphor for development necessary to initiate parallel spirals to deal with
emerging problems
©Knut H. Rolland 2002
Slide 22
Characteristics...
Complexity
Situation
Uncertainty
Low
High
Low
High
Analytical
Mode of operation
Experimental
Approach
Means of expression
Specifications
Prototypes
©Knut H. Rolland 2002
Slide 23
Complexity & Uncertainty revisited
●
●
●
●
Complexity and uncertainty are closely related
Behaving in an analytic way -> introduces new
sources of uncertainty
Behaving in an experimental way -> produces
new information, thereby increasing complexity
Complexity or uncertainty in software
development cannot be reduced without
affecting the other
©Knut H. Rolland 2002
Slide 24
The principle of limited reduction
●
Relying on analytical behaviour to
reduce complexity introduces new
sources of uncertainty requiring
experimental countermeasures.
Correspondingly, relying on
experimental behaviour to reduce
uncertainty introduces new sources of
complexity requiring analytical
countermeasures.
©Knut H. Rolland 2002
Slide 25