Rational Unified Process

History

• a tailorable process that guided development
• tools that automated the application of that process
• services that accelerated adoption of both the process and the tools.

1. business modeling, much of this content had already been in the Objectory Process
2. a Configuration and Change Management discipline, sourced through the acquisition of Pure Atria Corporation.

1. Develop iteratively, with risk as the primary iteration driver
2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes

1. the introduction of concepts and techniques from approaches such as eXtreme Programming, that would later come to be known collectively as agile methods. 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.
2. a complete overhaul of the testing discipline to better reflect how testing work was conducted in different iterative development contexts.
3. the introduction of supporting guidance - known as "tool mentors" - for enacting the RUP practices in various tools. These essentially provided step-by-step method support to Rational tool users.
4. automating the customization of 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.

Rational unified process topics

RUP building blocks

• Roles – A role defines a set of related skills, competencies and responsibilities.
• Work products – A work product represents something resulting from a task, including all the documents and models produced while working through the process.
• Tasks – A task describes a unit of work assigned to a Role that provides a meaningful result.

• Six "engineering disciplines"
• * Business modelling
• * Requirements
• * Analysis and design
• * Implementation
• * Test
• * Deployment
• Three supporting disciplines
• * Configuration and change management
• * Project management
• * Environment

  Four project life-cycle phases

Inception phase

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Requirements understanding as evidenced by the fidelity of the primary use cases.
• Credibility of the cost/schedule estimates, priorities, risks, and development process.
• Depth and breadth of any architectural prototype that was developed.
• Establishing a baseline by which to compare actual expenditures versus planned expenditures.

Elaboration phase (Ortner)

• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process.
• An executable architecture that realizes architecturally significant use cases.
• Business case and risk list which are revised.
• A development plan for the overall project.
• Prototypes that demonstrably mitigate each identified technical risk.
• A preliminary user manual

• Is the vision of the product stable?
• Is the architecture stable?
• Does the executable demonstration indicate that major risk elements are addressed and resolved?
• Is the construction phase plan sufficiently detailed and accurate?
• Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
• Is the actual vs. planned resource expenditure acceptable?

Construction phase

Transition phase

The IBM Rational Method Composer product

Certification

Six best practices