RUP started in the mid-1990s as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle. However over time, Rational (and subsequently IBM Rational) added additional guidance and artifacts to extend the applicability of RUP to all sorts of situations, such as package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types. In practice RUP suffered from several problems:
- RUP became unwieldy and hard to understand and apply successfully due to the large amount of disparate content.
- RUP was often misappropriately instantiated as a waterfall (with Inception as a big requirements up front (BRUF) phase, Elaboration as a detailed architecture phase, and Transition as a testing phase.
- RUP was often misappropriately instantiated in a heavy and onerous manner.
Yes, RUP properly applied in the right circumstances can be very effective. Unfortunately though, that often did not happen in practice.