2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

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

distant stakeholders are no longer able to deliver products in an unstable requirements scenario. During the 2000-year, many articles were published highlighting problems related to the documentation driven development and heavyweight processes. Authors advocate light methods for software development. In 2001, seventeen developers and consultants representatives of those methods met to discuss better ways of developing software. As a result, the Agile Manifesto was published [1]. It corresponds to four statements that express the main concerns for a development process, based on twelve principles. The methods were named as agile methods. Given the contexts where service-orientation and agility emerged, it is remarkable that both paradigms share similar concerns, such as: new ways of working, flexibility, responsiveness to changes, stakeholder involvement, and business understanding. Nevertheless, despite these similarities, there is no consensus about the applicability of agile methods to the service-oriented development [11]. As an example, the SOA principle of interface design aiming maximum reuse and flexibility does not follow the evolutionary design principle, upon which agile methods are based on. On the other hand, [12] emphasizes that uncertainty is inherent to service development. In this context, agile methods and its practices of close customer, continuous feedback, incremental development etc. are mechanisms to deal with such complexity and dynamism. This work proposes guidelines and best practices that employ XP and SOA concepts for service development. It exposes the issues and identifies shared concerns and existing gaps between the approaches. It also identifies ways to combine SOA and XP to provide service-oriented solutions built incrementally with continuous feedback and flexibility to rapidly meet changes in business requirements. The remainder of this work is organized as follow. Section 2 introduces principles of agile methods. Section 3 presents SOA principles. Section 4 presents XP values, principles and practices. Section 5 presents the related work on combining SOA and XP. Section 6 proposes a method for service development using the XP agile approach adherent to SOA principles. Section 7 presents the conclusion and points to future work.

I.

INTRODUCTION

The 21st century brought a new configuration to the global economy: dynamism, new communication channels, global competition, and deregulated markets shape a scenario where companies communicate and negotiate directly [10]. Organizations are in a context where it is required to respond rapidly to market changes. By focusing on core competencies, organizations must establish a collaboration network with partners for product delivery [10]. Hence organizations have to find more agile ways of working to handle unstable requirements and environments in a way that improve organizations competitive advantages. Gu and Lago [7] state that service-oriented systems are developed differently from traditional ones. There are greater concerns with reuse-oriented software construction, stakeholder involvement, deep understanding of business model, service distribution across enterprise boundaries, and business-IT alignment. Pressman [18] presents that projects based on frozen requirements, large development deadlines and
978-0-7695-4944-6/12 $26.00 2012 IEEE DOI 10.1109/SOSE.2013.25 254

II.

AGILE METHODS CHARACTERISTICS

Strode [21] consolidates twelve agile methods published between 1997 and 2003, and identifies a set of common properties among all methods, such as: Objectivist methods; Address business problems; Practitioner based; Incremental development; Iterative development; Constant change; Active user involvement; Constant feedback and learning; Teamwork; Empowered teams; Communication; Small teams; Frequent meetings; Working software; Modeling techniques are not mandatory; Minimize documentation. Those methods are related to several aspects or phases of a software development lifecycle and cover a broad spectrum. We conducted an analysis identifying which agile practices are employed by each agile method. The results of this analysis are presented in Appendix A, available at [http://www.uniriotec.br/~azevedo/UNIRIO/Agile_Methods_P ractices_Analysis.pdf]. Some methods are related to specific phases of a software development lifecycle (e.g., Agile Modeling uses 3.8% of all agile practices) whilst others cover more 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 are employed by most of the methods (e.g., up to 58% of the methods use Fitness for business purpose). This work focus on construction phase due to the lack of appropriate design and development methodologies that can be closely followed and provide efficient SOA applications, while dealing with SOA principles and complexities, as stated by [4]. Hence, the 12 methods presented by [21] were reviewed and grouped considering their most relevant characteristics into the classification presented Table I and detailed as follows.
TABLE I. Lifecycle Manageme nt Scrum, RUP, DSDM, ASD, ISD Practices framewor k Lean, Crystal AGILE METHODS CLASSIFICATION Software Constructi on XP, FDD, PP Distribute d software developme nt process OSS Software modeling

Development (ISD) practices and principles are related to handling customer engagement, architecture stability, teamwork and environment constraints. All those methods do not define specific software construction practices. Practice framework methods provide a set of tools or practices to be tailored and used according to the situation at hand, but do not present systematic way on how to perform the tasks comprised by them: Lean provides insights and guidelines about how to apply lean manufacture principles to software development [17]; Crystal methods are a family of project management practices proposed by [5], whose premise is that the projects size and criticality should determine the weight of the processes and controls to be applied [1]. Software construction methods provide guidelines, tools and practices close to the software construction, such as: Extreme Programming (XP) is a method and a software discipline that defines practices to be used on construction phase, such as continuous integration, pair programming and refactoring, with feedback to adjust the practices to the situation under work; Feature-Driven Development (FDD) is focus on design and building phases [1]. Pragmatic Programming (PP) is a collection of programming best practices that solve daily problems and are focused on iterativeincremental development, thorough tests and customer-oriented design ([1] and [2]). It focus on software construction. Distributed software development process: Methods that define processes and guidelines for distributed software development, 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 and release management. It focus on the aspects of distributed software development than on software development practices. Software modeling: Methods related to software modeling techniques, 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, small teams, close communication and collaboration, multidisciplinary teams, low amount of documentation. The classification presented in Table I identifies the methods that are more related to software construction (such as XP, FDD and PP), and the ones that do not relate to the goal of this work. When comparing those three methods, it is demonstrated that XP covers a broader spectrum than the others. XP makes use of approximate 45% of all agile practices, while PP and FDD employ approximate 12% and 17%, respectively. Besides, in a survey conducted by [15], XP is considered to be more popular than PP and FDD. Considering both aspects, XP was chosen to be evaluated as agile method for service construction in an SOA context. III. SOA PRINCIPLES

AM

Lifecycle management methods prescribe practices and tools related to managing the lifecycle of a project: Scrum is an empirical approach for managing a software development process in a volatile environment ([1] and [2]); Rational Unified 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) method consists of phases that comprise feasibility and business studies, and iterative-incremental phases for prototyping, construction and implementation; Adaptive Software Development (ASD) is a method that focuses on the development of large, complex systems, based on iterativeincremental development and constant prototyping [1]. Its phases and practices cover the projects entire lifecycle, and do not focus on software construction; Internet Speed

Erl [6] defines a service as any task or function provided by an organization, aligned to business, well defined and isolated from other tasks (autonomy principle).

255

According to [6], service-orientation is an implementation of the distributed logic solution paradigm, which aims to split a big problem into small parts, adhering to concern separation theory. The greatest benefit of service-orientation is to produce small solutions that solve each small part of the original problem, while being agnostic to the bigger problem to be solved. This split of problems into smaller pieces fosters reuse. Erl [6] enumerates eight principles that a service-oriented solution should follow: (i) Standardized Service Contract: a service should express its purpose and capacities through a contract; (ii) Service Loose Coupling: the dependencies among the services contract, implementation and consumers should be minimal; (iii) Service Abstraction: a service should hide its implementation details to keep its consumers loosely coupled; (iv) Service Reusability: services should be corporate resources, agnostic to functional contexts; (v) Service Autonomy: a service should have control over its environment and resources, while remaining isolated from other services; (vi) Service Statelessness: services should only hold state information when necessary in order to not compromise its availability or scalability; (vii) Service Discoverability: services should be easily discovered and understood to foster reuse; (viii) Service Composability: it should be possible to create services from the composition of other services in order to produce sophisticated solutions according to business needs requirements and fostering reuse of existing assets. Considering system development scenarios, [7] point that traditional systems development typically deals with a number of problems, such as not satisfying user requirements or usage of resources according to budget or deadline restrictions. Distributed software development adds further problems to systems development, such as: lack of communication between stakeholders, unclear development tasks and arguable responsibility distribution. Besides, in an SOA environment, additional problems rise, for example: teams are often geographically distributed, demanding good communication and cooperation among stakeholders and organization roles; business partners have to understand the business model and their roles and responsibilities within the business net; stakeholders can demand conflicting requirements which have to be handled properly; alignment of business requirements with IT solutions; how to distribute services across organizational boundaries in a secure manner. Section 5 presents a proposal for a service development method that deals with such complexities by using XP practices. IV. XP VALUES, PRINCIPLES AND PRACTICES

XP is composed by five fundamental principles: (i) Rapid feedback: the team should get feedback and introduce the new knowledge into the system as soon as possible; (ii) Simplicity: solve the present problem, instead of planning a solution to the future; (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 the releases is determined by business priorities and technical estimates; (ii) Small Releases: each release should be a simple and fast deployable; (iii) Metaphor: a simple metaphor describes how the system should work; (iv) Simple Design: design should derive from tests with the fewest possible classes and methods, no duplicated logic and stating every intention important to programmers; (v) Testing: each program feature should have an associated automated test;(vi) Refactoring: restructure the system continuously improving communication and flexibility; (vii) Pair Programming: the code is written by two programmers side by side; (viii) Collective Ownership: anyone is allowed to change the code of any part of the system at any given time; (ix) Continuous Integration: the system is integrated and built several times a day; (x) 40-hour Week: everyone is supposed to work no longer than 40 hours per week; (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 as complimentary. For instance, pair programming is supported by tests, in the sense that both programmers line up their understanding 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 WORK

Several authors report experiments or case studies involving the use of agile methods in SOA initiatives. Karsten & Cannizzo [8] report their experience using XP and Scrum in a distributed team developing a Software Development Kit (SDK) and a set of services, adherent to SOA concepts, to expose traditional telecom features. Their major focus was keeping fine communication flow. The team was divided in several local sub-teams. The entire sub-team and the customer met every beginning and ending of sprints. Automated tests were created, and continuous integration was conducted. Each sub-team worked on isolated components whose interfaces were loosely coupled. The authors provided important information about the usage of XP practices in an SOA 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 to combine agile and SOA. It also lacks information about how business-IT alignment was accomplished. Madison [13] proposes a hybrid framework, composed by the combination of Scrum, XP and sequential project management used for guiding architectural work on different kinds of projects. It provides an example of its use in an SOA

As presented in Section 2, XP was the agile method chosen to be used in this work. As pointed by [3], XP is made by values, principles and practices. The four XP's values are: (i) Communication: keep communication flow by enforcement of communication practices; (ii) Simplicity: provide simple solutions to solve specific problems even though it requires some changes in the future; (iii) Feedback: give system feedback to all stakeholders; (iv) Courage: encourage developers to make complex changes to source code at any given point of time.

256

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 be used in service development within an SOA context. They believe that not all practices (namely Metaphor, Pair Programming, Collective Ownership and 40-hour Week) are relevant for service development. On the other hand, they consider advantages in the usage of other practices. For example, Planning Game allows the team to see the services as a set of features to be developed; Small Releases provide immediate feedback from customers; Refactoring allows the services to be continuously and smoothly redesigned and improved; Coding Standards and Continuous Integration foster orchestration and data mapping. Roy & Debnath [19] introduced XP practices and their inter-relationships along with SOA concepts. Afterwards, they depicted a scenario of services development in a traditional team composed by a project manager, program leader, DBA, programmers, each responsible for its part and not communicating or collaborating properly with others. The authors suggest the usage of XP practices to turn this team into an agile one, but provide a shallow analysis of such conversion and applicability of the tools. Likewise, they do not refer to SOA complexities or how to tackle them using XP practices. Schatz [20] focuses on the advantages by combining XP practices to SOA, such as: automated tests continuously integrated builds a reliable foundation; small releases adds value to organization immediately, and the system quality and functions can be verified by stakeholders at any time. Nevertheless, [20] just provides insights on how SOA could take advantage of XP practices to deploy system faster and with more quality, he does not discusses SOA complexities and their relationship with XP practices. Callahan [4] considers the use of small releases, on-site customer and pair programming practices to be beneficial to SOA, for improving communication within the team, and adding flexibility and rapid feedback to the development process. On the other hand, Callahan [4] considers the lack of an up-front design and minimal documentation to be harmful to SOA applications. It also shows concerns considering cultural aspects, e.g., SOA often deals with geographically distributed and large teams, and customers constrained by rigid schedules, whereas XP recommends small face-to-face teams, with a close customer. Nevertheless, [4] highlights that XP core practices need 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 an enterprise by tying service-orientation goals and agile practices. He does not specifically address XP practices, but general agile practices. He explains how XP practices are to be used in this context, such as: refactoring, planning game and simple design. He also suggests XP practices to support some SOA 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 the handling of SOA complexities according to these practices.

This section has described several approaches that aim to combine XP practices and SOA principles and complexities at some level, seeking to provide flexible yet simple solutions that respond rapidly to business needs. All of them believe or have demonstrated this combination is possible, but none has produced a comprehensive approach that covers all of the three points: XP practices, SOA principles and complexities. The next section presents the proposal of how these three issues can be supported in combination, resulting in an adaptation of XP to support the delivery of SOA solutions. VI. PROPOSAL

This work presents a proposal of using XP for service development in an SOA environment. For this purpose, in this section we go through each SOA principle and present how each 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 define guidelines and best practices to create an effective Service Agile Development approach. In the following subsections, it is presented how SOA principles can be supported by XP. A. Standardized Service Contract All stakeholders (customers, service providers, service consumers, brokers) should understand the Metaphor [9] that will guide the development and the Planning Game. For metaphor understanding, [14] propose to perform several meetings (planning games) among multiple teams. Contracts should be Simple Designed to meet the simplest solution [22]. Simple contracts allow providers and consumers to work in parallel. It increases testability and makes easier to develop or consume the service. Once established the general understanding of the services and corresponding contracts, every Pair of Programmers should follow Coding Standards to implement the services. An On-Site Customer yields rapid feedback to define contracts and take decisions. B. Service Loose Coupling Multiple stakeholders should be aware of the Metaphor that guides a contract creation. They are creators and reviewers of contracts aiming to an optimal coupling level between the provided service and consumption. Simple Design favors loosely coupled services and collective ownership, resulting on self-contained services. Service Testing provide instant feedback making simpler refactoring of service code or contract. Pair Programming implies programmers working also as reviewers aiming at a contract and implementation low coupling. Refactoring must be used to fix the coupling among services. Continuous Integration provides a environment where loose coupling can be measured. E.g., if the service has high coupling, it will be more complex to deploy it. An on-site customer provides feedback on assuring if coupling to the service is adequate. Coding standards support service loose coupling best practices and guidelines. C. Service Abstraction The Metaphor should be agreed by different stakeholders aiming Simple Design that hides service implementation

257

details. Test complexity serve as a metric of how suitable is the level of service abstraction. Refactoring should be performed by Pair of Programmers in order to meet the desired level of abstraction. An on-site customer provides feedback on assuring the right level of abstraction. Coding Standards must be used to provide service abstraction best practices. D. Service Reusability and Service Autonomy The Metaphor should help to design aiming to service reuse autonomy. Test complexity should be used as tool to produce service reuse and isolation. Based on the stakeholders agreement, Pair Programming should be used to continuously guarantee that the level of isolation is kept. Coding Standards and Simple Design provide guidelines and best practices to yield reuse and autonomy. Continuous Integration provides a neutral environment, on which tests can only be executed if isolated from a specific context, helping service development to be isolated from any specific context. Refactoring may be used to yield reuse while On-site Customer provide feedback about service reuse fostering development and refactoring. E. Service Statelessness Based on the Metaphor and a thorough Tests suite, the Pair of Programmers will be able to evaluate whether a service is holding state information inadvertently. In this case, Refactoring and Simple Design are used to simplify services without modifying its behavior. Coding Standards can also provide best practices for programmers to avoid holding state information during service development. F. Service Discoverability The use of Small Releases offers new operations and new contract versions to consumers, which, in turn, improves the discoverability of the service for new purposes on every release. A Metaphor aware stakeholders make it easy to understand the service by their consumers, consequently fostering discoverability. A Test suite running on Continuous Integration may be used to guarantee that the service is correctly discovered at any given time. On-Site Customers may also provide feedback on whether a service is easily discoverable. Coding Standard should provide guidelines to allow easy service discovery. G. Service Composability Small Releases allow a given service to be available to new compositions more frequently, allowing new priorities to be put on the next planning game. Metaphor and Simple Design of contract foster services adherent to that contract making easier composition within a shared context. Automated Tests and Continuous Integration make possible to foresee the behavior of a given composition, or what to expect of each service that take part in a given composition. An on-site customer can provide rapid feedback on a service design in regards to its composability to other services. Coding standards may provide guidelines for service design yielding greater composability. As depicted on Table II, most of SOA principles may be handled by several XP practices. Besides there is XP practices is complementary when fitting SOA principles. E.g., Simple

Design and Coding Standards provide best practices and guidelines for service loose coupling, abstraction, and so on. Coding Standards foster collective ownership when developers switch among services' implementation. Continuous Integration provides a neutral and isolated environment yielding Simple Design. During Planning Games stakeholders share the metaphor to establish a ubiquitous language. XP principles can also tackle the SOA complexities: 1) Cooperation between the SOA stakeholders: SOA deals with 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 combining Planning 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 new features 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 and relationship 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: On distributed 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 IT solutions: Since business representatives are not always present for taking decisions and guiding development, our proposal is to tackle this by using On-site Customer practice. Final users or customers should be present on either Planning 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 organizational boundaries in a secure manner: The approach recommended

258

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 valuable feedback 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 of the 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 simply designed to fit current needs, and refactoring is used to meet new demands. We propose to prioritize Refactoring during 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. CONCLUSION Service-Oriented Architecture and agile methods are important paradigms for system development with similar concerns, such as: flexibility, stakeholders involvement, business understanding, among others. Despite this similarity in fundamental concepts, there is no consensus on how to use agile methods in service-oriented system development. This work provided guidelines and best practices towards an effective Service Agile Development approach focused on the 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 the agile method characteristics, and, more specifically, XP principles, values and practices, along with SOA principles and complexities. XP was the method employed by this work to provide a service construction approach. Afterwards, it was made explicit how broad are the agile methods considering common practices. In the Appendix A, it was highlighted which practices are covered/uncovered by each method, what are the shared/unshared ones. After analyzing how XP practices support SOA principles and complexities, we proposed an approach composed by a set of guidelines for the usage of XP practices in service development within an SOA context. It points a direction to use the practices to incrementally build an SOA solution, with continuous feedback and flexibility to rapidly meet changes in business requirements, while adherent to SOA solutions. Nevertheless, as future work, we propose to evaluate the approach in real world scenarios, and encompass the use of agile methods throughout the whole SOA development lifecycle besides the construction phase.

REFERENCES
[1] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, Agile software development methods: review and analysis. Espoo, Finland: Technical Research Centre of Finland, VTT Publications 478, Available online: http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf, 2002. P. Abrahamsson, J. Warsta, M. Siponen, J. Ronkainen, New directions on agile methods: a comparative analysis. Proceedings of the 25th International Conference on Software Engineering, May 2003, USA. K. Beck, Extreme Programming Explained, 2nd ed. New York: Addison-Wesley, 2000. A. G. Callahan, Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications, Seminar on Enterprise Information Systems: Service-Oriented Architecture and Software Engineering, Helsinki University of Technology, 2006. A. Cockburn, Surviving object-oriented projects: a manager's guide, 1st ed. New York: Addison Wesley Longman, 1998. T. Erl, SOA: Principles of Service Design, 1st ed. New Jersey: Prentice Hall, 2007. Q. Gu, P. Lago, A Stakeholder-Driven Service Life Cycle Model for SOA. Proceedings of 2nd International Workshop On Service Oriented Software Engineering (IW-SOSWE 07), pp. 1-7, 2007. 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. M. Keeling, M. Velichansky, Making Metaphors that Matter. Agile Conference 2011. T. Kohlborn, A. Korthaus, T. Chan, M. Rosemann, Identification and analysis of business and software services - a consolidated approach. IEEE Transactions On Services Computing, Vol. 2, No. 1, 2009. P. Krogdahl, G. Luef, C. Steindl. Service-oriented agility: an initial analysis for the use of agile methods for SOA development, Proceedings of the 2005 IEEE International Conference on Services Computing (SCC05). M. Lankhorst, Agile service development, 1st ed. New York: Springer, 2012. J. Madison, Agile-architecture interactions. IEEE Software, Vol. 27, Issue 2, Pages 41-48, Mar-Apr, 2010 R. Maranzato, M. Neubert, P. Herculano, Scaling Scrum step by step: the Mega framework. Agile Conference 2012. 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, Computer Science Department, IME USP, May, 2012. V. Narayanan, Modern SOA methodology and SOA adoption using agile practices. Available online: http://www.soamag.com/I42/08102.php and http://www.soamag.com/I43/0910-3.php, unpublished. M. Poppendieck, T. Poppendieck, Lean Software Development: An Agile Toolkit, 1st ed. New York: Addison-Wesley, 2003. R. Pressman, Software Engineering A Practitioners Approach, 6th ed. Columbus: Mc Graw-Hill, 2012. S. Roy, M. K. Debnath, Designing SOA based e-governance system using eXtreme Programming methodology for developing countries, 2nd International Conference on Software Technology and Engineering (ICSTE), vol. 2, pp. V2-277 - V2-282, 2010. B. Schatz, SOA and agile development achieving success through continuous integration and testing. Available online: http://project.management6.com/Agile-Journal-SOA-And-AgileDevelopment-Achieving-Success-Through-download-w10442.pdf,. D. Strode, Agile methods: a comparative analysis, 19th Annual Conference of the National Advisory Committee on Computing Qualifications (NACCQ 2006), New Zealand, 2006. W. C. Wake, "Extreme Programming Explored", 1st ed. Reading: Addison-Wesley, 2001.

[2]

[3] [4]

[5] [6] [7]

[8]

[9] [10]

[11]

[12] [13] [14] [15]

[16]

[17] [18] [19]

[20]

[21]

[22]

259