Unified process phases pdf

Rational Software originally developed the rational unified unified process phases pdf 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 based 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. The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. Requirements understanding as evidenced by the fidelity of the primary use cases. Depth and breadth of any architectural prototype that was developed.

Establishing a baseline by which to compare actual expenditures versus planned expenditures. If the project does not pass this milestone, called the life cycle objective milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria. The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed.

A description of the software architecture in a software system development process. Business case and risk list which are revised. A development plan for the overall project. Prototypes that demonstrably mitigate each identified technical risk.