Rational Unified Process (RUP) started in the mid-1990s as a small manageable process framework. RUP was targeted specifically for building software within the context of an iterative lifecycle.
A Very Brief History of The Rational Unified Process
RUP quickly became the dominant process in the late 1990s, but was eclipsed by agile ways of working (WoW) in the early 2000s. RUP was effectively retired by IBM Rational in the early 2010s. Yes, RUP properly applied in the right circumstances could be very effective. Unfortunately, that often did not happen in practice.
Why RUP Lost the “Process Wars”
Over time, Rational (and subsequently IBM Rational) added additional guidance and artifacts to extend the applicability of RUP. This included 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 inappropriately instantiated as a waterfall. Inception was a big requirements up front (BRUF) phase, Elaboration a detailed architecture phase, and Transition as a testing phase.
- RUP was often inappropriately instantiated in a heavy and onerous manner.
I Had Skin in the RUP Game
For it’s time RUP was an incredible resource. I did what I could to explain how to apply it effectively and to extend it where appropriate. In fact, I (co-)wrote five books specifically on this subject.