RUP - A process model for working with UML

Abstract

Recently, the Rational Unified Process (RUP) has been published as the second part of Rational’s Unified Method project. The RUP is advertised as an “iterative and incremental, use case-driven, architecture-centric” process model and aims to support system designers, builders and managers working with the Unified Modeling Language (UML) by a procedural guideline. In this chapter, a brief review and a critical analysis of the RUP is attempted. Its general aim and its contribution towards more harmonisation in the software process field are acknowledged. However, its ability to reduce the complexity of software development and to clarify its interlaced structure and terminology is doubted. Major problems may result from concepts not clearly specified like workflow or architecture. In particular, RUP core concepts like phase, iteration, workflow and milestone are debated. It is argued that RUP phases and milestones do not support the requirements of modern object-oriented (and, in particular, component-based) software projects. Iteration cycles should be based on software building blocks rather than on phases and activities. As one possible alternative to the RUP, a component-based (and truly architecturecentric) process model is sketched, and a multi-variant approach to software process modelling is recommended. INTRODUCTION: THE “UNIFIED PROCESS,” ITS HISTORY AND AIMS In the mid-'90s Rational company has started a project trying to merge some existing methodologies for object-oriented analysis and design into a common “Unified Method.” For this purpose their chief methodologist G. Booch, joined by J. Rumbaugh and (later) by I. Jacobson, tried to combine their methods which became popular at that time. Realizing that this goal was not to be achieved, within one single step the authors reduced their ambitions and started with a common metamodel and notation, an approach which resulted