Rational Software originally developed the rational unified process as a software process product. Rational technical representative was tasked with heading up the original RUP team. This guidance was augmented in subsequent versions with knowledge ibm software products list pdf on the experience of companies that Rational had acquired.
In 1997, a requirements and test discipline were added to the approach, much of the additional material sourced from the Requirements College method developed by Dean Leffingwell et al. SQA Process method developed at SQA Inc. Configuration and Change Management discipline, sourced through the acquisition of Pure Atria Corporation. These best practices were tightly aligned with Rational’s product line, and both drove the ongoing development of Rational’s products, as well as being used by Rational’s field teams to help customers improve the quality and predictability of their software development efforts. Additional techniques including performance testing, UI Design, data engineering were included, and an update to reflect changes in UML 1. In 1999, a project management discipline was introduced, as well as techniques to support real-time software development and updates to reflect UML 1. Between 2000 and 2003, a number of changes introduced guidance from ongoing Rational field experience with iterative development, in addition to tool support for enacting RUP instances and for customization of the RUP framework.
This included techniques such as pair programming, test-first design, and papers that explained how RUP enabled XP to scale for use on larger projects. RUP practices in various tools. These essentially provided step-by-step method support to Rational tool users. RUP in a way that would allow customers to select parts from the RUP process framework, customize their selection with their own additions, and still incorporate improvements in subsequent releases from Rational. IBM acquired Rational Software in February 2003.
RUP is based on a set of building blocks and content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. A role defines a set of related skills, competencies and responsibilities. A work product represents something resulting from a task, including all the documents and models produced while working through the process. A task describes a unit of work assigned to a Role that provides a meaningful result. The RUP has determined a project life-cycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a ‘waterfall’-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished.