offers extra value to the user that can be assessed to influence the next implementation phase. As work
progresses, the initial goal may change, affecting the direction of development accordingly. The principles of
the approach are summarised as [8]: x Deliver something to a real end user.
x Measure the added-value to the user in all critical
dimensions. x Adjust both design and objectives based on
observed realities. Unfortunately Gilb gives little indication of how this
is to be achieved in practice, simply stating that [8]: “Evolutionary delivery is based on iteration towards
clear and measurable objectives. The set of objectives must contain all functional, quality and resource
objectives which are vital to the long-term and short- term survival of the system under development”.
This paper argues for a ‘top-down’ approach to analysis, so that an adequate understanding of the
environment is built up before focusing attention on the computing system or systems. For agile development,
that, in effect, means the use of a D-type analysis in support of a longer-term view of how a computing
system might evolve. SSM is a suitable technique for performing this type of analysis [20, 21]. The next
section summarises its main characteristics, identifying the models it helps to create.
3. Environment Analysis
The need for a thorough context environment analysis is often a neglected area in software practice
and theory [1]. This is probably because the starting point for many analysts is a request for a computing
system, whose purpose seems fairly clear. This is a dangerous assumption, however, and it is safer to
always analyse a new problem situation in reasonable depth even when the context appears familiar [15]. If
the situation is well understood, and the solution obvious, then this analysis can proceed rapidly with
little time lost. However, if it emerges that the situation is more complex than it initially appeared, time and cost
will have been saved overall. These issues are compounded
by the fact that many software
development organisations see themselves as solution- providers rather than problem-solvers.
Soft Systems Methodology SSM [14] is a well- established technique for analysing problem situations,
including the development of information systems [20, 21]. In particular, it helps identify opportunities for
improvement by promoting a greater understanding of a problem situation by all stakeholders. It is especially
helpful in complex ‘messy’ situations—so called ‘soft’ problems. It can be used in support of a goal-driven
approach to change by first establishing a ‘vision’ of what the business could or should be and then
comparing that with the current situation to identify opportunities for improvement.
Traditionally, SSM has been described as a seven- stage process [14], as illustrated in Figure 2.
1. The problem situation: unstructured
2. The problem situation: expressed
3. Root definition of relevant systems
4. Conceptual models
5. Comparison of 4 with 2
6. Definition of feasible desirable
changes 7. Action to solve the
problem or improve the situation
Real world thinking Systems thinking
FINDING OUT
TAKING ACTION
BUILDING MODELS
EVALUATING MODELS
Figure 2: Seven-Stage SSM Model
In SSM, problem situations are usually captured diagrammatically as rich pictures 2. These are
subjective, with no rules defined for drawing them, but they help achieve a shared understanding of a situation
among stakeholders. Based on that understanding, models of ‘relevant systems’ are developed 3. These
are expressed as root definitions and conceptual models. A root definition is a short textual statement that defines
the important elements of the ‘relevant system’ providing a particular perspective on the system under
investigation. In general, each root definition identifies or implies
six particular pieces of information indicated by the mnemonic CATWOE. These elements are described in
Table 1. The ‘Weltanschauung’, or
world-view,
Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems ECBS’06 0-7695-2546-606 20.00 © 2006
IEEE
identifies why a system exists, and the ‘transformation’ indicates what the system does to achieve its purpose.
Conceptual models are derived from root definitions. A conceptual model is a behavioural description
identifying each activity identified or implied in its matching root definition. More specifically, it is a
directed graph with nodes denoting activities and arcs indicating logical dependencies. Conceptual models
provide a basis for further debate on the activities involved. Each activity may help identify where change
is needed. Also, it might be the starting point for further analysis
of the development of specific implementations. They can also form the basis of other
types of model such as dataflow diagrams [22], process models [23], object models [24] and use case models
[25]. Conceptual models are compared with the current real-world situation to identify ‘gaps’ for improvement
5. For each activity, the facilitator can ask: i is this currently conducted ii if so, how; and iii how well?
Change recommendations are then derived from the results 6 and action to improve the situation
undertaken 7.
Table 1: General Components of a Root Definition Components
Meaning
Customers The beneficiaries or victims of a
system Actors
The agents who carry out, or cause to be carried out, the main
activities of the system Transformation
The process by which defined inputs are transformed
into defined outputs
Weltanschauung A viewpoint, framework, image
or purpose, which makes a
particular root definition meaningful
Owner Those who own a system have
the power to close it down Environment
Influences external to a system that affect its operation
One potential disadvantage of using SSM in agile development is that it is traditionally a slow process
[21], designed for effectiveness rather than efficiency. Thus, some streamlining is required. This is considered
briefly in the next section, which examines how SSM and XP might be integrated
4. Integrating XP and SSM
