7/28/2019 4944a254

1/6

Service Agile Development Using XP

Felipe Carvalho

Petrobras Petrleo Brasileiro S/A Graduate Program in

Informatics (PPGI)

Federal University of the State of Rio de Janeiro (UNIRIO)

Rio de Janeiro, Brazil

felipe.carvalho@uniriotec.br

Leonardo Guerreiro Azevedo

Applied Informatics Department (DIA)

Graduate Program in Informatics (PPGI)

Federal University of the State of Rio de Janeiro (UNIRIO)

Rio de Janeiro, Brazil

azevedo@uniriotec.br

AbstractSystem development using a Service-Oriented

Architecture approach encompasses new roles and tasks as

opposed to traditional development. It brings new challenges in

different aspects, such as: reuse, flexibility, stakeholders

involvement, business understanding. Considering methods for

system development, those aspects are handled by agile methods.However, there is no consensus on how to use agile methods in

service-oriented system development. Agile methods can be used

in different phases of a software development lifecycle, such as:

project management, modeling, software construction, software

testing. Extreme Programming (XP) is one of the methods more

closely related to the construction phase. XP is widely adopted in

the industry and offers practices that can be applied to several

business contexts. The goal of this work is to propose guidelines

and best practices towards service development, focused on the

construction phase, in an SOA environment using XP. It goes

towards the identification of the shared concerns and the gaps

between SOA and XP practices and, additionally, presents open

issues and main challenges to be considered when incrementally

constructing service solutions with continuous feedback and

flexibility to rapidly develop services that meet changing business

requirements.

KeywordsSOA, Extreme Programming, Service Development

Methods

I. INTRODUCTIONThe 21st century brought a new configuration to the global

economy: dynamism, new communication channels, globalcompetition, and deregulated markets shape a scenario wherecompanies communicate and negotiate directly [10].

Organizations are in a context where it is required torespond rapidly to market changes. By focusing on corecompetencies, organizations must establish a collaborationnetwork with partners for product delivery [10]. Henceorganizations have to find more agile ways of working tohandle unstable requirements and environments in a way thatimprove organizations competitive advantages.

Gu and Lago [7] state that service-oriented systems aredeveloped differently from traditional ones. There are greaterconcerns with reuse-oriented software construction,stakeholder involvement, deep understanding of businessmodel, service distribution across enterprise boundaries, and

business-IT alignment. Pressman [18] presents that projectsbased on frozen requirements, large development deadlines and

distant stakeholders are no longer able to deliver products in anunstable requirements scenario.

During the 2000-year, many articles were publishedhighlighting problems related to the documentation driven

development and heavyweight processes. Authors advocatelight methods for software development. In 2001, seventeendevelopers and consultants representatives of those methodsmet to discuss better ways of developing software. As a result,the Agile Manifesto was published [1]. It corresponds to fourstatements that express the main concerns for a development

process, based on twelve principles. The methods were namedas agile methods.

Given the contexts where service-orientation and agilityemerged, it is remarkable that both paradigms share similarconcerns, such as: new ways of working, flexibility,responsiveness to changes, stakeholder involvement, and

business understanding. Nevertheless, despite thesesimilarities, there is no consensus about the applicability ofagile methods to the service-oriented development [11].

As an example, the SOA principle of interface designaiming maximum reuse and flexibility does not follow theevolutionary design principle, upon which agile methods are

based on. On the other hand, [12] emphasizes that uncertaintyis inherent to service development. In this context, agilemethods and its practices of close customer, continuousfeedback, incremental development etc. are mechanisms todeal with such complexity and dynamism.

This work proposes guidelines and best practices thatemploy XP and SOA concepts for service development. Itexposes the issues and identifies shared concerns and existinggaps between the approaches. It also identifies ways tocombine SOA and XP to provide service-oriented solutions

built incrementally with continuous feedback and flexibility torapidly meet changes in business requirements.

The remainder of this work is organized as follow. Section2 introduces principles of agile methods. Section 3 presentsSOA principles. Section 4 presents XP values, principles and

practices. Section 5 presents the related work on combiningSOA and XP. Section 6 proposes a method for servicedevelopment using the XP agile approach adherent to SOA

principles. Section 7 presents the conclusion and points tofuture work.

2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

978-0-7695-4944-6/12 $26.00 2012 IEEE

DOI 10.1109/SOSE.2013.25

254

7/28/2019 4944a254

2/6

II. AGILE METHODS CHARACTERISTICSStrode [21] consolidates twelve agile methods published

between 1997 and 2003, and identifies a set of commonproperties among all methods, such as: Objectivist methods;Address business problems; Practitioner based; Incrementaldevelopment; Iterative development; Constant change; Activeuser involvement; Constant feedback and learning; Teamwork;

Empowered teams; Communication; Small teams; Frequentmeetings; Working software; Modeling techniques are notmandatory; Minimize documentation.

Those methods are related to several aspects or phases of asoftware development lifecycle and cover a broad spectrum.We conducted an analysis identifying which agile practices areemployed by each agile method. The results of this analysis are

presented in Appendix A, available at[http://www.uniriotec.br/~azevedo/UNIRIO/Agile_Methods_Practices_Analysis.pdf]. Some methods are related to specific

phases of a software development lifecycle (e.g., AgileModeling uses 3.8% of all agile practices) whilst others covermore practices (e.g., XP uses 44.2% of all agile practices).Besides, some practices are specific to a method (e.g.,

MoSCoW Rules is specific to DSDM) while others areemployed by most of the methods (e.g., up to 58% of themethods use Fitness for business purpose).

This work focus on construction phase due to the lack ofappropriate design and development methodologies that can beclosely followed and provide efficient SOA applications, whiledealing with SOA principles and complexities, as stated by [4].Hence, the 12 methods presented by [21] were reviewed andgrouped considering their most relevant characteristics into theclassification presented Table I and detailed as follows.

TABLE I. AGILE METHODS CLASSIFICATION

Lifecycle

Management

Practices

framework

Software

Construction

Distribute

d softwaredevelopme

nt process

Software

modeling

Scrum,

RUP,DSDM,ASD, ISD

Lean,Crystal

XP, FDD,PP

OSS AM

Lifecycle management methods prescribe practices andtools related to managing the lifecycle of a project: Scrum is anempirical approach for managing a software development

process in a volatile environment ([1] and [2]); RationalUnified Process (RUP) is an iterative OO method that defines

phases and practices for software modeling and development,but does not provid concrete software development practices

[1]; The Dynamic Systems Development (DSDM) methodconsists of phases that comprise feasibility and businessstudies, and iterative-incremental phases for prototyping,construction and implementation; Adaptive SoftwareDevelopment (ASD) is a method that focuses on thedevelopment of large, complex systems, based on iterative-incremental development and constant prototyping [1]. Its

phases and practices cover the projects entire lifecycle, and donot focus on software construction; Internet Speed

Development (ISD) practices and principles are related tohandling customer engagement, architecture stability,teamwork and environment constraints. All those methods donot define specific software construction practices.

Practice framework methods provide a set of tools orpractices to be tailored and used according to the situation athand, but do not present systematic way on how to perform the

tasks comprised by them: Lean provides insights andguidelines about how to apply lean manufacture principles tosoftware development [17]; Crystal methods are a family of

project management practices proposed by [5], whose premiseis that the projects size and criticality should determine theweight of the processes and controls to be applied [1].

Software construction methods provide guidelines, toolsand practices close to the software construction, such as:Extreme Programming (XP) is a method and a softwarediscipline that defines practices to be used on construction

phase, such as continuous integration, pair programming andrefactoring, with feedback to adjust the practices to thesituation under work; Feature-Driven Development (FDD) isfocus on design and building phases [1]. Pragmatic

Programming (PP) is a collection of programming bestpractices that solve daily problems and are focused on iterative-incremental development, thorough tests and customer-orienteddesign ([1] and [2]). It focus on software construction.

Distributed software development process: Methods thatdefine processes and guidelines for distributed softwaredevelopment, such as the Open Source Software (OSS)development, which is also not a method [1]. It consists of

phases related to problem identification, finding volunteers,solution identification, distributed software construction andrelease management. It focus on the aspects of distributedsoftware development than on software development practices.

Software modeling: Methods related to software modelingtechniques, such as the Agile Modeling (AM). It is a set of

practices focused on communication and cultural change ([1]and [2]) aiming to implement an agile modeling, focusing on

popular agile practices, such as: active user involvement, smallteams, close communication and collaboration, multi-disciplinary teams, low amount of documentation.

The classification presented in Table I identifies themethods that are more related to software construction (such asXP, FDD and PP), and the ones that do not relate to the goal ofthis work. When comparing those three methods, it isdemonstrated that XP covers a broader spectrum than theothers. XP makes use of approximate 45% of all agile

practices, while PP and FDD employ approximate 12% and17%, respectively. Besides, in a survey conducted by [15], XPis considered to be more popular than PP and FDD.

Considering both aspects, XP was chosen to be evaluated asagile method for service construction in an SOA context.

III. SOAPRINCIPLESErl [6] defines a service as any task or function provided by

an organization, aligned to business, well defined and isolatedfrom other tasks (autonomy principle).

255

7/28/2019 4944a254

3/6

According to [6], service-orientation is an implementationof the distributed logic solution paradigm, which aims to split a

big problem into small parts, adhering to concern separationtheory. The greatest benefit of service-orientation is to producesmall solutions that solve each small part of the original

problem, while being agnostic to the bigger problem to besolved. This split of problems into smaller pieces fosters reuse.

Erl [6] enumerates eight principles that a service-orientedsolution should follow: (i) Standardized Service Contract: aservice should express its purpose and capacities through acontract; (ii) Service Loose Coupling: the dependencies amongthe services contract, implementation and consumers should

be minimal; (iii) Service Abstraction: a service should hide itsimplementation details to keep its consumers loosely coupled;(iv) Service Reusability: services should be corporateresources, agnostic to functional contexts; (v) ServiceAutonomy: a service should have control over its environmentand resources, while remaining isolated from other services;(vi) Service Statelessness: services should only hold stateinformation when necessary in order to not compromise itsavailability or scalability; (vii) Service Discoverability:services should be easily discovered and understood to fosterreuse; (viii) Service Composability: it should be possible tocreate services from the composition of other services in orderto produce sophisticated solutions according to business needsrequirements and fostering reuse of existing assets.

Considering system development scenarios, [7] point thattraditional systems development typically deals with anumber of problems, such as not satisfying user requirementsor usage of resources according to budget or deadlinerestrictions. Distributed software development adds further

problems to systems development, such as: lack ofcommunication between stakeholders, unclear developmenttasks and arguable responsibility distribution. Besides, in anSOA environment, additional problems rise, for example:teams are often geographically distributed, demanding good

communication and cooperation among stakeholders andorganization roles; business partners have to understand the

business model and their roles and responsibilities within thebusiness net; stakeholders can demand conflicting requirementswhich have to be handled properly; alignment of businessrequirements with IT solutions; how to distribute servicesacross organizational boundaries in a secure manner. Section 5

presents a proposal for a service development method thatdeals with such complexities by using XP practices.

IV. XPVALUES,PRINCIPLES AND PRACTICESAs presented in Section 2, XP was the agile method chosen

to be used in this work. As pointed by [3], XP is made byvalues, principles and practices.

The four XP's values are: (i) Communication: keepcommunication flow by enforcement of communication

practices; (ii) Simplicity: provide simple solutions to solvespecific problems even though it requires some changes in thefuture; (iii) Feedback: give system feedback to all stakeholders;(iv) Courage: encourage developers to make complex changesto source code at any given point of time.

XP is composed by five fundamental principles: (i) Rapidfeedback: the team should get feedback and introduce the newknowledge into the system as soon as possible; (ii) Simplicity:solve the present problem, instead of planning a solution to thefuture; (iii) Incremental change in small chunks; (iv)Embracing change: solve the most complex problems first,with the simplest design; (v) Quality work: pursue a good

quality during system development.Those values and principles are put in action through

twelve practices: (i) The Planning Game: the scope of thereleases is determined by business priorities and technicalestimates; (ii) Small Releases: each release should be a simpleand fast deployable; (iii) Metaphor: a simple metaphordescribes how the system should work; (iv) Simple Design:design should derive from tests with the fewest possible classesand methods, no duplicated logic and stating every intentionimportant to programmers; (v) Testing: each program featureshould have an associated automated test;(vi) Refactoring:restructure the system continuously improving communicationand flexibility; (vii) Pair Programming: the code is written bytwo programmers side by side; (viii) Collective Ownership:anyone is allowed to change the code of any part of the systemat any given time; (ix) Continuous Integration: the system isintegrated and built several times a day; (x) 40-hour Week:everyone is supposed to work no longer than 40 hours perweek; (xi) On-site Customer: a real final user close to the team;(xii) Coding Standards: to write the code.

Beck [3] describes these values, principles and practices ascomplimentary. For instance, pair programming is supported

by tests, in the sense that both programmers line up theirunderstanding of the system before implementing it. Likewise,

both programmers share the understanding of the metaphor,making it the basis for decision-making and simplicity.

V. RELATED WORKSeveral authors report experiments or case studies

involving the use of agile methods in SOA initiatives.

Karsten & Cannizzo [8] report their experience using XPand Scrum in a distributed team developing a SoftwareDevelopment Kit (SDK) and a set of services, adherent to SOAconcepts, to expose traditional telecom features. Their majorfocus was keeping fine communication flow. The team wasdivided in several local sub-teams. The entire sub-team and thecustomer met every beginning and ending of sprints.Automated tests were created, and continuous integration wasconducted. Each sub-team worked on isolated componentswhose interfaces were loosely coupled. The authors providedimportant information about the usage of XP practices in anSOA development initiative. Nevertheless, it does not mention

how or whether SOA principles were pursuit by the team.There is no guideline or step-by-step proposal on how tocombine agile and SOA. It also lacks information about how

business-IT alignment was accomplished.

Madison [13] proposes a hybrid framework, composed bythe combination of Scrum, XP and sequential projectmanagement used for guiding architectural work on differentkinds of projects. It provides an example of its use in an SOA

256

7/28/2019 4944a254

4/6

project, but he does not refer to SOA principles or challenges,or how to tackle those using XP practices.

Ivanyukovich et al. [1] analyze how XP practices can beused in service development within an SOA context. They

believe that not all practices (namely Metaphor, PairProgramming, Collective Ownership and 40-hour Week) arerelevant for service development. On the other hand, they

consider advantages in the usage of other practices. Forexample, Planning Game allows the team to see the services asa set of features to be developed; Small Releases provideimmediate feedback from customers; Refactoring allows theservices to be continuously and smoothly redesigned andimproved; Coding Standards and Continuous Integration fosterorchestration and data mapping.

Roy & Debnath [19] introduced XP practices and theirinter-relationships along with SOA concepts. Afterwards, theydepicted a scenario of services development in a traditionalteam composed by a project manager, program leader, DBA,

programmers, each responsible for its part and notcommunicating or collaborating properly with others. Theauthors suggest the usage of XP practices to turn this team into

an agile one, but provide a shallow analysis of such conversionand applicability of the tools. Likewise, they do not refer toSOA complexities or how to tackle them using XP practices.

Schatz [20] focuses on the advantages by combining XPpractices to SOA, such as: automated tests continuouslyintegrated builds a reliable foundation; small releases addsvalue to organization immediately, and the system quality andfunctions can be verified by stakeholders at any time.

Nevertheless, [20] just provides insights on how SOA couldtake advantage of XP practices to deploy system faster andwith more quality, he does not discusses SOA complexities andtheir relationship with XP practices.

Callahan [4] considers the use of small releases, on-sitecustomer and pair programming practices to be beneficial toSOA, for improving communication within the team, andadding flexibility and rapid feedback to the development

process. On the other hand, Callahan [4] considers the lack ofan up-front design and minimal documentation to be harmful toSOA applications. It also shows concerns considering culturalaspects, e.g., SOA often deals with geographically distributedand large teams, and customers constrained by rigid schedules,whereas XP recommends small face-to-face teams, with a closecustomer. Nevertheless, [4] highlights that XP core practicesneed adaptations to fit SOA complexities properly. However,he does not provide an analysis of what modifications should

be made to combine XP and SOA.

Narayanan [16] believes SOA and agile can coexist in anenterprise by tying service-orientation goals and agile

practices. He does not specifically address XP practices, butgeneral agile practices. He explains how XP practices are to beused in this context, such as: refactoring, planning game andsimple design. He also suggests XP practices to support someSOA principles, e.g., loose coupling, abstraction,composability, standardized contract, stateless and reuse.However, he does not take into consideration how other XP

practices relate to SOA development, neither discusses thehandling of SOA complexities according to these practices.

This section has described several approaches that aim tocombine XP practices and SOA principles and complexities atsome level, seeking to provide flexible yet simple solutions thatrespond rapidly to business needs. All of them believe or havedemonstrated this combination is possible, but none has

produced a comprehensive approach that covers all of the threepoints: XP practices, SOA principles and complexities. The

next section presents the proposal of how these three issues canbe supported in combination, resulting in an adaptation of XPto support the delivery of SOA solutions.

VI. PROPOSALThis work presents a proposal of using XP for service

development in an SOA environment. For this purpose, in thissection we go through each SOA principle and present howeach XP practice can be used to support each SOA principle.Afterwards, we analyze the SOA complexities and how the XP

practices can be used to tackle them. Our goal is to defineguidelines and best practices to create an effective ServiceAgile Development approach. In the following subsections, itis presented how SOA principles can be supported by XP.

A. Standardized Service ContractAll stakeholders (customers, service providers, service

consumers, brokers) should understand the Metaphor [9] thatwill guide the development and the Planning Game. Formetaphor understanding, [14] propose to perform severalmeetings (planning games) among multiple teams. Contractsshould be Simple Designedto meet the simplest solution [22].Simple contracts allow providers and consumers to work in

parallel. It increases testability and makes easier to develop orconsume the service. Once established the generalunderstanding of the services and corresponding contracts,everyPair of Programmers should follow Coding Standards toimplement the services. An On-Site Customer yields rapidfeedback to define contracts and take decisions.

B. Service Loose CouplingMultiple stakeholders should be aware of the Metaphorthat

guides a contract creation. They are creators and reviewers ofcontracts aiming to an optimal coupling level between the

provided service and consumption. Simple Design favorsloosely coupled services and collective ownership, resulting onself-contained services. Service Testing provide instantfeedback making simpler refactoring of service code orcontract. Pair Programming implies programmers workingalso as reviewers aiming at a contract and implementation lowcoupling.Refactoringmust be used to fix the coupling amongservices. ContinuousIntegration provides a environment whereloose coupling can be measured. E.g., if the service has high

coupling, it will be more complex to deploy it. An on-sitecustomer provides feedback on assuring if coupling to theservice is adequate. Coding standards support service loosecoupling best practices and guidelines.

C. Service AbstractionThe Metaphor should be agreed by different stakeholders

aiming Simple Design that hides service implementation

257

7/28/2019 4944a254

5/6

details. Testcomplexity serve as a metric of how suitable is thelevel of service abstraction. Refactoringshould be performed

by Pair of Programmers in order to meet the desired level ofabstraction. An on-site customerprovides feedback on assuringthe right level of abstraction. Coding Standards must be usedto provide service abstraction best practices.

D. Service Reusability and Service AutonomyThe Metaphorshould help to design aiming to service reuseautonomy. Testcomplexity should be used as tool to produceservice reuse and isolation. Based on the stakeholdersagreement,Pair Programming should be used to continuouslyguarantee that the level of isolation is kept. Coding Standardsand Simple Design provide guidelines and best practices toyield reuse and autonomy. Continuous Integration provides aneutral environment, on which tests can only be executed ifisolated from a specific context, helping service developmentto be isolated from any specific context. Refactoringmay beused to yield reuse while On-site Customerprovide feedbackabout service reuse fostering development and refactoring.

E. Service StatelessnessBased on the Metaphorand a thorough Tests suite, thePair

of Programmers will be able to evaluate whether a service isholding state information inadvertently. In this case,Refactoring and Simple Design are used to simplify serviceswithout modifying its behavior. Coding Standards can alsoprovide best practices for programmers to avoid holding stateinformation during service development.

F. Service DiscoverabilityThe use ofSmall Releases offers new operations and new

contract versions to consumers, which, in turn, improves thediscoverability of the service for new purposes on everyrelease. A Metaphor aware stakeholders make it easy tounderstand the service by their consumers, consequentlyfostering discoverability. A Test suite running on ContinuousIntegration may be used to guarantee that the service iscorrectly discovered at any given time. On-Site Customers mayalso provide feedback on whether a service is easilydiscoverable. Coding Standard should provide guidelines toallow easy service discovery.

G. Service ComposabilitySmall Releases allow a given service to be available to new

compositions more frequently, allowing new priorities to beput on the next planning game. Metaphorand Simple Design ofcontract foster services adherent to that contract making easiercomposition within a shared context. Automated Tests andContinuous Integration make possible to foresee the behavior

of a given composition, or what to expect of each service thattake part in a given composition. An on-site customer can

provide rapid feedback on a service design in regards to itscomposability to other services. Coding standards may provideguidelines for service design yielding greater composability.

As depicted on Table II, most of SOA principles may behandled by several XP practices. Besides there is XP practicesis complementary when fitting SOA principles. E.g., Simple

Design and Coding Standards provide best practices andguidelines for service loose coupling, abstraction, and so on.CodingStandards foster collective ownership when developersswitch among services' implementation. ContinuousIntegration provides a neutral and isolated environmentyielding SimpleDesign. During Planning Games stakeholdersshare the metaphor to establish a ubiquitous language.

XP principles can also tackle the SOA complexities:

1) Cooperation between the SOA stakeholders: SOA dealswith distributed teams and stakeholders. Communication is

often done asynchronously and/or in not a face-to-face way,

depending on e-mails and instant messaging, leading to lack of

communication and inherent lack of cooperation among

stakeholders. This may be addressed by combiningPlanning

Game and [14]s approach of multiple meetings. Additionally,

by establishing a Metaphor, and thus an ubiquitous language,

stakeholders should have a common understanding of the

problem being tackled, and frequent meetings should help on

establish cooperation among them. The use of Continuous

Integration and Small Releases allow stakeholders to rapidly

know which features are deployed, and re-prioritize newfeatures and releases according to market demands. By having

flexibility and agility to put new features in production,

communication among stakeholders will be necessary to agree

on the set of features to be ready for the next release.

2) Good understanding of the business model andrelationship between business partners: Organizations are

focusing on core competencies and establishing collaboration

networks with partners for delivering customized products to

clients [10]. Therefore, business partners must understand the

combined business models to deliver products that fit the

market needs. Hence communication is vital, and our proposal

is to include business partners along with service stakeholders

during Planning Game and synchronization meetings.Business partners should understand the Metaphors and

priorities, improving collaboration.

3) How to deal with conflicting requirements: Ondistributed software development environment clients

demand conflicts occur frequently, leading to duplication and

loss of reuse. The solution for this issue is to include clients

and stakeholders in the Planning Game and synchronization

meetings. This way, they should be able to understand the

Metaphor and the existing conflicts. Besides, during the

planning game and the meetings, an agreement should result.

4) How to align the business requirements with the ITsolutions: Since business representatives are not always

present for taking decisions and guiding development, our

proposal is to tackle this by using On-site Customerpractice.

Final users or customers should be present on eitherPlanning

Game, synchronization meetings or sitting physically close to

development team (even if not permanently, as [3] states), to

answer questions, take small-scale decisions and providing

general guidance on the development.

5) How to distribute services across organizationalboundaries in a secure manner: The approach recommended

258

7/28/2019 4944a254

6/6

by this work is to have all roles (providers, consumers,

business partners, software developers, IT infrastructure

representatives) participating in Planning Game and

synchronization meetings, as to make everyone aware of

Metaphor (correponding to functional and non-functional

requirements). Besides, Coding Standards may provide

guidelines and best practices for developing secure services.

Test suites and Continuous Integration provide valuablefeedback on whether how secure and responsive is a service at

any given time. An On-site Customer may also guide

development based on test results. Small Releases and

Refactoring may be used to incrementally refine the services

implementation and infrasctructure settings.

6) Geographically distributed teams: The assimilation ofthe Metaphor is crucial for distributed teams. Tools must be

provided to perform face-to-face communication in planning

games and synchronization meetings.

7) Change management: A service should be simplydesigned to fit current needs, and refactoring is used to meet

new demands. We propose to prioritizeRefactoringduring the

Planning Game, and considering the impact on consumers,QoS, etc. The updated service is deployed in Small Releases in

the appropriate time considering the impact on consumers.

VII. CONCLUSIONService-Oriented Architecture and agile methods are

important paradigms for system development with similarconcerns, such as: flexibility, stakeholders involvement,

business understanding, among others. Despite this similarityin fundamental concepts, there is no consensus on how to useagile methods in service-oriented system development.

This work provided guidelines and best practices towardsan effective Service Agile Development approach focused onthe construction of services in SOA. It exposed the issues in the

emerging paradigm of combining agile methods and SOA.

In order to base the proposal, first this work presented theagile method characteristics, and, more specifically, XP

principles, values and practices, along with SOA principles andcomplexities. XP was the method employed by this work to

provide a service construction approach. Afterwards, it wasmade explicit how broad are the agile methods consideringcommon practices. In the Appendix A, it was highlightedwhich practices are covered/uncovered by each method, whatare the shared/unshared ones. After analyzing how XP

practices support SOA principles and complexities, weproposed an approach composed by a set of guidelines for theusage of XP practices in service development within an SOAcontext. It points a direction to use the practices to

incrementally build an SOA solution, with continuous feedbackand flexibility to rapidly meet changes in businessrequirements, while adherent to SOA solutions.

Nevertheless, as future work, we propose to evaluate theapproach in real world scenarios, and encompass the use ofagile methods throughout the whole SOA developmentlifecycle besides the construction phase.

REFERENCES

[1] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, Agile softwaredevelopment methods: review and analysis. Espoo, Finland: TechnicalResearch Centre of Finland, VTT Publications 478, Available online:http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf, 2002.

[2] P. Abrahamsson, J. Warsta, M. Siponen, J. Ronkainen, New directionson agile methods: a comparative analysis. Proceedings of the 25th

International Conference on Software Engineering, May 2003, USA.

[3] K. Beck, Extreme Programming Explained, 2nd ed. New York:Addison-Wesley, 2000.

[4] A. G. Callahan, Suitability of Extreme Programming and RUPSoftware Development Methodologies for SOA Applications, Seminaron Enterprise Information Systems: Service-Oriented Architecture andSoftware Engineering, Helsinki University of Technology, 2006.

[5] A. Cockburn, Surviving object-oriented projects: a manager's guide, 1sted. New York: Addison Wesley Longman, 1998.

[6] T. Erl, SOA: Principles of Service Design, 1st ed. New Jersey: PrenticeHall, 2007.

[7] Q. Gu, P. Lago, A Stakeholder-Driven Service Life Cycle Model forSOA. Proceedings of 2nd International Workshop On Service OrientedSoftware Engineering (IW-SOSWE 07), pp. 1-7, 2007.

[8] P. Karsten, F. Cannizzo, The Creation of a Distributed Agile Team.Agile Processes in Software Engineering and Extreme Programming,

Lecture Notes in Computer Science, Volume 4536/2007, pp. 235-239,2007.

[9] M. Keeling, M. Velichansky, Making Metaphors that Matter. AgileConference 2011.

[10] T. Kohlborn, A. Korthaus, T. Chan, M. Rosemann, Identification andanalysis of business and software services - a consolidated approach.IEEE Transactions On Services Computing, Vol. 2, No. 1, 2009.

[11] P. Krogdahl, G. Luef, C. Steindl. Service-oriented agility: an initialanalysis for the use of agile methods for SOA development,Proceedings of the 2005 IEEE International Conference on ServicesComputing (SCC05).

[12] M. Lankhorst, Agile service development, 1st ed. New York:Springer, 2012.

[13] J. Madison, Agile-architecture interactions. IEEE Software, Vol. 27,Issue 2, Pages 41-48, Mar-Apr, 2010

[14] R. Maranzato, M. Neubert, P. Herculano, Scaling Scrum step by step:the Mega framework. Agile Conference 2012.

[15] C. Melo, V. Santos, H. Corbucci, E. Katayama, A. Goldman, F. Kon,Agile Methods in Brazil: State of Practice in Teams and Organizations(in Portuguese). Technical Report RT-MAC-2012-03, ComputerScience Department, IME USP, May, 2012.

[16] V. Narayanan, Modern SOA methodology and SOA adoption usingagile practices. Available online: http://www.soamag.com/I42/0810-2.php and http://www.soamag.com/I43/0910-3.php, unpublished.

[17] M. Poppendieck, T. Poppendieck, Lean Software Development: AnAgile Toolkit, 1st ed. New York: Addison-Wesley, 2003.

[18] R. Pressman, Software Engineering A Practitioners Approach, 6th ed.Columbus: Mc Graw-Hill, 2012.

[19] S. Roy, M. K. Debnath, Designing SOA based e-governance systemusing eXtreme Programming methodology for developing countries,2nd International Conference on Software Technology and Engineering(ICSTE), vol. 2, pp. V2-277 - V2-282, 2010.

[20] B. Schatz, SOA and agile development achieving success throughcontinuous integration and testing. Available online:http://project.management6.com/Agile-Journal-SOA-And-Agile-Development-Achieving-Success-Through-download-w10442.pdf,.

[21] D. Strode, Agile methods: a comparative analysis, 19th AnnualConference of the National Advisory Committee on ComputingQualifications (NACCQ 2006), New Zealand, 2006.

[22] W. C. Wake, "Extreme Programming Explored", 1st ed. Reading:Addison-Wesley, 2001.

259