Tahere Jahangiri completed her Associate's degree in Computer Science at the Islamic Azad University of Minab, and her Bachelor's degree at Bandar Abbas University.
Amid received his BSc degree in Computer Software Enginering from Shahid Bahonar University in Kerman, Iran in 2008, and his MSc degree in Software Engineering from Islamic Azad University in Tehran, Iran in 2010. He is currently undertaking his PhD in the Science and Research branch of Islamic Azad University, focusing on software service metrics and measurement. He has published about 30 research papers in international journals and conference proceedings. His areas of research include software systems engineering, software service development, software service metrics, SOA, and cloud computing.
The Rapid Development of Solutions using XP – Part I Published: September 20, 2015 • Service Technology Magazine Issue XCII PDF
Abstract: One drawback of using the XP agile method in software development is its underestimation of software quality attribution. These attributes are of main indices of software architecture. In this study, a method is represented for responding to this challenge on the bases of probability theory.
Firstly, the rating matrix is structured on the bases of quality attributions architecture solutions. Each element of this matrix shows a rating for every solution, and the ratings are initialized through the analytic hierarchy process (AHP). Via quality weight implement on the above matrix, a rating vector is created. Each rating vector represents the rate of reaching those quality attributes in a rating matrix.
Because rating vectors have normal probable distribution, their elements' probable density is mostly gathered around the mean. In this study, the probable density of architecture is defined, the appropriateness of a solution in comparison to other solutions is evaluated. The response to XP challenge is done in order to reach architecture solutions in the frame of rating vector. A complex of data is gathered and the results are compared in an experimental method in order to investigate the represented method of this paper.
Keywords: Quality Attributes, Architecture Solutions, Normal Distribution and Analytic Hierarchy Process AHP.
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 [REF-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 [REF-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 [REF-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 [REF-18] presents that projects based on frozen requirements, large development deadlines and 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 [REF-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 [REF-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, [REF-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.
Agile Methods Characteristics
Strode [REF-21] consolidates twelve agile methods published between 1997 and 2013 and identifies a set of common properties among all methods including:
These methods are related to several 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 and are available at www.uniriotec.br/~azevedo/UNIRIO/Agile_Methods_Practices_Analysis.pdf. Some methods are related to specific phases of a software development lifecycle; for instance, Agile Modeling uses 3.8% of all agile practices. Others cover more practices; XP uses 44.2% of all agile practices.
Besides, some practices are specific to a method (MoSCoW Rules is specific to DSDM) while others are employed by most methods. For example, up to 58% of the methods use the "fitness for business" purpose.
This work focuses on a construction phase due to the lack of appropriate design and development methodologies that can be closely followed. It provides efficient SOA applications while dealing with SOA principles and complexities, as stated by [REF-4]. Hence the twelve methods presented by [REF-21] were reviewed and grouped considering their most relevant characteristics into the classification presented Table I and detailed as follows.
Table 1 – Agile Methods Classification
Lifecycle management methods prescribe practices and tools related to managing the lifecycle of a project:
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:
Software construction methods provide guidelines, tools, and practices close to the software construction such as:
Distributed software development process – a method that defines processes and guidelines for distributed software development such as the Open Source Software (OSS) development [REF-1] This process consists of phases related to problem identification, the finding of volunteers, solution identification, distributed software construction and release management. It focuses on the aspects of distributed software development rather 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 ([REF-1] and [REF-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, and minimal 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 [REF-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.
Erl [REF-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.) According to [REF-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 that it produces small solutions that solve parts of the original problem while being agnostic to the bigger problem to be solved. This split of problems into smaller pieces fosters reuse.
Erl [REF-6] enumerates eight principles that a service-oriented solution should follow:
Considering system development scenarios, [REF-7] points 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:
Section 5 presents a proposal for a service development method that deals with such complexities by using XP practices.
XP Values, Principles, and Practices
As presented in Section 2, XP was the agile method chosen to be used in this work. As pointed by [REF-3], XP is made by values, principles and practices. The four XP's values are:
Those values and principles are put in action through twelve practices:
Beck [REF-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.
Several authors report experiments or case studies involving the use of agile methods in SOA initiatives. Karsten & Cannizzo [REF-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 [REF-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 project, but he does not refer to SOA principles or challenges, or how to tackle those using XP practices. Ivanyukovich et al. [REF-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 [REF-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 those using XP practices.
Schatz [REF-20] focuses on the advantages by combining XP practices to SOA, such as: automated tests continuously integrated build a reliable foundation; small releases add value to organization immediately, and the system quality and functions can be verified by stakeholders at any time. Nevertheless, [REF-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 [REF-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 [REF-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, [REF-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 [REF-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.
[REF-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, 2012.
[REF-2] 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 2013.
[REF-3] K. Beck, Extreme Programming Explained, 2nd ed. New York: Addison-Wesley, 2000.
[REF-4] 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, 2010.
[REF-5] A. Cockburn, Surviving object-oriented projects: a manager's guide, 1st ed. New York: Addison Wesley Longman, 2009.
[REF-6] T. Erl, SOA: Principles of Service Design, 1st ed. New Jersey: Prentice Hall, 2011.
[REF-7] 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.
[REF-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, 2012.
[REF-9] M. Keeling, M. Velichansky, "Making Metaphors that Matter". Agile Conference 2011.
[REF-10] 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.
[REF-11] P. Krogdahl, G. Luef, C. Steindl. "Service-oriented agility: an initial analysis for the use of agile methods for SOA development", Proceedings of the 2010 IEEE International Conference on Services Computing (SCC'05).
[REF-12] M. Lankhorst, "Agile service development", 1st ed. New York: Springer, 2012.
[REF-13] J. Madison, "Agile-architecture interactions". IEEE Software, Vol. 27, Issue 2, Pages 41-48, Mar-Apr, 2010.
[REF-14] R. Maranzato, M. Neubert, P. Herculano, "Scaling Scrum step by step: the Mega framework". Agile Conference 2012.
[REF-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, Computer Science Department, IME – USP, May, 2012.
[REF-16] V. Narayanan, "Modern SOA methodology and SOA adoption using agile practices". Available online: http://www.soamag.com/I42/0810- 2.php and http://www.soamag.com/I43/0910-3.php, unpublished.
[REF-17] M. Poppendieck, T. Poppendieck, Lean Software Development: An Agile Toolkit, 1st ed. New York: Addison-Wesley, 2011.
[REF-18] R. Pressman, Software Engineering – A Practitioner's Approach, 6th ed. Columbus: Mc Graw-Hill, 2012.
[REF-19] 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.
[REF-20] B. Schatz, "SOA and agile development achieving success through continuous integration and testing". Available online: http://project.management6.com/Agile-Journal-SOA-And-Agile- Development-Achieving-Success-Through-download-w10442.pdf.
[REF-21] D. Strode, "Agile methods: a comparative analysis", 19th Annual Conference of the National Advisory Committee on Computing Qualifications (NACCQ 2006), New Zealand, 2010.
[REF-22] W. C. Wake, "Extreme Programming Explored", 1st ed. Reading: Addison-Wesley, 2008.
SOA: Service Oriented Architecture
XP: Extreme Programming
ISD: Internet Speed Development
FDD: Feature Driven Development
PP: Pragmatic Programming
OSS: Open Source Software
AM: Agile Modeling
RUP: Rational Unified Process
DSDM: Dynamic Systems Development
ASD: Adaptive Software Development
SDK: Software Development Kit