Rational Unified Process - Assignment Example

Rational Unified Process Introduction This work is intended to describe Rational Unified Process and compare its application with one of the Real World Software Process to development of Airline Information Management System (AIMS) that is envisioned to provide a single, integrated environment for dealing with all aspects of Ansett Airline’s operation. Description of Rational Unified Process Kroll and Kruchten (2003) regard the RUP as three different things: The RUP is a software development approach that is iterative, architecture-centric, and use-case-driven. The RUP is a well defined and a well-structured software engineering process. The RUP is also a process product that provides you with a customizable process framework for software engineering. (Kroll and Kruchten, 2003) In general, the Rational Unified Process describes how to effectively deploy commercially proven approaches to software development for software development teams. These are called "best practices" not so much because you can precisely quantify their value, but rather, because they are observed to be commonly used in industry by successful organizations. The Rational Unified Process provides each team member with the guidelines, templates and tool mentors necessary for the entire team to take full advantage of among others the following best practices: Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software (Rational Unified Process: Best Practices for Software Development Teams 2000) Overview of Rational Unified Process Kroll and Kruchten (2003) write that at the core of the Rational Unified Process lie several fundamental principles that support successful interactive development and that represent the essential “Spirit of the RUP”: Attack major risks early and continuously Ensure that you deliver value to your customer Stay focused on executable software Accommodate change early in the project Baseline an executable architecture early on Build your system with components Work together as one team Make quality a way of life, not an afterthought (Kroll and Kruchten, 2003, pp. 8-12) History of Rational Unified Process The RUP is an endeavour of IBM's Rational division, formerly Rational Software Corporation. Rational is best known for its development toolset and as the initial developers of the Unified Modeling Language (UML). The UML is now maintained by the Object Management Group (OMG). Critical events in the evolution of the Rational Unified Process are: 1988: Objectory v1.0 is defined by Ivar Jacobson's Objectory AB company. The Objectory process defined the core process from which the RUP and later the EUP evolved. 1995: Objectory v3.8 releases their first online version and Rational Corporation purchases Objectory AB. June 1998: Rational Unified Process (RUP) 5.0 is released. This is the renamed ROP, extended with process material obtained from other tool companies purchased by Rational Corporation as well as material developed by the RUP group led by Phillipe Kruchten. October 1999: An enhanced lifecycle for the RUP is first proposed by Scott Ambler, which extends the RUP with a production phase and a cross-system discipline called Infrastructure Management. February 2000: RUP 2000 is released. Major enhancements include the addition of business engineering techniques to the business modeling discipline and a more extensive approach to requirements. 2000-2002: The Unified Process series of books, edited by Scott W. Ambler and Larry Constantine, is published. This series repositions the enhanced RUP lifecycle as the EUP. December 2002: IBM purchases Rational Corporation. May 2003: RUP 2003 is released. Some of the material from the Unified Process series, in particular an enhanced test discipline and some agile concepts, are now covered by the RUP. February 2005: Release of the Enterprise Unified Process: Extending the Rational Unified Process by Prentice Hall PTR. September 2005: The Agile Unified Process (AUP) product is announced at Software Development Best Practices in Boston. October 2005: The Eclipse Project Framework (EPF) and Basic Unified Process (BUP) announced by IBM. November 2005: The Rational Method Composer (RMC) is announced by IBM. For more information, read Peter Haumer's IBM Rational Method Composer: Key Concepts. (Ambler, S.W., 2006) Structure of Rational Unified Process The RUP can be described in two dimensions, or along two axes: The horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones. The vertical axis represents the static aspect of the process: how it is described in terms of activities, artifacts, workers and workflows. The software lifecycle is broken into cycles, each cycle working on a new generation of the product. The Rational Unified Process divides one development cycle in four consecutive phases. Inception phase Elaboration phase Construction phase Transition phase Each phase is concluded with a well-defined milestone--a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved. A process also describes who is doing what, how, and when. The Rational Unified Process is represented using four primary modeling elements: Workers, the "who" Activities, the "how" Artifacts, the "what" Workflows, the "when" (Kroll and Kruchten, 2003, pp. 14-25) Type of Projects for which the Rational Unified Process is Applicable Kroll and Kruchten (2003) write that the RUP is a flexible, versatile process framework, which can be tailored to suit the needs of development projects of all types and sizes. They also give three examples of successful RUP application to small, medium and huge projects. Breadth of Current Usage of Rational Unified Process Although RUP can be applied to small, medium and huge projects, more often it is used for big commercial projects, because it was developed for complex and long-term projects with big teams. Nevertheless, some of RUP best practices are successfully used in relatively small projects, especially in education sector. (Alhir, 2002) Target Market of Rational Unified Process Bloomberg (2000) names e-business as a core target market of RUP application. He writes that building an e-business is building a Web site, with all the human processes involved in using and supporting that site - what he calls a Web solution. Bloomberg (2000) proves that RUP builds requirements for software packages in the human context of use cases, which describe how people will interact with the system; RUP is also iterative, and integrates quality throughout its process. Pros and Cons of Using the Rational Unified Process The main argument for using RUP is ability of full control of the system development. The main argument against using RUP is its price. I think an organization should use RUP only if it is specialized on huge commercial projects for e-business. Benefits of Using the Rational Unified Process for AIMS Booking System project The Rational Unified Process will provide each team member of AIMS Booking System project with the guidelines, templates and tool mentors necessary for the entire team to take full advantage of among others the RUP best practices. So control over the project will be achieved and the project will be controlled during all its life-cycle. Drawbacks of Using the Rational Unified Process for AIMS Booking System project The major drawback of RUP is its cost. Rational Software has a business model to go with the process. To use the formal RUP documentation and templates, it is necessary to buy the RUP methodology and tools, including the Rational Rose design tool. Paying for consultancy is also encouraged, and sometimes necessary, as RUP can require extensive customization. The RUP methodology, itself, is iterative: new versions come out regularly, with associated upgrade costs. Also, adopting RUP is often thought to be expensive. Then, RUP does not cover any non-software aspects of development -- e.g., system engineering, product-line engineering, safety engineering. If the users of RUP do not understand that RUP is a formal process that requires customization, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight "out of the box." Comparison of Rational Unified Process with RWSP Similarities Both RUP and RSWP have strict structure that makes project flow stable and predictable. Both of them include agile software development process that is ideal for small-to-medium scale application development. Both RUP and RSWP take a number of "best practices", and put them together into a simple, easy-to-follow process and implement it in an incremental and iterative model Differences While RUP requires from developer a long study, RWSP can be used by developers ranging from novices through to seasoned professionals. Also RWSP is free while for RUP it is necessary to buy the RUP methodology and tools. Conclusion It seems that Real World Software Process (RWSP) is more applicable for development of AIMS Booking System, because it best suits the needs of small-to-medium scale application development. RSWP has document support, and has been successfully used by a number of Australian-based companies and by over 1000 students in the Faculty of Information Technology at the Queensland University of Technology (QUT). (RSWP Website, 2002) Although RWSP has strict structure (Phase Zero, Phase One, Phase N and Finalisation) and takes many "best practice" software engineering concepts, the project manager can use judgment when deciding on the precise order of activities and tasks, and the way in which they are done. References 1. Alhir, S.S. (2002). Understanding the Unified Process (UP). Methods & Tools. Retrieved May 21, 2006 from http://www.methodsandtools.com/archive/archive.php?id=32 2. Ambler, S.W. (2006). History of the Unified Process. Retrieved May 21, 2006 from http://www.enterpriseunifiedprocess.com/essays/history.html 3. Bloomberg, J. (2000). Building E-businesses with the Rational Unified Process. Retrieved May 21, 2006 from http://www.rhodes.com/articles/ebiz.html 4. Rational Unified Process: Best Practices for Software Development Teams. (2000). Retrieved May 21, 2006 from Rational Software Corporation http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.html#1 5. Kroll P., Kruchten P. (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to Rational Unified Process. New York: Addison-Wesley Professional 6. Rational Unified Process. (2006). Retrieved May 21, 2006 from Wikipedia http://en.wikipedia.org/wiki/Rational_Unified_Process 7. Royce, W. (1998). Software Project Management: a unified framework. MA: Addison-Wessley. 8. RSWP Website. (2002). Retrieved May 21, 2006 from http://sky.fit.qut.edu.au/~rwsp/ 9. Software Development Magazine (2001). Retrieved May 21, 2006 from UML Design Center http://www.sdmagazine.com/uml/ 10. Zokaites, D. (2002). Writing Understandable Code. Software Development. Retrieved May 21, 2006 from http://www.sdmagazine.com/documents/s=2279/sdm0201b/0201b.htm Read More