Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications

Transcription

1 Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications Guillermo A. Callahan 1 1 Seminar on Enterprise Information Systems : Service Oriented Architecture and Software Engineering, Helsinki University of Technology SoberIT, Innopoli 2, Tekniikantie 14, Espoo, Finland Abstract. Because of the recent importance given to Service Oriented Architecture (SOA), a document review investigation has taken place with the objective to compare SOA development with two highly used agile software development methods: Extreme Programming (XP) and Relational Unified Process (RUP). The motor behind this investigation is to see if this agile development methods are capable enough to design effectively and efficiently SOA type applications. The investigation concluded that both methodologies are not exactly suited to create SOA applications, but RUP has a greater chance to provide SOA type applications if the proper adjustments are made, specially on the design side of the methodology. Keywords: Service Oriented Architecture, Software Development Methods, Extreme Programming, Relational Unified Process (RUP). 1 Introduction Service Oriented Architecture has been a topic that has been discussed about a lot recently, specially because of the supposed benefits it can provide companies: empowering a business environment with a flexible infrastructure and processing environment by provisioning independent, reusable, automated business processes and providing a robust information foundation for leveraging these services. In other words: a software application that has the power to incorporate business services to business practices all together, while being distributed along a network, no mater what is the underlying technology [1]. Also these services are reusable, independent and can compose aggregate services by combining it with other ones, therefore reducing the cost of new technology for every change made to the system, creation of new services, maintenance, etc. For this, SOA can be defined as the logical way to design a software concept that provides services to either end user applications or to other services distributed over network, via published and discoverable interfaces [2].

2 As new computing paradigm, SOA is in it's baby steps, as most of the structure, design and technology are still under research. But as an idea, it is not as new, this is because the vision of having reusable, composite and dependable code components, as well as the benefits, have long been envisioned [2]. One of the research priorities regarding SOA is the search of a proper design and development methodology that can take into account all of the SOA principles and that, while being closely followed, can conclude on the creation of working and efficient SOA type applications. Since SOA is of high importance for businesses (specially because the increasing importance of services in the economy of developed countries [3][4]), and fact that there is no proper development methodology yet, a document review investigation was carried out. The objective of this investigation is to find if any current software development methodology can more or less replicate, at least to some extension, SOA principles at the moment of design or development. The methodologies chosen to take part in this investigation are two popular agile software developing methodologies: Extreme Programming (XP) and the Rational Unified Process (RUP) [6]. These methodologies have their very own differences, strengths, drawbacks, etc. Even though, RUP is sometimes not considered an agile development method, because of the large quantity of requirements and processes between iterations, but still, the methodology can be tuned to be agile by eliminating some processes between iterations. even though, it is also because of the large differences between XP and this methodology that it was chosen for this investigation; after all they still carry out the same objective: that at the end of the development process, the software product should be finished, or at least the reasons for why the development couldn't continue are explicitly given. The rest of the document is written in the following way: each of the previously stated methodologies will be explained separately, mentioning their characteristics, it's life cycle and it's principles, then it's benefits when developing SOA type applications, it's drawbacks after that, and possible point's of improving when using that methodology when developing SOA type applications. 2 Extreme Programming (XP): Extreme Programming (XP) is a relatively new agile software development method, that, evolving from the problems cause by the long development cycles of traditional development practices [7], the methodology concluded as a combination of practices that have been found effective in software development processes over time. These principles, even though not new, were incorporated in such a way that they are lined up to function with each other, eventually forming this methodology. The term Extreme comes from taking these principles to extreme levels [8]. The methodology is considered as an agile software development method because: it is an incremental development methodology (that takes out small software releases, versions or parts of a software product in rapid cycles), it's cooperative nature with

3 costumers (costumers and developers in close communication), straightforward (as in the method itself is easy to learn, modify, etc) and that it's adaptive (it is able to make last minute changes to the software product) [8]. The life cycle of the XP software development methodology consists of 6 steps or phases, which are [6]: Exploration: This is the first phase, consists that the costumer writes story cards (description of features to be added into the program), which are delivered to the developers, where afterwards, these familiarize themselves with the requirements, the technology, the practices they are going to be used, etc. After that, the team of developers test the technology and also the development of a prototype to explore the architecture possibilities. Planning: Here the development team sets priority to the story cards and agrees with the costumer about the contents of the first release, and also the schedule for each of the features. Iterations to release: The schedule set in the planning phase is broken down to a number of iterations, these iterations create one or more functions of the system in each one of them. Functional tests are made after every iteration and at the final iteration, the system is ready for production. Productionizing: This phase consists of extra testing and performance checks, while also revising if new changes are found and need to be included in the current release, this of course to provide a much better version for the costumer. Maintenance: The development is in this phase after the first version is productionalized and the XP project is kept in the production running while making new iterations. Death: It is the final phase, when the costumer doesn't have any more story cards to provide and it satisfies the costumers needs in every aspect. Also this is the phase where the documentation is written since there are no more changes to the architecture. This is also when either the system becomes too expensive for further development, or it's canceled when it doesn't get to meet the needed requirements. The methodology claims to be able to provide successful software development despite having a vague idea of the environment (filled with uncertainty), or being in an environment that has constant changes. The methodology aims to provide a successful developing if the following practices are being followed [8]: Planning Game: The programmers estimate the effort needed for the implementation of the customer's stories, while the customer decides the scope and timing. Small/Short Releases: A simple system is productionized rapidly at least once every 2 or 3 months.

4 Metaphor: This means that both the customer and the programmers share a story based on metaphors that guides all development by describing the functionality of the system. Simple Design: Emphasis on finding the simplest possible solution that is implementable at the moment. Testing: The software development is test driven. Refactoring: It means restructuring the system by removing duplication, improving communication, simplifying and adding flexibility. Pair Programming: Two people write code in the same computer. Collective Ownership: Anyone can change code at any given time. Continuous Integration: A new piece of code is integrated into the code base as soon. 40 Hour Week: Maximum of a 40 hour working week, with no more than two overtime weeks in a row are allowed. On Site Costumer: The customer has to be present and available full time for the team. Coding Standards: Coding rules exist and are followed by the programmers. Open Workspace: A large room with small cubicles where pair programming can be performed. Just Rules: The team has it's own rules that are followed, but they can be changed at anytime. In simpler words, the methodology consists on keeping the agile methodology requirements by having small groups of tightly communicated developing teams, which develop small parts of the project in quick intervals, where the costumer interacts directly to the team to see the small, but (supposedly) increasing improvements in the development. It is based on high communication within the development team and the costumer, simple solutions by small iterations and quick feedback to stop any chance of creating complicated code that won't be used or that has flaws in it, and finally the courage to try, day by day, small changes to the code to get to the best solution, providing an evolving design at the moment of coding. 2.1 Comparison of XP with SOA Benefits: SOA indeed requires an evolving software development method, since SOA consists of a highly uncertain environment where constant business, protocol, code, process among other changes are already considered and foreseen. Since XP considers changes after every small and rapid iteration, it allows for quick changes inside the code, providing a flexible coding environment. The instant communication with the costumer is also a great strength for the SOA environment, since business rules and processes are constantly changing and adding up to the original project. Direct communication with the costumer can provide a

5 more accurate description of the business needs and requirements the costumer desires in the project. Another strength of XP inside the developing of a SOA is that the high communication between developers; small teams constantly communicating, well defined roles and pair programming seem to provide large improvements in productivity and in obtaining a successful final project. 2.2 Comparison of XP with SOA Drawbacks: There are many publications that argue that XP is not really a good software development methodology, as they argue that the lack of documentation (either on requirements or design), constant code tweaking and unlikeliness of having either a capable on site costumer, or one that is available anytime, provides difficulties for the development of a software project. Even though a software project can be finalized using XP, same publications argue that other development methods can do the same more effectively, cheaply and easily [9][10]. On the side of developing SOA applications with XP, the most important drawback is the lack of any up front design of the system or of its requirements. The immense requirements of a true SOA inside a business structure can cause loss of focus; producing bugs and an architecture that can be completely wrong design wise. The development of an architecture that uses services as building blocks, that incorporates these services themselves to use them to create composite services, that has to support constant changes in the business environment with an increasing amount of possible variables inside it and, most importantly, the need for these services to work correctly in any situation requires a well thought design beforehand, one that incorporates all the possible variables inside the development. Secondly, as SOA tries to incorporate services from previously designed applications and systems, keeping track of the state of the current applications and keeping a tangible reference or model of development could be very useful for the effective development of a SOA driven architecture. All of this without mentioning the possibility of creating composite services out of single services, and that these compositions can act as a service themselves, or not mentioning the management required behind these services so they can operate seamlessly and effectively [1][9][10]. The lack of documentation, or any design model, is supposedly replaced by constant testing, pair programming and the availability of an an on site costumer. Constant testing might be able to detect bugs, but sometimes failure in design is detected very long afterward. Pair programming can be useful for any development process, but the need for an specification is still required, even though the on site costumer can be able to provide the necessary insight, the fact that the possibility of a completely aware costumer of the business situation inside the company, and the (assuming) slight chances of being available all the time, requires the need of an upfront documentation to guide the developers through the process [9]. Another possible drawbacks when applying XP is that if either the size of the developing team (as it is best suited for small medium teams), the geographical circumstances (as it is stated that geographically separated teams are intolerable for

6 XP), the business culture behind the costumer (as, for example, rigid schedules from the on site costumer stops the feedback from being delivered, slowing the development process) and finally, the type of technology (if it requires long feedback times and a strong resistance to change, which is a possibility behind SOA) are not equivalent to the XP principles, it makes XP unsuitable for the software project, which can include SOA related projects [1][9]. 2.3 Discussion of Areas of Improvement for the Development of SOA Type Software (XP): Since XP is one of the most documented agile software development methodologies, there's been reports on the possibilities and restrictions of XP, as for example, there are statements of productivity gains by using XP inside a e business company. The company in question, did server side Java development and the company used principles similar to the one XP advocates, and it showed increases in productivity. But still, even though that positive review, it is still hard to conceive the implementation of XP in a SOA related development [11] The lack of a real up front documentation can be seen as a big flaw for SOA development. As stated before, the huge requirements and variables inside SOA applications should require a starting point, (which stops ad hoc development, mainly because of the use of previously developed applications). The use of at least some documentation should be of very big use for SOA development. It is stated that XP is just a group of principles, and also, it has been noted that not all of the investigations regarding developing experience with XP have used all of the principles. This indicates that using XP for SOA can be tailored a bit to choose the principles that can work best in the developing of this architecture [8]. Definitely, as stated before, documentation is needed. But the adaptation of this principles to include bigger and geographically separated groups could also be of great use, as there are statements that SOA is a multi disciplinary task, which will require large amounts of people in planning and possibly, also in development. Another point of improvement could be the fact of having roles that involve costumer relationships, designing responsibilities, managerial responsibilities, and also, a role that involves knowledge or research of the possible costumers that would use this SOA based application, as these would be most likely required for the development of an effective SOA project. In a personal opinion, I believe XP is more concentrated on small projects filled with high uncertainty. Even though SOA is in a highly uncertain environment, it is by no means small, which requires adapting this methodology to support the development of this type of applications. Even though it also seems that XP is concentrated more on the programmers than on the clients, this should also be adapted to SOA, as SOA is firmly concentrated on providing better services easily to an end user that most likely, won't be the developer's costumer. In conclusion, although XP seems to provide results productivity wise, the adaptation to SOA development (in theory) would require changing many of it's main

7 principles so the development of this kind of applications can be effective (providing an operable SOA) and efficient (faster and with less problems while developing). 3 Relational Unified Process (RUP): The Relational Unified Process is an agile software development method created by Philippe Kruchten, Ivar Jacobsen and others at Rational Corporation to complement the Unified Modifying Language (UML an industry standard modeling method). Even though the methodology is mostly focused on the object oriented paradigm, it does not implicitly rule out the other methodologies for designing software [13] As stated previously, this software development methodology is considered agile as it is able to comply with all the requirements needed for an agile methodology (adaptive, straightforward, incremental and cooperative) many believe that this method is too robust to be called agile, as it has various design phases and it takes too long to provide a final version. But, as this is also a step of rules and best practices, developers can get to choose the parts they believe would benefit the development process [9]. The RUP development process consists of four phases, which are split into (usually many) iterations, where each one of them has the purpose of producing a demonstrable part of the software project. The phases are [12]: Inception: Here, the needs of every stakeholder are taken into account. This helps find all critical use cases, candidate architectures for the system are schemed and also estimations are provided. Elaboration: In this phase is where the foundation of the software architecture takes place. The architecture is elaborated with the output of the previous phase. The project plan is elaborated while the process, infrastructure and development environment are identified. At the end of this phase, most use cases and actors are identified and described, the complete architecture is described and a prototype of it has been created. Construction: In the construction phase, all the remaining components and applications are developed, integrated into the product and are tested. Transition: The process concludes with this phase, which is essentially the release of the product. And also, according to user response, modifications and the addition of extra features takes place as well as the writing of manuals and such. What it is to note, is that through all these phases, there are nine work flows that are parallel to the phase. In each iteration, usually in extensive manner, all this work flows are addressed. The work flows are: business modeling, requirements, analysis and design, implementation, test, configuration and change management, project management and environment [12]. The methodology consists essentially that in every phase of the development life cycle, each part of the development has to be consistent and done methodically, not

8 escaping any detail or potential error. This, even though takes probably a lot of time, it provides software that is likely to be consistent with the previously stated model that, after a lot of time in it, contains all the necessary information to provide the costumer with the software applications he desires. To also help in the development process, the methodology follows the next practices [12]: Develop Software Iteratively: Develop the software in small increments and short iterations to detect potential risks and problems early. Manage Requirements: Identify the most important requirements before coding; the ones that change over time and have the biggest impact. Among it's benefits are detection of inconsistencies and improved communication, as the requirements are clearly defined. Use Component Based Architectures: Improved flexibility in development and also reduction in future development efforts are among the benefits of isolating code that will most likely change over time or that many resources share. Visually Model Software: Using common visualizations, a clear and common language is established among the developing members. Improving communication and common understanding. It also helps developers to not lose track of the project in the development process. Verify Software Quality: By testing every iteration, defects and bugs can be detected even before the development cycle, reducing resources in maintenance. Control Changes to Software: All changes to requirements should be managed and their effect on software traced, as this improves the understanding of the current situation of the application. As a summary, RUP consists of a robust methodology, were small iterations, elaborate modeling sessions, constant testing and a common design language can be the better solution for creating software applications of great quality, error free and that meet all the costumer requirements. 3.1 Comparison of RUP with SOA Benefits: As it was compared previously when comparing SOA development necessities with XP, there is a need for proper documentation to keep track of all the requirements, changes, and possibilities when designing services, or SOA type applications, and this is what RUP provides: a methodology that is mainly focused on initial requirements, modeling and documentation, while also keeping the agile software development method's principles. Other than fact of providing an up front documentation, where states the requirements and the most important areas of development; which are useful to state the situation where the company is, it's best practices, and how to provide a visual connection of all the services. Another big benefit of this methodology is that one of it's practices is that it encourages component based architectures. This components are the building blocks for services, which means that this

9 methodology is at least concerned on some of the key elements of SOA: re usability, abstraction of business processes, flexibility, and code that is loosely coupled and finely grained [1]. 3.2 Comparison of RUP with SOA Drawbacks: The main drawbacks of using RUP to create SOA type applications is the fact that RUP is mostly object oriented (at least in design), which is not adequate for service modeling, as services include many other factors that object oriented design leaves out. A couple of examples are the aggregation of services to combine composite services that can, act as a service themselves, also the fact that it ignores underlying infrastructure (protocols, location and technologies), service management, etc. [1][3] Other visible drawback in applying RUP is the lack of agility (in comparison with other methodologies), as this methodology is far more robust and requires much more to do in every iteration than in other software developing methods. Even though, this may not be considered as significant drawback, sometimes a more agile model could be of use if the need for an SOA application is immediate. Related to the last drawback, the fact that RUP doesn't have any real mention of how to adapt the methodology to a software project while considering the circumstances of it and it's environment, leaving this task up for the developers. In the case of SOA, a rigid methodology would do more than fine, specially on the current situation of SOA applications, but in the near future, the rapid creation of such applications might be an increasing need that, unless having the proper combination of principles or an adequate adaptation to SOA, might stop developers from picking this methodology [6]. 3.3 Discussion of Areas of Improvement for the Development of SOA Type Software (RUP): The main area of improvement is the creation of a proper modeling technique that can be adequate for the creation SOA type applications. The combination of the RUP principles, with a proper business modeling approach would provide much better background for the development of these applications. It's also convenient to mention that this modeling technique should also consider the aspects mentioned previously, such as service composition, management, gap analysis, focus on service coupling, cohesion and granularity as design principles, service versioning and governance [1]. Also the creation of proper tools that can ease the development of SOA type applications, specially one that can automatically analyze business processes in detail, discovering and selecting suitable external services, interaction problem detection, alternative solution search, service monitoring, etc. In my opinion, this can help in the way UML tools help in RUP. 4 Discussion:

10 As it can be seen in the discussion paragraphs, both software development method have different advantages, disadvantages, and places for improvement in SOA software specific development. The main requirements needed, in both methodologies include a moderate balance between quick iterations and no documentation or design, and between long iterations and large quantities of documentation, and as well the use of a Service Oriented design method. Currently, there is no such thing as Service Oriented design method, but research is carried out [1]. It is also up to discussion the possibilities of also researching an specific software development method for SOA software. But the implementation of current software development methods seems to be more than adequate, considering it's large number of advantages, it's all about finding the proper best practices that can be well suited for SOA development, this of course takes research time, as well as practice from enterprises. There is no clear advantage, or any for that matter, that one of both Software development methodologies reviewed in this article are better for SOA software development, they seem, in this case, to provide different types of advantages according to the type of task (XP small software projects while large RUP object oriented projects, both in uncertain environments). This can indicate that the proper combination of these two methodologies, as well as adding a service oriented documentation/design methodology, can be enough for the development of SOA software. It is my opinion that states that the use of RUP, for the design (using service oriented methodologies), development and maintenance of the main architecture of SOA software, while using XP for the creation and composition of services, is sufficient to provide the advantages of both methodologies, and would be enough to maintain all possible requirements in software development. 5 Conclusions: As it can be seen, both software development methods are quite different, but still carry out the same objectives either way. Anyway, for SOA software development, some analysis must be done to choose the proper system for the development of such software type. A table comparing both methods, as well as SOA software requirements is shown in Table 1. Table 1. Comparison of SOA Software Development with XP and RUP software development processes. Characteristic SOA XP RUP Size of development team It is likely to require large multi disciplinary teams. Small tightly communicated teams Large teams Level of documentation Extremely high considering legacy systems and requirements None, all based on direct communication with a costumer. High, all possible descriptions of the system

11 Development time Type of software it's focused on. Type of orientation Long, at least while designing the Architecture, but will be small when the architecture is in place. Quick iterations for quick development development Long, but steady development Enterprise Small, Costumer based Any size Service Any, no real methodology behind it Object As a summary, neither XP or RUP, in their complete extension, are not software development methods completely adequate for SOA software development, as there are characteristics they miss and can take into account for SOA software specific development. Even though, currently, there is no SOA specific development method, in my opinion, the use of the best business practices from current methodologies seems like the best bet for current SOA development. Finally, Table 2, summarizes graphically all that was explained in the previous sections. Table 2. Comparison of XP and RUP software development processes, considering Advantages, Disadvantages, etc. Characteristic XP RUP Advantages Fast iterations and development. Direct communication with the costumer. Disadvantages Does not consider any documentation. Focused at small projects. Possible changes to fit SOA. Slight use of a methodology and design will be useful. Concentrate on the service creation side of SOA development. Considering bigger working groups Consistent methodology. Large amounts of design and preparation. Focused on large projects. Too robust and long development process and iterations. It mostly object oriented. Change the methodology and design features to a Service Oriented one Concentrate on the Architecture development of SOA.

12 References: 1. Papazoglou, Michael P., Traverso, P., et al.: Service Oriented Computing Roadmap. Dagstuhl Seminar Proceedings Service Oriented Computing (SOC). (2006). 2. Maceheiter, N., Ward Dutton N.: Real SOA: Critical Success Factors. Macehiter Ward Dutton. (2005). 3. Hurtwitz, J., Bloor R., Baroudi C.: Service Oriented Architecture for Dummies. Willey Publishing Inc. (2006). 4. Chesbrough, H., Spohner, J.: A Research Manifesto For Services Science. Communications of the ACM. Vol.49, No.7. July (2006). 5. Sheehan, J.: Understanding Service Sector Innovation. Communications of the ACM. Vol.49, No.7. July (2006). 6. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J.:Agile software development methods Review and analysis. VTT Publications 478. Espoo, Finland. (2002). 7. Beck, K.: Embracing Change With Extreme Programming. IEEE Computer 32(10): (1999). 8. Beck, K.: Extreme programming explained: Embrace change. Reading, Mass., Addison Wesley. (1999). 9. Stephens, M.: The Case Against Extreme Programming. August 26, (2001). Last updated: January 26, (2003). 10. Stephens, M., Rosenberg, D.:, Extreme Programming Re factored: The Case Against XP, Apress, (July, 2003). 11. Maurer, F. and Martel, S.: On the Productivity of Agile Software Practices: An Industrial Case Study. (2002). 12. Kruchten, P. : The Rational Unified Process: an Introduction. Addison Wesley. (2000). 13. Jacobsen, I., Christerson, M., Jonsson, P. and Overgaard, G.: Object Oriented Software Engineering: A Use Case Driven Approach. Reading, MA, Addison Wesley. (1994).