XP in the Large Applying XP to Large Scale Telecommunication Software Development

taxidermistplateSoftware and s/w Development

Nov 7, 2013 (3 years and 9 months ago)

361 views

XP in the Large


Applying XP to Large Scale
Telecommunication Software Development



Mark Sheppard

Dave Anderson



Logica Mobile Networks

Logica Mobile Networks



5 Customs House Plaza

5 Customs House Plaza



Harbourmaster Place

Harbourmaster Place



D
ublin 1, Ireland

Dublin 1, Ireland



+353
-
1
-
819 2076

+353
-
1
-
819 3573



Mark.Sheppard@LogicaCMG.com

Dave.Anderson@LogicaCMG.com




ABSTRACT

Using an effective and efficient development process can
have a significant impact on a software development
projec
t. Employing a process that is lightweight, flexible
and focused will contribute to the success of a project.
Extreme Programming (XP) and agile development
methodologies have come into vogue in recent years. These
lightweight development methodologies st
rive to guarantee
the delivery of high grade software in a timely manner.
Typically the application of XP has been targeted at small
to medium sized projects. So how does XP scale to a large
high grade product development? We addressed this issue
by means

of a ‘divide and conquer’ approach applying XP
at two levels of project granularity, macroscopically at the
global project level and microscopically at the component
team level. This was augmented by a project level
infrastructure which was designed to p
romote
communications within the global project team. This
process successfully delivered a high quality 3G messaging
system. The contribution of XP to this product
development was significant. Thus we conclude that XP
can be applied to large scale softw
are product development
but not without some level of adaptation.

Keywords

Large Scale, Software Development, Extreme
Programming, Unit testing, Acceptance tests, Iterative
Development, Quality , XP.

1

INTRODUCTION

In today’s highly competitive and fast mov
ing
telecommunications software market place there is a
demand for the timely delivery of high quality product. The
emphasis is on reducing cost and time to market. The need
for effective and efficient software development process is
therefore evident.

Em
ploying a process that is lightweight, flexible and
focused will contribute to the success of a project. Extreme
Programming (XP) and agile development methodologies
have come into vogue in recent years. Their emphasis is on
the timely delivery of quality
software.

About 2
nd

quarter 2001 Logica LMN embarked on the
development of a large scale telecommunications product
for multimedia messaging system targeted at the 3G
market. The emphasis for this development on high quality
both in terms of the system st
ructure and design and in the
levels of testing.

About this time the eXtreme Programming (XP)
methodology was gaining significant attention and
credibility. Logica LMN had used XP on a ‘sub
-
project’
for a year prior to this. The results of this pilot w
ere very
positive and it was deemed that XP was worth using on the
next large scale MMSC development project. This was to
replace the then Logica LMN Cortex process which
followed, in the main, the traditional ‘waterfall’
methodology.

The key drivers for
the adaptation of XP were: initial time
to market, phased releases, quality deliverables, system
evolution, good design practice, functionality adaptability
in an evolutionary product market. It was perceived that XP
could assist in meeting these goals.

2

X
P IN THE LARGE


ADAPTATION AND
EVOLUTION

Typically the essence of XP is based on the scenario that
requirements and functionality are captured in User Stories.
The user stories are reviewed by the developers. After a
conversation or conversations with t
he customer they are
prioritized by the customer. Then the stories are
implemented and delivered over the course of a number of
iterations.

In the MMSC product context there are a number of
potential customers and product management would
usually converse

with them. So an adaptation of the
customer/developer relationship was needed. For this a
number of project stakeholders were identified: Potential
Customers, Product Management, Product Architect team,
Product Development Manager, Product Component team
s,
Product End
-
to
-
End test team, System test team. This
effectively provides you with two virtual teams: Customer

team and Development team. In essence we had a ‘proxy
customer’.

The Architecture team provides an overlap between the two
virtual teams. Thi
s overlap is conceived to assist the
communications process between the two domains and
additionally within the product development teams.

The component team based structure for the overall
development team was used to allow for the practice of XP
in its
purer form at a fine granularity of development. The
End
-
to
-
End test team was put in place to facilitate
component integration and a continuous integration
strategy.

An additional aspects of the adaptation was the introduction
of the Team Story concept. Th
is is to ensure that any team
can work in an XP manner.

The relationship between User Stories and Team Stories is
as follows: A Team Story is associated with exactly one,
unique, User Story. A User Story has one or more Team
Stories. When all the Team Stor
ies associated with a User
Story are complete, then the User Story is complete. A
Team Story requires work from one team only.

Figure 1 shows the relationship between user stories and
teams stories; their corresponding relationship with end
-
to
-
end and

acceptance tests.

validated by
End2EndTest
UserStory
Team
AcceptanceTest
TeamStory
validated by
owned by

Figure 1. User Story, Team Story and Test relationships

Tracking of stories and metrics is necessary in a large
project. An online tools based on Zope [1] was used for
recording User Stories, Team Stories and corresponding
test coverag
e. This kept the administrative overhead to a
minimum.

Thus the adaptation of XP to MMSC product development
project included the following project elements and
artifacts:
Team based component development, User
Stories, Team Stories, Unit testing, Acceptan
ce tests, End
-
to
-
End testing, System tests, Engineering releases,
Iterations, Start of iteration meeting and end of iteration
meeting, Online capture of user and team stories, Online
capture of acceptance tests.

3

EVALUATION AND CONCL
USIONS

The project deliv
ered a high quality MMS within the
expected time frames and with the expected functionality
(as dictated by the customer) and quality. This can be
attributed to the adoption of XP and its adaptation to suit
large scale product development.

Iterative deve
lopment facilitates tractable product
development and project management. The use of unit
tests, extended unit tests, in team acceptance test and end
-
to
-
end testing contributed to high quality software
deliverables.

By using a component team based appro
ach allows XP to
be applied in its purer form at a microscopic level. This
approach together with End
-
to
-
End testing produced a very
usable and effective development process.

Continuous integration is an integral part of XP. Regular
integration testing
at all levels (team story and user story,
End
-
to
-
End test) was fundamental to avoiding ‘big bang’
problems.

In short XP in its purest form cannot be applied to large
scale high grade product development. It needs to be
augmented with some additional projec
t management
artifacts at a macroscopic level.

The use of test first design is difficult to achieve, as is the
practice of pair programming. These require significant
effort in terms of mentoring, tutoring and coaching.

Refactoring requires ‘bravery’ and

without collective
ownership and an appropriate set of unit tests it is unlikely
be done.

Badly designed and badly implemented code that delivers
the specified functionality has a habit of persisting until
there is a major failure.

Yesterday’s weather be
came an effective mechanisms for
estimating the effort for a piece of work. However, care
must still be taken to avoid under estimating and over
committing in an iterations.

By keeping metrics for each iteration it was possible to
check the project progres
s at any time. This is important
for global visibility within an organization.

The developer
-

customer communications needs careful
attention. The use of the architect team as a proxy
customer, while contributing to architectural consistency of
the prod
uct, didn’t quite achieve the developer/customer
dialogues espoused with XP.

Finally, XP has no place for maverick developers, who
want to do their own thing. They have a negative impact
on the development process and on team morale.

ACKNOWLEDGEMENTS

The

adoption of XP within Logica Mobile Networks was
championed and nurtured by Eoin Cavanagh. This
document is in part a summary of his efforts and process
development vision. Seamus Hayes was instrumental in
formulating the test structure for the project.

R
EFERENCES

1. Zope is an open source web application server primarily
written in the Python programming language.