Aligning computing systems with their en

(1)

Aligning Computing Systems with their Environment: An Agile Perspective

Frank Keenan

and David W. Bustard

Department of Computing and Mathematics, Dundalk Institute of Technology, Ireland

frank.keenan@dkit.ie

School of Information and Software Engineering, University of Ulster, Coleraine, BT52 1SA, UK

dw.bustard@ulster.ac.uk

Abstract

Ideally, all computing systems should be closely aligned to the context in which they are used. Unfortunately, although the increasingly popular agile software development methods attempt to be customer oriented, the practices involved tend to focus more attention on the software product. The purpose of this paper is to examine this imbalance in relation to eXtreme Programming (XP) and suggest how improvements might be achieved through the use of Soft Systems Methodology (SSM). A process is described that combines parts of SSM with XP while still attempting to remain within the general agile philosophy. An example is used to illustrate the process proposed.

1. Introduction

All computing systems operate in a specific context orenvironment. Essentially, an environment is that part of the world that affects or is affected by the computing system. This is the same concept as Jackson’s machine-domain relationship [1]. Ideally, a computing system should be ‘aligned’ with its environment to provide it with optimal support and such alignment should be maintained as circumstances change. In practice, however, this is a weak area in the development of many systems. A recent report from the Royal Academy of Engineering [2], for example, identifies the “lack of a clear link between the project and the organisation’s key strategic priorities” as the most common cause of project failure. This is a longstanding problem, with a survey in 1996 indicating that less than 25% of systems integrated business and technical objectives properly [3].

The underlying issue seems to be that developers spent insufficient time attempting to understand the environment in which a computing system will be used. A recent UK Government report [4], for example, argues that IT practitioners need an understanding of the business and the processes currently employed, if an IT system is to achieve the intended outcome. This weakness is also implied in the third cause of failure

listed in the Royal Academy report [2], namely a “lack of effective engagement with stakeholders.”

The agile approach to software development

recognises this general issue by having ’customer commitment’ as one of its guiding principles, the others being the promotion of individual and group interactions, a focus on the working product, and the ability to respond to change [5]. Agile methods actively involve users in establishing, prioritising, and verifying requirements. This close collaboration, supported by feedback from frequent delivery of software, facilitates the alignment between a computing system and its environment.

eXtreme Programming (XP) [6], the most widely adopted and best documented agile method, was created to address the problems caused by the long development cycles evident in traditional development approaches. Beck describes XP as a lightweight discipline of software development, based on values of simplicity,

communication, feedback, courage, and respect [7]. Recently it has evolved from a fixed set of twelve practices [6] to what is now described [7] as a “process of experimentation and improvement,” with no “given software process that can be pointed to as the one and only definition of Extreme Programming.”

One original key practice of XP was the use of Gilb’s

evolutionarydevelopment method [8] of short releases, which is now represented byincremental deployment in the recent definition [7]. This approach allows systems to be progressively refined from the feedback obtained from each release.

Another original key practice was that of theon-site customer [6], which is now covered by two practices:

real customer involvement andwhole team development [7]. An expectation of the person in the customer role is that they will use their knowledge of the environment to ensure that what is developed is linked to the context in which it will be used.

Various difficulties have been reported with the XP approach, in general, and the customer role, in particular. One is that the XP process begins at the

requirements specificationphase, with no suggestion of any pre-specification analysis activities [7, 9]. Also, it encourages a focus on short-term product development,

(2)

emphasized by the YAGNI mantra (You Aren’t Going to Need It). This discourages a consideration of longer-term business strategy or a detailed analysis of the business context, which is typically more complex than it appears initially. The recent version of XP has begun to acknowledge the importance of wider issues by including the quarterly cycle practice, concerned with checking on “alignment with larger goals” and taking account of the “big picture” as progress is made.

The essential problem is that there are few guidelines on the implementation of the customer role to suggest how interaction with developers should occur. In particular, it is unclear what models or system

descriptions should be used to build a shared

understanding of both the problem situation and the computing solution being proposed. Various authors

have offered advice. Jepsen [10], for example,

recommends spending a great deal of time and energy in investigating contrasting stakeholder viewpoints in complex situations to help in “understanding the business” [11]. Stephens and Rosenberg also highlight the value of spending time ‘up front’ with as many customer representatives as possible and exhorting developers to “get down into the trenches and find out the real problems that need to be solved” [12]. Van Deursen [13] similarly identifies benefit for the customer representative in having “systematic ways for diagnosing problem situations,” which again means analysing the environment adequately. Without this activity, an XP project can become too inwardly focused.

The purpose of this paper is to propose a systematic way of analysing an environment in support of agile development. It starts by examining the concept of

alignment between a computing system and its

environment. This is followed by a brief summary of Soft Systems Methodology (SSM) [14], a general technique for analysing any situation considered problematic. The final sections suggest how the process and models of SSM might be linked to XP to better define the customer role, which also helps to improve the match between the computing system produced and the context in which it will be used. This is supported with the use of an example.

2. Computing-Environment Alignment

Jackson argues that when tackling new projects it is important to understand the problem domain adequately

before focusing on the solution, because the

requirements are effectively determined by this

environment [15]. The objective of analysing a problem situation is to (i) understand the context in which there appears to be a need for the creation or modification a computing system; and (ii) define a basic course of action. For ongoing development, both the context and

required action may be well established but it is still desirable to ensure that there have been no significant changes since the previous analysis was undertaken. Also, the analyst may be new to the project and require some time to appreciate the arguments in that analysis.

Figure 1 shows a representation of an evolving computing system and its corresponding environment. The arrow between each system version and its environment implies that they are ‘aligned’ [16, 17]. That is, ideally, the computing system provides optimal support for the environment in which it is used and this alignment is maintained as the situation evolves.

Analysis can either be (i)goal-oriented, developing a vision or target of what the computing system and its aligned environment could or should become, or (ii)

problem-oriented, focusing on current shortcomings (or opportunities) and determining how they might be addressed. Also, analysis can betop-down, starting with an environment analysis, or bottom-up, with a focus on the computing system to be produced [18].

…

Environment

Computing System

Environment

Computing System

Environment

Computing System

A C

Current Target

Figure 1. System Co-Evolution Model

Four different starting points for system analysis are identified in the diagram [18]:

x A-type analysis is the classic product-focused approach to software development. Here, the environment is mainly understood in terms of its relevance to the computing system and the functions it provides.

x B-type analysis is the traditional ‘information systems’ approach, involving the analysis and modelling of the environment to provide a context for identifying system requirements.

x C-type analysis helps develop a long-term vision of what the software could or should become. Implementation steps are then defined to advance the system in that direction.

x D-type analysis first develops a long-term vision of the computing system environment, which is then used to determine environment changes as well as identify desirable supporting technology and its implementation steps.

One well-known example to C-type analysis is Gilb’s Evolutionary Delivery method [8]. This has been adopted as a key practice of XP and is a core aspect of agile development, in general [19]. Each delivery step

(3)

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

(4)

identifieswhy a system exists, and the ‘transformation’ indicateswhatthe system does to achieve its purpose.

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

In XP, the determination of requirements starts during the Planning Game. The onsite customer is responsible for all ‘business problems’, leaving

developers free to focus on technical decisions [6]. Requirements are elicited from the customer as user stories [26]. These are documented on cards, each of which describes a requirement, its associated acceptance tests, and an estimate of the time and effort needed to implement the requirement. The development team then sorts and prioritises stories by value (cost-benefit) and risk. In the subsequent Release Planning phase, a decision is taken on which stories to include in each release and how the project should be organised overall. Each release is divided into 2-4 week iterations, each of which will complete a number of stories. During development, rescheduling may be necessary if a story cannot be developed on time. This can affect subsequent iterations, and so possibly affect the next release and the wider development plan.

Table 2 summarises a proposal for how SSM and XP might be linked. The first column identifies seven process steps that fall into three phases. The first phase (1-3) covers an initial SSM analysis and the final phase (5-7) deals with XP activities associated with the creation of a Release Plan and User Stories, followed by the detailed definition of iterations and their implementation. In the middle is a bridging phase (4), in which possible computing systems are identified from the SSM models. The Release Plan is based on these systems, taking account of any computing support that exists already.

The second and third columns of Table 2 describe the purpose of each step and the associated outputs. The fourth column is a graphical indication of the focus of each step with respect to the diagram in Figure 1.

For steps 1 to 5 it is likely that the participants will include senior customers, the development team, other customer representatives, and a facilitator. This is consistent with thewhole team practice [7]. In step 6 the senior customers withdraw, leaving their interests to be covered by theon-site customer.

Step 6 generates user stories. As all project participants were involved in the SSM analysis up to that point this step can proceed with more confidence. The starting point is an examination of the activities in the conceptual model that are relevant to the current release. These should provide enough detail to allow the team to elicit and document desirable features. If not, then activity descriptions can be taken down to a lower level of detail.

The stories generated can be linked to future business value and releases. This can be implemented by adding fields to theuser storythat name the release, conceptual model activity and root definition (representing the

goal).

In step 7, iterations are defined and performed. As each iteration is completed, the results can be evaluated with respect to the objectives of the iteration and the

(5)

requirements of the customers. In effect, this ensures alignment with the environment. This analysis will typically influence the next iteration and may trigger adjustments to the Release Plan, the list of possible computing systems, and the higher level SSM models from which they were derived.

To be acceptable to the agile community, the benefit of using of SSM must clearly outweigh its cost. For that reason, the traditional role of SSM in identifying

beneficial changes to the problem situation has been omitted from the steps described, thereby avoiding any unnecessary delay in reaching the analysis of computing needs. Also, additional analysis, such as using business use cases or rich pictures to describe existing processes (consistent with B-type analysis) have been omitted. The next section illustrates the first stages of this linked SSM-XP process using a simple example.

Table 2: The SSM/XP link

Step Purpose Output Focus

Phase 1: SSM Analysis 1. SSM: Express Problem

Situation

Build a shared understanding of the problem situation

Rich Picture diagram

…

2. SSM: Create Root definitions Develop system perspectives of the problem situation (goals)

Root Definitions

…

3. SSM: Derive Conceptual Models

Produce a high level activity model for each root definition

High level Conceptual

Models …

Phase 2: Bridging

4. Identify Possible Computing Systems

Suggest computing systems to support activities in models

Possible computing

systems …

Phase 3: XP Activities

5. XP: Produce Release Plan Compare output from 4 with current computing facilities; prioritise increments of change

Release Plan and

measurable objectives …

6. XP: Create User Stories

For each release

a. Analyse and develop activities

Identify activities associated with the release, expanding to lower level models as necessary

Lower level Conceptual

Models …

b. For each activity

x define user stories

Identify and document features to support each activity

Initial User Stories

…

x define acceptance tests and estimate effort

Define acceptance tests for each feature and estimate

implementation effort required

User Stories with Acceptance Tests and estimates

…

x link models Link each story to root

definition(s) and conceptual model(s)

User Stories with link to

goal and activities …

7. XP: Implement Iterations

Repeat

a. select stories Select stories for the next iteration

and prioritise them

Iteration Plan

…

b.perform iteration Implement iteration, making

adjustments where required

Revised Iteration and

Release Plans …

c. check project focus until no stories

Check that output of the iteration meets expectations

Revised models and

(6)

5. An Example

This section works through sufficient steps of the proposed methodology to explain the SSM-XP linkage. This is illustrated through a fictional project for a pizza restaurant, Pizza Promise, which provides home delivery in its immediate area. It is assumed that the project has been instigated by the owner who is unhappy with the time taken to record customer details given over the telephone and the time wasted during delivery when addresses are not recorded accurately. The owner’s belief is that the situation can be improved by using a computing system to determine address details from a post code and house number, and then using this information to label each customer’s pizza box, thereby reducing effort and the risk of transcription errors.

The requirements here seem well understood but a broader analysis is desirable to anticipate other opportunities for computer use to enhance the business. For example, if customer records are maintained then a loyalty scheme might be introduced to offer discounts to regular customers.

Step1. SSM: Express Problem Situation

In the first step, a rich picture, depicting a shared understanding of the problem under investigation, is developed. A picture for Pizza Promise is presented in Figure 3. This has been simplified for illustration purposes. It shows all the essential elements of the pizza restaurant business, including an indication that pizzas can be ordered over the counter at the restaurant as well as by telephone, and that orders can be collected directly as well as delivered. In a full rich picture for this situation, there would also be an indication of (i) all significant external dependencies, such as the suppliers of raw materials; (ii) other areas of difficulty, such as slow deliveries when the restaurant is busy; and (iii) other possible innovations, such as a lunchtime delivery service for local businesses.

Figure 3: Rich Picture for Pizza Promise Step 2. SSM: Create Root Definitions

From the discussion so far, it is possible to identify several relevant viewpoints of this problem situation. For simplicity, just one will be considered here, namely the central goal of providing a reliable, competitive and convenient food service. The six elements of the SSM CATWOE analysis are shown in Table 3.

A root definition can also be presented as a single statement, of the form:

A Pizza Promise owned system to provide a reliable, competitive and convenient food service to the general public in its surrounding area, using restaurant staff to prepare and deliver ordered pizzas, taking account of the demand for pizza and the external factors affecting its accurate delivery.

Table 3: Sample Root Definition Components Meaning

Customers The general public in the surrounding area

Actors Restaurant staff

Transformation Prepare and deliver ordered pizzas

Weltanschauung Provide a reliable, competitive and convenient food service

Owner Pizza Promise

Environment The demand for pizza; the external factors affecting its accurate delivery

Home Delivery Home

Customers _{(Slow) phone}

Order

Pizza Promise

Direct Collection & Counter Orders Preparation

Computer Use?

(7)

A10: monitor that the restaurant is providing a reliable, competitive & convenient food service, taking

control action as necessary A2: handle

orders

A9: set staffing levels A7: be aware of

external factors affecting service

A8: define expectations for

service

A6: be aware of demand

A5: prepare and deliver ordered

pizzas

TCA

A4: be aware of competition A1: publicise

service

A3 determine charges

Figure 4: Sample Conceptual Model Step 3. SSM: Derive Conceptual Models

Figure 4 shows a conceptual model derived from the root definition described in Table 3. The model includes the transformation taken directly from the root definition (A5). This is essentially the central activity of the model. Another important activity is A10, which monitors that the defined Weltanschauung (viewpoint) is achieved, taking control action if necessary (TCA). This can affect any other activity in the model. Activities are also added to handle the environmental constraints listed in the root definition (A4, A7) and to cover consequential or implied activities (A1, A3, A6, A8, A9).

Step 4. Identify Possible Computing Systems

Possible computing systems can be identified by working systematically through each activity in a conceptual model and noting opportunities for computing support. Each activity may suggest a new system or use a system already noted. Table 4 shows a list of possible systems for Pizza Promise, including a web site for the restaurant.

Table 4: Suggested Systems for Pizza Promise Activity Possible systems

A1. Publicise service Restaurant web site P1: Address System P6: Customer System A2. Handle orders Restaurant web site

P1: Address System

P2: Product Availability System P3: Scheduling System P4: Order System P5: Sales System P6: Customer System A3.Determine charges P5: Sales System

A4. Be aware of competition

A5. Prepare and deliver ordered pizzas

P2: Product Availability System P3: Scheduling System P4: Order System P5: Sales System P6: Customer System P7: Stock Control System A6. Be aware of demand P5: Sales System

A7. Be aware of external factors affecting service

A8: Define expectations for service

P8: Business Monitoring System

A9: Set staffing levels P3: Scheduling System

A10: Monitor effectiveness of service

P4: Order System P5: Sales System P7: Stock Control System P8: Business Monitoring System P9: Customer Feedback System

As a clarification of the suitability and adequacy of these systems it is useful to set them out in a diagram that shows their inter-dependency. Figure 5, for example, suggests the likely relationships among the systems identified in Table 4. The functional details of these systems are not decided until the seventh step in

the development process, which deals with the

(8)

Restaurant Web Site

Customer System

Product Availability

System

Order System Customer Feedback System

Address System

Scheduling System

Business Monitoring

System Sales

System

Stock Control System

Figure 5: Computing System Dependency Model

Steps 5-7. XP: Release Plan, User Stories & Iterations The initial motivation for the project was the restaurant owner’s request for an address lookup system. From the SSM analysis this has emerged as one element of a possible suite of inter-connected systems. The owner at this stage can still settle for that feature alone but will be taking the decision with knowledge of the many more forms of support that could be provided. Through discussion with the owner, a Release Plan can be produced suggesting an order of implementation and the level of sophistication involved in each case. For example, a basic web site might be implemented

immediately, giving information on the services

available, covering opening hours, range of pizzas, and contact information. This can subsequently be expanded to include online ordering when an order system and customer system are being created.

The advantage of having the options laid out in this way is fairly obvious and, importantly, has been achieved with relatively little effort because of the high level of analysis being performed. Much more effort is needed in subsequently determining the detail of the user stories and the definition of individual iterations.

6. Conclusion

In effect, this paper has argued that agile

development methods need a wider environment perspective to appreciate the context into which an individual computing system is to be introduced. That wider appreciation will include an understanding of the other related computing systems that could exist in that

environment and an indication of how these systems might evolve with their environment.

The paper looked specifically at eXtreme Programming and the possibility of supporting it using Soft Systems Methodology in the initial stages of analysis. A methodology for using SSM and XP together was outlined. Essentially, SSM was used to analyse the problem situation in a way that identified a wide range of possible inter-dependent computing systems, linked to the operational processes that they support. The expectation is that this initial alignment between computing systems and their environment would be maintained, through the models created, as computing systems are produced and the environment itself evolves. Overall, the advantage of this approach is that it helps to create a strategic plan for change, reducing the risk of significant reworking.

The value of SSM as a pre-analysis technique for XP shows significant potential but trials of the approach are being undertaken to clarify the importance of a range of issues that are involved. These include the time taken to perform an SSM analysis, the need for tools in supporting the models involved, and the desirability of maintaining related models in an agile context. The effort required by developers to understand SSM up to a usable level and the possibility of tailoring its use in specific contexts are also being examined.

Acknowledgements

The work described in this paper was supported by the Centre for Software Process Technologies (CSPT), funded by Invest NI through the Centres of Excellence Programme and the Staff Development Programme at Dundalk Institute of Technology.

References

[1] Jackson, M., Software Requirements & Specifications, Addison-Wesley, 1995.

[2] Royal Academy of Engineering, British Computer Society, “The Challenges of Complex IT Projects”, April 2004, ISBN 1-903496-15-2.

[3] Clegg C. et al, “The Performance of Information Technology and the Role of Human and Organizational Factors”, Technical Report, Economic and Social Research Council, UK, 1996.

[4] Parlimentary Office of Science and Technology, “Government IT projects”, July 2003.

[5] Cockburn, A., Agile Software Development, Pearson Education, 2002.

[6] Beck K., “Extreme Programming Explained”, Addison Wesley, 1999.

[7] Beck K., Andres C., “Extreme Programming Explained”, Second Edition, Addison Wesley, 2005.

(9)

[8] Gilb, T., “Principles of Software Engineering Management”, Addison Wesley, 1988.

[9] Abrahamsson P., Warsta J, Siponen M., Ronkainen J, “New Directions on Agile Methods: A Comparative Analysis”, ICSE 2003, pp. 244-254.

[10] Jepsen O., “Customer Collaboration – challenges and experiences”, Agile Development Conference, Salt Lake City, 2004.

[11] Thorup L, Jepsen O., “Improving customer developer collaboration”, JAOO 2003, 25/09/03, www.bestbrains.dk/xpvip-jaoo2003-report.html [viewed 16/08/04].

[12] Stephens M., Rosenberg D., “Extreme Programming Refactored: The Case Against XP”, Apress, 2003 [13] van Deursen A., “Customer Involvement in Extreme

Programming”, http://www.cwi.nl/~arie/wci2001/wci-report.pdf, May 2001, pp 1-2, XP2001.

[14] Checkland, P., Systems Thinking, Systems Practice (with 30-year retrospective), John Wiley & Sons, 1999 [15] Jackson M., “Seeing More of the World”, IEEE

Software Nov/Dec 2004, 21(6), pp 83-85.

[16] Boar, B.H., Practical Steps for Aligning Information Technology with Business Strategies: How to Achieve a Competitive Advantage, John Wiley & Sons, 1994. [17] D.W. Bustard, D. Greer, Z. He, P.J. Lundy, R. Oakes,

and F.G. Wilkie, “Developing a Co-Evolutionary Business-IT Change Plan”, in Bustard, D.W., P. Kawalek, and M.T. Norris (eds.), Systems Modelling for Business Process Improvement, Artech House, May 2000, pp. 213-232.

[18] Bustard, D.W. and Keenan, F., Strategies for Systems Analysis: Groundwork for Process Tailoring,

Proceedings of International Conference of Computer Based Systems, Greenbelt, MA, IEEE Computer Society, pp. 357-362, 2005.

[19] Keenan, F., Bustard, D.W., “BPUF: Big Picture Up Front”, International Conference on Extreme Programming and Agile Processes (XP2005), Sheffield, 2005.

[20] Stowell, F.A. (ed.), Information Systems Provision: The Contributions of SSM, McGraw-Hill, London, 1995. [21] Mingers J., Taylor S., “The Use of Soft Systems

Methodology in Practice,” Journal of the Operational Research Society, 43(4), 1992, pp. 321-332.

[22] Bustard, D.W., Oakes, R. and E. Heslin, Support for the Integrated Use of Conceptual and Dataflow Models in Requirements Specification, Colloquium on Requirements for Software Intensive Systems, pp. 37-44, DRA Malvern, 1993.

[23] Bustard, D.W. and P.J. Lundy, Enhancing Soft Systems Analysis with Formal Modelling, IEEE Requirements Engineering Symposium (RE'95), York, pp. 164-171, 1995.

[24] Bustard, D.W., Dobbin T.J. and B. Carey, Integrating Soft Systems and Object Oriented Analysis, IEEE International Conference on Requirements Engineering, Colorado Springs, USA, pp. 52-59, 1996.

[25] Bustard, D.W., He, Z., and F.G. Wilkie, Linking Soft Systems and Use-Case Modelling Through Scenarios, Interacting with Computers, 13, pp. 97-110, 2000. [26] Jeffries J. 2001, “Essential XP: Card, Conversation,

(1)

identifieswhy a system exists, and the ‘transformation’ indicateswhatthe 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

4. Integrating XP and SSM

In XP, the determination of requirements starts during the Planning Game. The onsite customer is responsible for all ‘business problems’, leaving

In step 7, iterations are defined and performed. As each iteration is completed, the results can be evaluated with respect to the objectives of the iteration and the

(2)

To be acceptable to the agile community, the benefit of using of SSM must clearly outweigh its cost. For that reason, the traditional role of SSM in identifying

Table 2: The SSM/XP link

Step Purpose Output Focus

Phase 1: SSM Analysis 1. SSM: Express Problem

Situation

Build a shared understanding of the problem situation

Rich Picture diagram

…

2. SSM: Create Root definitions Develop system perspectives of the problem situation (goals)

Root Definitions

…

3. SSM: Derive Conceptual Models

Produce a high level activity model for each root definition

High level Conceptual

Models …

Phase 2: Bridging

4. Identify Possible Computing Systems

Suggest computing systems to support activities in models

Possible computing

systems …

Phase 3: XP Activities

5. XP: Produce Release Plan Compare output from 4 with current computing facilities; prioritise increments of change

Release Plan and

measurable objectives …

6. XP: Create User Stories For each release

a. Analyse and develop activities

Identify activities associated with the release, expanding to lower level models as necessary

Lower level Conceptual

Models …

b. For each activity

x define user stories

Identify and document features to support each activity

Initial User Stories

…

x define acceptance tests and estimate effort

Define acceptance tests for each feature and estimate

implementation effort required

User Stories with Acceptance Tests and estimates

…

x link models Link each story to root definition(s) and conceptual model(s)

User Stories with link to

goal and activities …

7. XP: Implement Iterations Repeat

a. select stories Select stories for the next iteration and prioritise them

Iteration Plan

…

b.perform iteration Implement iteration, making adjustments where required

Revised Iteration and

Release Plans …

c. check project focus until no stories

Check that output of the iteration meets expectations

Revised models and

(3)

5. An Example

Step1. SSM: Express Problem Situation

Figure 3: Rich Picture for Pizza Promise Step 2. SSM: Create Root Definitions

A root definition can also be presented as a single statement, of the form:

Table 3: Sample Root Definition

Components Meaning

Customers The general public in the surrounding area

Actors Restaurant staff

Transformation Prepare and deliver ordered pizzas

Weltanschauung Provide a reliable, competitive and convenient food service

Owner Pizza Promise

Environment The demand for pizza; the external factors affecting its accurate delivery

Home Delivery Home

Customers _{(Slow) phone}

Order

Pizza Promise

Direct Collection & Counter Orders Preparation

Computer Use?

(4)

A10: monitor that the restaurant is providing a reliable, competitive & convenient food service, taking

control action as necessary A2: handle

orders

A9: set staffing levels A7: be aware of

external factors affecting service

A8: define expectations for

service

A6: be aware of demand

A5: prepare and deliver ordered

pizzas

TCA

A4: be aware of competition A1: publicise

service

A3 determine charges

Figure 4: Sample Conceptual Model Step 3. SSM: Derive Conceptual Models

Step 4. Identify Possible Computing Systems

Table 4: Suggested Systems for Pizza Promise

Activity Possible systems

A1. Publicise service Restaurant web site P1: Address System P6: Customer System A2. Handle orders Restaurant web site

P1: Address System

P2: Product Availability System P3: Scheduling System P4: Order System P5: Sales System P6: Customer System A3.Determine charges P5: Sales System

A4. Be aware of competition

A5. Prepare and deliver ordered pizzas

P2: Product Availability System P3: Scheduling System P4: Order System P5: Sales System P6: Customer System P7: Stock Control System A6. Be aware of demand P5: Sales System A7. Be aware of external

factors affecting service A8: Define expectations for service

P8: Business Monitoring System A9: Set staffing levels P3: Scheduling System

A10: Monitor effectiveness of service

P4: Order System P5: Sales System P7: Stock Control System P8: Business Monitoring System P9: Customer Feedback System As a clarification of the suitability and adequacy of these systems it is useful to set them out in a diagram that shows their inter-dependency. Figure 5, for example, suggests the likely relationships among the systems identified in Table 4. The functional details of these systems are not decided until the seventh step in the development process, which deals with the implementation of XP iterations.

(5)

Restaurant Web Site

Customer System

Product Availability

System

Order System Customer Feedback System

Address System

Scheduling System

Business Monitoring

System Sales

System

Stock Control System

Figure 5: Computing System Dependency Model

Steps 5-7. XP: Release Plan, User Stories & Iterations

The initial motivation for the project was the restaurant owner’s request for an address lookup system. From the SSM analysis this has emerged as one element of a possible suite of inter-connected systems. The owner at this stage can still settle for that feature alone but will be taking the decision with knowledge of the many more forms of support that could be provided. Through discussion with the owner, a Release Plan can be produced suggesting an order of implementation and the level of sophistication involved in each case. For example, a basic web site might be implemented

immediately, giving information on the services

available, covering opening hours, range of pizzas, and contact information. This can subsequently be expanded to include online ordering when an order system and customer system are being created.

6. Conclusion

In effect, this paper has argued that agile

environment and an indication of how these systems might evolve with their environment.

Acknowledgements

References

[1] Jackson, M., Software Requirements & Specifications, Addison-Wesley, 1995.

[2] Royal Academy of Engineering, British Computer Society, “The Challenges of Complex IT Projects”, April 2004, ISBN 1-903496-15-2.

[3] Clegg C. et al, “The Performance of Information Technology and the Role of Human and Organizational Factors”, Technical Report, Economic and Social Research Council, UK, 1996.

[4] Parlimentary Office of Science and Technology, “Government IT projects”, July 2003.

[5] Cockburn, A., Agile Software Development, Pearson Education, 2002.

[6] Beck K., “Extreme Programming Explained”, Addison Wesley, 1999.

[7] Beck K., Andres C., “Extreme Programming Explained”, Second Edition, Addison Wesley, 2005.

(6)

[8] Gilb, T., “Principles of Software Engineering Management”, Addison Wesley, 1988.

[9] Abrahamsson P., Warsta J, Siponen M., Ronkainen J, “New Directions on Agile Methods: A Comparative Analysis”, ICSE 2003, pp. 244-254.

[10] Jepsen O., “Customer Collaboration – challenges and experiences”, Agile Development Conference, Salt Lake City, 2004.

[11] Thorup L, Jepsen O., “Improving customer developer collaboration”, JAOO 2003, 25/09/03, www.bestbrains.dk/xpvip-jaoo2003-report.html [viewed 16/08/04].

[12] Stephens M., Rosenberg D., “Extreme Programming Refactored: The Case Against XP”, Apress, 2003 [13] van Deursen A., “Customer Involvement in Extreme

Programming”, http://www.cwi.nl/~arie/wci2001/wci-report.pdf, May 2001, pp 1-2, XP2001.

[14] Checkland, P., Systems Thinking, Systems Practice (with 30-year retrospective), John Wiley & Sons, 1999 [15] Jackson M., “Seeing More of the World”, IEEE

Software Nov/Dec 2004, 21(6), pp 83-85.

[16] Boar, B.H., Practical Steps for Aligning Information Technology with Business Strategies: How to Achieve a Competitive Advantage, John Wiley & Sons, 1994. [17] D.W. Bustard, D. Greer, Z. He, P.J. Lundy, R. Oakes,

and F.G. Wilkie, “Developing a Co-Evolutionary Business-IT Change Plan”, in Bustard, D.W., P. Kawalek, and M.T. Norris (eds.), Systems Modelling for Business Process Improvement, Artech House, May 2000, pp. 213-232.

[18] Bustard, D.W. and Keenan, F., Strategies for Systems Analysis: Groundwork for Process Tailoring,

Proceedings of International Conference of Computer Based Systems, Greenbelt, MA, IEEE Computer Society, pp. 357-362, 2005.

[19] Keenan, F., Bustard, D.W., “BPUF: Big Picture Up Front”, International Conference on Extreme Programming and Agile Processes (XP2005), Sheffield, 2005.

[20] Stowell, F.A. (ed.), Information Systems Provision: The Contributions of SSM, McGraw-Hill, London, 1995. [21] Mingers J., Taylor S., “The Use of Soft Systems

Methodology in Practice,” Journal of the Operational Research Society, 43(4), 1992, pp. 321-332.

[23] Bustard, D.W. and P.J. Lundy, Enhancing Soft Systems Analysis with Formal Modelling, IEEE Requirements Engineering Symposium (RE'95), York, pp. 164-171, 1995.

[24] Bustard, D.W., Dobbin T.J. and B. Carey, Integrating Soft Systems and Object Oriented Analysis, IEEE International Conference on Requirements Engineering, Colorado Springs, USA, pp. 52-59, 1996.

Aligning computing systems with their en