The competition in the software industry is ruthless; and many software corporations are striving to provide quality of the products to its customers. Quality can be achieved through the use of a process models, which dictates what needs to be done, when and how. This paper discusses whether Rational Unified Process (RUP) methodology would be the best choice for the XYZ’s eCommerce project proposal and also analyzes RUP’s compatibility with the Zachman framework.

The Rational Unified Process (RUP) model is a two dimensional model, which provides a realistic, well-defined system development process, often used to develop systems based on object and/or component-based technologies. It is based on sound software engineering principles such as taking an iterative, requirements driven, and architecture-centric approach to software development (Kruchten 2004). It provides several mechanisms, such as relatively short-term iterations with well-defined goals and go/nogo decision points at the end of each phase, to provide management visibility into the development process (Ambler, 2005).

Since the goal of RUP is to enable the development of quality software within predictable schedules and budgets, it unifies the software best practices that can be adapted for a wide range of projects and organizations. Some of the reasons as to why it’s the best choice for this project is that it is based on the waterfall model and easy to comprehend; customization of the process is well described and so organizations can adapt the process to suit any type of projects; supports an organization that is trying to achieve CMM Level-2 and CMM Level-3 software process maturity levels; and provides detailed guidance on how to effectively use Rational tools.

The Rational Unified Process is an incremental process. The overall project is broken down into phases and iterations i.e. inception is the phase in which the scope of the project is determined and the business case is defined; elaboration focuses on defining and validating a robust architecture to eliminate technical risk and uncertainty; construction is the phase in which the product is built where functionality is incrementally added to the architectural baseline; and transition is the phase in which the product is delivered to end users. Iterations are risk driven and oriented toward mitigating those risks. Each one should deliver executable software that is demonstrable and testable against the project requirements and use cases (Ambler 2001, 2005).

If we consider the Rational Unified Process as a software development process, we can apply the Zachman Framework to determine its effectiveness in terms of its coverage of software development deliverables. The MUL interaction diagrams are used to describe how the user will interact with the system, through the use of forms that are represented as boundary object classes (Ambler 2004). This can be achieved and represented by reordering the columns of the Zachman Framework, however, because the RUP has both static and dynamic dimensions. This minor adjustment has no effect on the Framework itself because there are no dependencies between columns, but it does make the results more readable (de Villiers, 2001).

The Rational Unified Process describes workflows in terms of roles, artifacts, and activities. Due to the artifact-driven nature of the RUP, the selection of artifacts for a particular instance of the process, or development project, drives the selection of roles and activities. This implies relationships between the What, Who, and How columns that cannot be represented within the Zachman Framework adequately. That is, there is no precise way of mapping the defined artifacts onto the Zachman Framework. Because some artifacts address more than one cell in the matrix and some combinations or sets of artifacts address only one cell. Hence, it may not truly represent the purpose of the project (de Villiers, 2001).

In addition, RUP is not applicable in every project situation i.e. it does not cover any non-software aspects of project development, e.g., system engineering, product-line engineering, safety engineering. RUP besides does not state clearly how to deal with non-functional requirements. The fact that the RUP is a 'use case driven' process could also lead its adopters to put more effort to the User Interface development than into software testing (Unified Process, 2005 ).

Despite the limitations of Rational Unified Process methodology for software development, it has some significant advantages over other methodologies and works quite well with the Zachman Framework to produce adequately acceptable results.

References:

Ambler, S.W. (2001). Enhancing the Unified Process. Software Development, October 
2001. www.sdmagazine.com/documents/s=753/sdm9910b/9910b.htm

Ambler, S.W. (2004). The Object Primer 3rd Edition: Agile Model Driven Development  with UML 2. New York: Cambridge University Press.  www.ambysoft.com/theObjectPrimer.html

Ambler, S.W. (2005). Manager's Introduction to the RUP, December 4, 2005.
http://www.ambysoft.com/downloads/managersIntroToRUP.pdf 
http://www.ambysoft.com/unifiedprocess/rupIntroduction.html

Kruchten, P. (2004). The Rational Unified Process 3rd Edition: An Introduction.
Reading, MA: Addison-Wesley Longman, Inc.

Unified Process, 30 May 2006.
http://en.wikipedia.org/wiki/Rational_Unified_Process

De Villiers D. J. (2001), Using the Zachman Framework to Assess the Rational Unified Proces. The Rational Edge
http://www.therationaledge.com/content/mar_01/t_zachman_dv.html