Tahere Jahangiri

Tahere Jahangiri

Biography

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.

Contributions

rss  subscribe to this author

Amid Khatibi Bardsiri

Amid Khatibi Bardsiri

Biography

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.

Contributions

rss  subscribe to this author

Bookmarks

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.

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 [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:

  • objectivist methods
  • addressment of business problems
  • basement of practitioner
  • incremental development
  • iterative development
  • constant change
  • active user involvement
  • constant feedback and learning
  • teamwork
  • empowered teams
  • communication
  • small teams
  • frequent meetings
  • working software
  • non-mandatory modeling techniques
  • minimization of documentation.

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.

Lifecycle Management Practices Framework Software Construction Distributed Software Development Process Software Modeling
Scrum, RUP, DSDM, ASD, ISD Lean, CrystalXP, FDD, PP OSS AM

Table 1 – Agile Methods Classification

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 [REF-1, REF-2]
  • Rational Unified Process (RUP) is an iterative OO method that defines phases and practices for software modeling and development but does not provide concrete software development practices [REF-1]
  • The Dynamic Systems Development (DSDM) method consists of phases that comprise of feasibility and business studies as well as 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 iterative incremental development and constant prototyping [REF-1]. Its phases and practices cover the project's entire lifecycle, and do not focus on software construction
  • Internet Speed Development (ISD) practices and principles are related to handling customer engagement, architecture stability, teamwork, and environment constraints. None of those methods 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 [REF-17]
  • Crystal methods are a family of project management practices proposed by [REF-5] whose premise is that the project's size and criticality should determine the "weight" of the processes and controls to be applied [REF-1]

Software construction methods provide guidelines, tools, and practices close to the software construction such as:

  • Extreme Programming (XP) – 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) – focuses on design and building phases [REF-1]
  • Pragmatic Programming (PP) – a collection of programming best practices that solve daily problems and are focused on iterative incremental development, thorough tests and customer-oriented design [REF-1, REF-2.] It focuses on software construction.

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.

SOA Principles

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:

  1. Standardized Service Contract: a service should express its purpose and capacities through a contract
  2. Service Loose Coupling: the dependencies among the service's contract, implementation and consumers should be minimal
  3. Service Abstraction: a service should hide its implementation details to keep its consumers loosely coupled
  4. Service Reusability: services should be corporate resources, agnostic to functional contexts
  5. Service Autonomy: a service should have control over its environment and resources, while remaining isolated from other services
  6. Service Statelessness: services should only hold state information when necessary in order to not compromise its availability or scalability
  7. Service Discoverability: services should be easily discovered and understood to foster reuse
  8. 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, [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:

  1. teams are often geographically distributed, demanding good communication and cooperation among stakeholders and organization roles
  2. business partners have yet to understand the business model and their roles and responsibilities within the business net
  3. stakeholders can demand conflicting requirements which have to be handled properly
  4. alignment of business requirements with IT solutions
  5. the challenge of distributing 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.

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:

  1. Communication: keep communication flow by enforcement of communication practices
  2. Simplicity: provide simple solutions to solve specific problems even though it requires some changes in the future
  3. Feedback: give system feedback to all stakeholders
  4. Courage: encourage developers to make complex changes to source code at any given point of time.
  5. XP is composed of five fundamental principles:
  6. Rapid feedback: the team should get feedback and introduce the new knowledge into the system as soon as possible
  7. Simplicity: solve the present problem, instead of planning a solution to the future
  8. Incremental change in small chunks
  9. Embracing change: solve the most complex problems first, with the simplest design
  10. Quality work: pursue a good quality during system development.

Those values and principles are put in action through twelve practices:

  1. The Planning Game: the scope of the releases is determined by business priorities and technical estimates
  2. Small Releases: each release should be a simple and fast deployable
  3. Metaphor: a simple metaphor describes how the system should work
  4. Simple Design: design should derive from tests with the fewest possible classes and methods (no duplicated logic and stating every intention important to programmers)
  5. Testing: each program feature should have an associated automated test
  6. Refactoring: restructure the system continuously improving communication and flexibility
  7. Pair Programming: the code is written by two programmers side by side
  8. Collective Ownership: anyone is allowed to change the code of any part of the system at any given time
  9. Continuous Integration: the system is integrated and built several times a day
  10. 40-hour Week: everyone is supposed to work no longer than 40 hours per week
  11. On-site Customer: a real final user close to the team
  12. Coding Standards: to write the code.

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.

Related Work

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.

References

[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.

Abbreviations

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