RATIONAL UNIFIED PROCESS What Is RUP (Cont)? Best Practices Overview of RUP the Time Dimension

• Rational Unified Process© (RUP) is a RATIONAL UNIFIED software engineering process • Goal: to ensure the production of high- PROCESS quality software that meets the needs of its end-users within a predictable schedule and budget • Developed and maintained by Rational® Software

What is RUP (cont)? Best Practices

• Enhances team productivity by providing team members with easy access to a knowledge base • RUP effectively deployment of six best – Guidelines practices, among others – Templates – Tools – Develop software iteratively • Creates and maintains models – semantically rich – Manage requirements representations of the software system under development – Use component-based architectures • Guides the team how to effectively use UML – Model software visually • Is supported by tools which automate large parts of the process – Verify software quality • Is a configurable process that can adapt to large and small teams and projects – Control change of software • Captures many of the industry best practices

Overview of RUP The Time Dimension

• Two dimensions, time and content • The software life-cycle is broken into cycles, each of which involves a new generation of the – The time dimension represents the progress product of the process as it is enacted, and is • Each cycle is divided into four phases in RUP expressed in terms of cycles, phases, – Inception phase iterations, and milestones. – Elaboration phase – Construction phase – The content dimension represents what is – Transition phase being done along the respective time • Each phase is concluded with a well-defined dimension. milestone – a point in time at which certain critical decisions must be made and key goals must have been achieved

1 Two Dimensions of RUP The Content Dimension

• Core process workflows – Business model – Requirements – Analysis & design – Implementation –Test – Deployment

The Content Dimension (cont) Some Details of Time Dimension

• Core supporting workflows • Inception phase: establish the business case for – Configuration & change management the system and delimit the project scope – Identify all external entities with which the system will – Project management interact – Environment – Identify all use cases – Specify success criteria – Assess risks – Estimate resources needed – Develop a plan showing dates of major milestones

Inception Phase (cont) Inception Phase (cont)

• Outcome of the inception phase (milestone) • Project milestone: the Lifecycle Objectives – A vision document: a general vision of the core Milestone project’s requirements, key features, and main • Evaluation criteria constrains – Stakeholder concurrence on scope definition and – A initial use-case model (10%-20% complete) cost/schedule estimates – An initial project glossary – Requirements understanding as evidenced by the – An initial business case which includes business fidelity of the primary use cases context, success criteria (revenue projection, market – Credibility of the cost/schedule estimates, priorities, recognition …), and financial forecast risks, and development process – An initial risk assessment – Depth and breadth of any architectural prototype that – A project plan showing phases and iterations was developed – A business model if necessary – Actual expenditures versus planned expenditures – One or several prototypes

2 Elaboration Phase Elaboration Phase (cont)

• Analyze the problem domain • The outcome of the elaboration phase – A use-case model (at least 80% complete) – all use cases and actors have been identified, most use case descriptions have • Establish a sound architectural foundation been developed • Develop the project plan – Supplementary requirements capturing the non-functional requirements and any requirements that are not associated with • Eliminate the highest risk elements of the a specific use case – A software architecture description project – An executable architecture prototype – A revised risk list and a revised business case • “mile wide and inch deep” view of the – A development plan for the overall project, including the coarse- system grained project plan, showing iterations and evaluation criteria for each iteration • An executable architecture prototype is – An updated development case specifying the process to be used built in one or more iterations – A preliminary user manual (optional)

Elaboration Phase (cont) Construction Phase

• Project milestone: the Lifecycle Architecture Milestone • All components are developed and integrated • Evaluation criteria into the product – Stability of the vision of the product • All features are thoroughly tested – Stability of the architecture – Demonstration of the executable showing that the major risk • Parallel constructions are possible, depending elements have been addressed and credibly resolved on the size of the project – Sufficiently detailed and accurate construction phase – Agreement of the stakeholders that the current vision is • The outcome of the construction phase achievable in the context of the current architecture – The software product integrated on the adequate – Actual resource expenditure versus planned expenditure platforms acceptable – The user manuals – A description of the current release

Construction Phase (cont) Transition Phase

• Project milestone: Initial Operational • Transition the software product to the user community Capability Milestone • Issues usually arise that require new releases, • Evaluation criteria correct problems, or finish the features that were postponed – Is this product release stable and mature • Primary objectives enough to be deployed in the user community – Achieving user self-supportability – Are all stakeholders ready for the transition – Achieving stakeholder concurrence that deployment baselines are complete and consistent with the into the user community evaluation criteria of the vision – Are the actual resource expenditures versus – Achieving final product baseline as rapidly and cost planned expenditures still acceptable effectively as practical

3 Transition Phase (cont) Transition Phase (cont)

• Expected results • Project milestone: the Product Release – “beta testing” to validate the new system Milestone against user expectations • Evaluation criteria: – Parallel operation with a legacy system that it – Is the user satisfied is replacing – Are the actual resource expenditure versus – Conversion of the operational databases planned expenditure still acceptable – Training of users and maintainers – Roll-out the product to the marketing, distribution, and sales teams

Iterations Time Distribution

• Although no projects are the same, time distribution is • Each phase in RUP can be further divided roughly the following into iterations • Inception: effort 5% schedule 10% – Business modeling •An iteration is a complete development – Requirement loop resulting in a release (internal or • Elaboration: effort 20% schedule 30% – Analysis external) of an executable product –Design • Construction: effort 65% schedule 50% • A subset of the final product, which grows – Implementation incrementally from iteration to become the – Testing • Transition: effort 10% schedule 10% final system – Deployment

Workers and Activities Life-cycle Artifacts

• Worker: a worker defines the behavior and • RUP is not document-driven responsibilities of an individual, or a group of • Main artifact should be software product individuals working together as a team itself – One person can be in multiple roles • Documentation should remain lean and • Activity: an activity of a specific worker is a unit limited to the few that bring real value of work that an individual in that role may be asked to perform • Two main categories of artifacts besides the software • Artifact: an artifact is a piece of information that is produced, modified, or used by a process • Management artifacts and technical artifacts

4 Life-cycle Artifacts (cont) Life-cycle Artifacts (cont)

• Management artifacts –An Organizational Policy document which is the codification of the • Technical artifacts organization’s process –A Vision document which describes the system level requirements, – User’s Manual: developed early in the life- qualities and priorities cycle –A Business Case document which describes the financial context, contract, projected return on investment and others – Software Documentation: preferably in the –A Development Plan document which contains in particular the overall iteration plan, and plan for the current and upcoming iteration form of self-documenting source code –An Evaluation Criteria document which contains the requirements, acceptance criteria and other specific technical objectives –A Software Architecture document: extracted – Release Description documents for each release from the software documentation describing – Deployment document which contains additional information useful for transition, training, installation, sales, and others the overall structure of the software, its – Status Assessment documents which contains periodic snapshots of decomposition in major elements, and project status with metrics of progress, staffing, expenditure, results, critical risks, actions items and others rationale for the key design decisions

Workflows – the content dimension Workflows (cont)

• Core process workflows • Business modeling: – Business model – Common language (vocabulary) between business – Requirements section and technical section – Analysis & design – Business use cases – Implementation • Requirements: –Test – What the system should do – Deployment • Core supporting workflows –A vision document – Configuration & change management – Actors are identified, entities that may interact with the system being developed – Project management – Environment – Use cases are identified, representing the behaviors of the system

Workflows (cont) Workflows (cont)

• Analysis and design: • Implementation: – Show how the system will be realized in the – Define the organization of the code implementation phase – Implement classes and objects – Result in a design model and optionally an analysis model – Test developed components as units – The design model consists of design classes – Integrate tested components into the system structured into packages with well defined interfaces –An architecture is formed as the result of design

5 Workflows (cont) Workflows (cont)

•Test: • Deployment: – Test for reliability, functionality, application – Product releases, delivery of the software to the users performance and system performance – Producing external releases of the software – Verify the interaction between objects – Packaging the software – Distributing the software – Verify the proper integration of all components – Installing the software – Verify that all requirements have been – Providing help and assistance to users (training) correctly implemented – Planning and conducting beta tests – Identify defects and ensure they are – Migrating of existing software or data addressed before release of the software – Formal acceptance

Workflows (cont) Workflows (cont)

• Project management: • Configuration and change management: – The art of balancing competing objectives, – How to control the numerous artifacts produced by managing risks, overcoming constraints to the many people who work on a common project deliver a product that meets the needs of – Issues include customers and users • Simultaneous update – A framework for managing software-intensive • Limited notification projects • Multiple versions – Practical guidelines for planning, staffing, – Manage parallel development, multiple sites, automate build process executing, and monitoring projects – Keep an audit trail on why, when and by whom any – A framework for managing risk artifact was changed

Workflows (cont) RUP Products

• Environment: • RUP is not just a concept. Many products exist to support it. – Provide processes and tools needed to • Resources include support the development team – A web-enabled searchable knowledge base providing all team members with guidelines, templates, and tool – Configure the process in the context of a mentors for all critical development activities project • Extensive guidelines • Tool mentors – Manage a Development Kit providing the • IBM Rational Rose®: examples of templates team with guidelines, templates, and tools • IBM Rational SoDA®: templates that help automate software documentation necessary to customize the process • Microsoft ® Word templates: templates to assist documentation in all workflows and all portions of life cycle

6 RUP Product (cont) RUP Product (cont)

• Resources include (cont) • Tool mentors: step-by-step guide describing how to operate a tool – Microsoft Project Plans: templates to help jump start – IBM Rational Requisite Pro -- keeps the entire development team updated, and on track throughout the application development process by the creation of a project plan making requirements easy to write, communicate and change – Development Kit: description of how to customize and – IBM Rational ClearQuest -- a Windows and web-based change-request management product that enables project teams to track and manage all change extend the RUP to the specific needs of the adopting activities that occur throughout the development life cycle – IBM Rational Rose 98 -- a visual modeling tool for business process organization or project, and a set of tools assisting the modeling, requirement analysis, and component architecture design efforts – IBM Rational SoDA -- automates the production of documentation for the entire software development process, dramatically reducing documentation time – Resource center containing the latest white papers, and costs updates, hints, and techniques – IBM Rational Purify -- a run-time error checking tool for application and component software developers programming in C/C++ – A book “Rational Unified Process – An Introduction” by Philippe Kruchten, published by Addison Wesley

RUP Product (cont) A Brief History of RUP

• Tool mentors: step-by-step guide describing how to 198x Objectory process from Ivar Jacobson, developed and marketed operate a tool by Objectory AB in Sweden – IBM Rational Visual Quantify – an advanced performance profiling tool for 1992 Simplified version of Objectory published in Ivar Jacobson’s book application and component software developers programming in C/C++, Visual Basic, and Java Object Oriented Software Engineering – IBM Rational Visual PureCoverage – automatically pinpoints areas of Oct 1995 Rational buys Objectory AB and with it Objectory V3.8 code not exercised in testing so developers can thoroughly, efficiently and effectively test their applications Oct 1996 Rational Objectory Process (ROP) Version 4.0, Adds iterative – IBM Rational TeamTest – creates, maintains and executes automated functional tests, allowing the developing team to thoroughly test the code and development and software architecture determine if the software meets requirements and performs as expected Sep 1997 Rational Objectory Process (ROP) Version 4.1, UML replaces – IBM Rational PerformanceStudio – an easy-to-use, accurate and Objectory notation scalable tool that measures and predicts the performance of client/server and web systems Nov 1998 Rational Unified Process (RUP) Version 5.0, Adds business – IBM Rational ClearCase – a software configuration management tool, modeling, extensions in project management giving project managers the power to track the evolution of every software development project 1999-2002 Many new versions (5.1, 2000, 2001, 2002)

June 2003 RUP 2003 (current version)