Deliverable D4X STASIS Development Process - CORDIS

Project FP6-2005-IST-5-034980
STASIS

SofTware for Ambient Semantic Interoperable Services

Deliverable D4X
STASIS Development Process

Workpackage WP5 – Development Process

Version 1.0 Date May 4th, 2009 Classification Public Status STASIS
V. 1.0

Abstract

STASIS (SofTware for Ambient Semantic Interoperable Services) is a Research and Development project sponsored
under the Europeans Commission’s 6th Framework programme as well as its projects members – www.stasis-project.net.
Its objective is for Research, Development and Validation of open, webServices based, distributed semantic services for
SME empowerment within the Automotive, Furniture and other sectors. It commenced September 1st 2006 and lasts for
3 years until August 2009 with a total budget of €4M. 12 Partners are involved including Commercial Companies (TIE,
iSoft) Academics (Universities of Sunderland, Oldenburg, Modena & Reggio Emilia, Tsinghua) and User Organisations
(AIDIMA, Mariner, Shanghai Sunline, Foton, TANET, ZF Friedrichshafen AG) and these are led by the managing partner
TIE. Partners are spread across Europe and China.

This document describes the development process that has been implemented in STASIS project. The purpose of this
document is to act as a reference for the EU projects’ coordinators and integrators in order to foster a visibility within their
projects and thus increase productivity of distributed teams. Although, the documents is targeted at addressing the needs
of coordinators of EU projects that involve reasonable amounts of software development, its principles are generic
enough to be applied in other types of projects and domains.

This deliverable is an informal deliverable that won’t be officially reviewed. It has been created on a voluntary basis in
order to share project experience and following a recommendation from the project reviewers.

Authors TIE, ir. Vadim Chepegin

Project partially funded by the European Commission
as part of the Information Society Technologies (IST)

Programme

D4X : STASIS Development Process

Executive Summary

This document describes the developments process that was adopted and
evolved within STASIS project. The goal of this document is to share lessons
learnt during an implementation of full-fledged STASIS prototype by a
distributed team whose members represent various software houses and
universities across Europe and in China.
This deliverable is an informal deliverable that won’t be officially reviewed. It has
been created on a voluntary basis in order to share project experience and
following a recommendation from the project reviewers.

2

D4X : STASIS Development Process

STASIS PARTNERS

3

D4X : STASIS Development Process

Table of Contents

1 BACKGROUND .................................................................................................................... 5
1.1 STASIS Project .......................................................................................................... 5
1.2 Deliverable purpose, scope and context.................................................................... 5
1.3 Audience .................................................................................................................... 5
1.4 References................................................................................................................. 6

2 PROCESS DESCRIPTION .................................................................................................. 7
3 CONCLUSIONS AND FURTHER STEPS.......................................................................... 14

4

D4X : STASIS Development Process

1 Background

The purpose of this section is to introduce the:

• STASIS Project
• Purpose, scope and context of this deliverable
• Intended audience for the deliverable
• External References

1.1 STASIS Project

STASIS (SofTware for Ambient Semantic Interoperable Services) is a Research
and Development project sponsored under the Europeans Commission’s 6th
Framework programme. Its objective is for Research, Development and
Validation of open, webServices based, distributed semantic services for SME
empowerment within the Automotive, Furniture and other sectors. It
commenced September 1st 2006 and lasts for 3 years until August 2009 with a
total budget of €4M. 12 Partners are involved including Commercial Companies
(TIE, iSOFT) Academics (Universities of Sunderland, Oldenburg, Modena &
Reggio Emilia, Tsinghua) and User Organisations (AIDIMA, Mariner, Shanghai
Sunline, Foton, TANET, ZF Friedrichshafen AG) and these are led by the
managing partner TIE. Partners are distributed across Europe and China.

1.2 Deliverable purpose, scope and context

This deliverable aims in capturing and sharing an experience gained with a
deployment of an agile development process in the STASIS project. The
purpose of this document is to act as a reference for the EU projects’
coordinators and integrators in order to foster a visibility within their projects and
thus increase productivity of distributed teams. Although, first of all targeted to
other EU coordinators of projects that involve reasonable amount of software
development, its principles are generic enough to be applied in other types of
projects and domains.

This deliverable is an informal deliverable that won’t be officially reviewed. It has
been created on a voluntary basis in order to share project experience and
following a recommendation from the project reviewers

1.3 Audience

The intended audience includes:

• Coordinators, integrators, project managers of large scale EU projects
conducted under the umbrella of Framework Programmes

• Representatives of customers in software projects

5

D4X : STASIS Development Process

1.4 References

The list of recommended literature that compliments this report includes the
following items:
1. Agile Project Management with Scrum (Microsoft Professional), Ken

Schwaber, Microsoft Press, 2004, 192 pages
2. The Rational Unified Process: An Introduction. 3rd ed.; Philippe Kruchten,

Addison-Wesley, 2007, 310 pages
3. Extreme Programming: A gentle introduction.

http://www.extremeprogramming.org/
4. Continuous Integration by Martin Fowler

http://www.martinfowler.com/articles/continuousIntegration.html

6

D4X : STASIS Development Process

2 Process Description

STASIS is a large research and development project supported under the
Europeans Commission’s 6th Framework programme. From an organizational
perspective STASIS’ 12 partners span many European countries with three
partners located in China. Thus, the development team was extremely virtual,
where different sub-teams and even some team members were working
remotely.

In order to facilitate a visibility of a progress and improve a performance of the
whole virtual team, the STASIS project coordinator and development lead
decided to introduce an agile development process. This type of process has a
strong focus on people and communication which was a vital component for a
success in a research and development project conducted by a distributed and
dispersed team which had no strict hierarchy.

From the very beginning, the consortium shared an understanding of the
important value of a common vision. The shared understanding was
crystallised during face to face meetings, follow-up emails and conference calls
and then documented as a consortium internal vision document.

In the next steps a functional specification was of course put in place before a
development phase. Although, it did not go into every single detail and left
freedom for research, it defined a framework for the whole team. These are of
course vital steps to make especially when the team is not located at one place
and every partner has its own goals, preferences and vision.

During a course of the project these documents were used as references and
guidelines that helped to keep the whole consortium up to speed and on the
right track. Thus, independently of the development process an experience
proved yet another time that a set of documents that capture common views on
the project and define certain directions is essential for the complete success.

Then all users’ functional requirements were translated into user stories, which
formed a so called product backlog. User story is short description of a
requirement formulated in a business language understandable and valuable for
a user. For example it might be as following “It is necessary to import
Interchange files into the STASIS application.”

The whole project was divided into time boxed frames of development called
sprints or iterations. The initial time for iteration was fixed as one month then
reduced to 2 weeks and finally became one week. This change was made
based on the observations over the project flow and as such differentiated from
a standard SCRUM approach which prescribed to keep a length of iteration a
constant. When iterations were reasonably long it gave too much room for
deviation from the major course and problems were hidden until it was much
harder to deal with them. Thus, iterations were reduced in several steps to one
week and weekly synchronisation teleconferences were set up. Each sub-team

7

D4X : STASIS Development Process

was encouraged to have a short daily (up to 10-15 minutes) stand up meeting
where all team members got a chance to share with others their progress, plans
and concerns. Weekly and daily meetings/teleconferences fostered visibility of
progress among developers and helped in discovering potential show stoppers
sooner.

In order to support developers with feedback and a vision of the overall
business objectives of the project a special role of “user’s representative” was
introduced. The role was played by one of the initiators and visionary of the
project with years of experience in the domain area. It is necessary to
emphasize this fact since often research and development projects tend to
deviate from the planned course and go into depth without delivering a
complete picture, even if just a high level one, and then fall apart and fail. A
person with clear understanding the business case can help in cutting off some
of the deviations to ensure the delivery of a full product work flow. This is not to
say that going into depth in specific research topics is not valuable. It is other
way around, because a tangible and complete result leverages future research
in the specific areas providing a test case and pointing out to the gaps.

A contact with a larger group of users represented in the project by partners
from the furniture and automotive industry was established through regular
deliverables of STASIS desktop application prototypes. Users could download
them, install on their system and work with them. Developers tutored the users
through the software and in many cases made use of current technology to offer
support through remote systems such as Netviewer and Skype. At the
beginning, there were some frustrations as the users were expecting close to
full functionality of the software only to find many features missing. But, of
course, the software was still very much in the development phase and user
input was crucial at an early stage to avoid costly development of functions and
features that could not be required or incorrectly conveyed by the users.

Hence, the feedback loop was established. It was performed via a centralised
Internet based system where all users could log their findings and developers
could pick up and resolve the most important ones. A Wiki was used as a
centralised bug filing system. Although it did not support any process flow
users found it easy to use and sufficient enough for the given context.

Initially, it was a planned to deliver one runnable prototype per month. The
prototype was built manually by a dedicated experienced Java developer and it
took sometimes up to 16 hours because code packages developed during one
month by different partners could have serious incompatibilities, e.g. different
versions of libraries, different configurations, etc. Such a problem never
reoccurred since one week iterations were put at place. Moreover, now an
automatic build and integration process is triggered many times per day by
using the Hudson (https://hudson.dev.java.net/) build system as described
below. Users can always have the latest build on the known Internet web site,
or can trigger a build, and developers are free of this routine but time
consuming task.

8

D4X : STASIS Development Process

At the heart of the development process was an ‘iteration’. At the start of every
iteration a person who played a role of users’ representative for a development
team told which user stories should be implemented during the next iteration
based on their vision and experience in the problem domain. When a user
representative was selecting stories for the coming iteration the development
team stated how many user stories could really implement based on the stories
complexities, assigned by the most experienced members of the development
team, and team productivity. At the beginning of the project team’s productivity
was not known yet, thus team leads made educated guesses based on their
expert knowledge about used technologies and team member’s capabilities.
After that, developers selected stories that looked the most interesting for them
and the iteration had begun. They broke down a story into more technical and
specific tasks that would not take much more than 24 hours to accomplish
otherwise it had to be split out into several tasks. This schema worked very well
since it demonstrated a trust in developers and motivated them by leaving the
technical problems fully for them and allowed the selection of the most
interesting stories from their perspective.
Thus, an overall process could be visualized as following (see fig. 1).

Figure 1. STASIS development process overview (adapted from [1])
As was already mentioned before, at the initial stage of the project it was
important to meet personally and develop a common ground for the further
work. And during a course of a project live face to face meetings cannot be fully
substituted by other means of communication. Thus, the consortium planned,
budgeted and organized several such events. Those meetings helped to iron
out some potential problems on the early stages including some personality and
work conflicts

9

D4X : STASIS Development Process

An overview of the main characteristics of development process is represented
in table 1.

Table 1. STASIS agile development process features

Factor Implementation

Time frames Weekly sprints

Granularity of monitored Task Based

development units

Test procedure Weekly Tests and Bug-Checking phase

when developers report progress of bug

fixing back to the Wiki

Task granularity Between 2 and 24 hours

Integration procedure and build The newest build ready at any moment of

time

Tools to support a process XPlanner, Mylyn, Hudson, Wiki

Other tools in use SubVersion, Sonar

And now it is a good time to reveal some of the tools that were already
mentioned and which supported the process and helped keeping track on it.
The Wiki was already introduced before as a place for registering bugs. But a
major role of controlling iterations and builds were delegated to XPlanner
(http://www.xplanner.org/). Of course, a big advantage of it was that it was free
of charge. There were more tools on the market, which were more user
friendly, with more functionality, etc. However, XPlanner supports all the main
required functions and was pretty easy to use immediately (see fig. 2).

Figure 2. Example of STASIS sprint information with user stories in XPlanner

10

D4X : STASIS Development Process

The whole project backlog was maintained in a “Master iteration”. Master
iteration was a place holder for all user stories to be implemented for the
project. User representatives together with leads of developers were moving
user stories to the new sprint during a planning phase of every sprint. This
formed an iteration backlog with all user stories that should be finished during a
current iteration. If developer finished all his user stories they could go and pick
more from a master iteration which improved their personal velocity, i.e.
productivity, which became visible through reports generated by XPlanner.
This way, process and supportive software encourages a positive spirit of a
competition and gives an extra motivation for the team members through
involving them into a game environment.
A very important part of the whole process was a continuous integration. As
were mentioned earlier, the project coordinator found unsatisfactory and
inefficient an approach when builds were created only once per month with
involvement of costly human resources for reasonable amount of time.
Following the best practices established in a software industry an automated
build environment was set up based on free Hudson continuous integration
engine (see fig. 3). It automatically triggers builds if code based located at one
centralised SubVersion (http://subversion.tigris.org/) server was changed. Build
process consists of a number of steps and among others it is necessary to
emphasize a step on which all unit and integration tests were performed. If any
single test failed the person(s) who checked in code after the last successful
build got notified and had to react immediately by fixing a problem.

Figure 3. Hudson performing a build of STASIS desktop application

11

D4X : STASIS Development Process

Every developer was asked to commit to and check out from SubVersion server
at least once per day. This procedure ensure that everybody is working on the
latest code base and in case of build failure it was easier to track the problem
right after it was introduced.
Eclipse (http://www.eclipse.org/) was used as a main development environment.
It is a very popular free Integrated Development Environment (IDE). STASIS
made use of its Java part. And also STASIS desktop application was built using
Eclipse Rich Client Platform (RCP). In order to simplify a task of registering
hours for developers a special software was used, namely Mylyn
(http://www.eclipse.org/mylyn/). Mylyn is an Eclipse plug-in with the main goal
of creation of “a task-focused interface for Eclipse that reduces information
overload and makes multi-tasking easy.” Besides having a great value for the
developers by itself, it allowed the automatic tracking time a developer spent on
a certain task and synchronized it with XPlanner server (see fig. 4).

Figure 4. Mylyn allows automatic hours tracking and synchronisation with
XPlanner

One of the complaints from developers when XPlanner was originally
introduced to the team was that it required extra efforts for booking hours.
Mylyn helped to dismiss this concern and added a flavour of task centred
environment to Eclipse.
At the end it is worth to mention one more tool that was not used in STASIS but
proved it usefulness in other projects. Sonar (http://sonar.codehaus.org/) allows
controlling quality of a project code base (see fig. 5).

12

D4X : STASIS Development Process

Figure 5. Usage of Sonar for measuring quality of a code base
It applies more than 300 different approaches accepted by industry to measure
code quality and then visualises them in a user friendly way. It helps in keeping
a quality on a certain high level.

13

3 Conclusions and Further Steps

To conclude, in the sole of all agile techniques and processes is a spirit of
search and adaptation. Every team can start with some form of agile process
but then it should plant and grow up its own process which is unique and
suitable solely for it. Although, it is an art, the recommendations gained from
literature and experience can help a lot and save many hours and negative
emotions of participants. STASIS team learnt its lessons and hopefully they will
be of use for new practitioners.
The development process implemented within the STASIS project proved its
efficiency against several benchmarks including user acceptance test for
produced software (STASIS desktop application) and reviewers’ evaluation
passed which was always positive. The overall approach and tools selection
have proven to be a very good base for the development process of a
distributed team. Thus, an important part of the development process is
sensible to be offered to other projects.
The practical benefits included:
• Improved team collaboration and commitment of team members
• Improved visibility and transparency of a development process
• Increased effectiveness of team
• Improved early detection of problems
Further work in this direction includes investigation of social networking
software to promote communications among dispersed team members and
structure them in an efficient, unobtrusive manner

Project partially funded by the European Commission
as part of the Information Society Technologies (IST)

Programme