RUP Overview Seyyed Jamaleddin Pishvayi seyyedjamalasta ir Objectives

RUP Overview Seyyed Jamaleddin Pishvayi seyyedjamal@asta. ir

Objectives: Rational Unified Process Overview Explain the role of process in software development. Explore the phase organization of Rational Unified Process and its relationship to iterative development. Explore the discipline organization of Rational Unified Process and its relationship to iterative development Introduction to disciplines

Role of Development Process Define the steps that lead to deliverables and who is responsible for them. Help to control the project and reduce confusion. Help project management to resource, plan, and measure progress. Reduce risk. Make software development predictable, repeatable, and measurable.

Role of UML in RUP Rational Unified Process was developed hand-in-hand with the UML. Many artifacts in Rational Unified Process have a UML representation. Rational Unified Process also includes guidelines for UML concepts.

RUP Structure RUP Organization along time l Lifecycle structure: phases, iterations l Process enactment: planning, executing l Activity management, project control RUP Organization based on content l Disciplines, Workflows Roles, Artifacts, Activities,

Organization Along Time

Major Milestones: Business Decision Points Product sufficiently mature for customers Commit resources for construction Customer acceptance or end of life Commit resources for the elaboration phase Inception Elaboration Construction Transition time Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release

Inception Phase: Objectives Prepare supporting environment for project Establish project scope and boundary conditions Determine the use cases and primary scenarios that will drive the major design trade-offs Demonstrate a candidate architecture against some of the primary scenarios Estimate the overall cost and schedule Identify potential risks (the sources of unpredictability)

Elaboration Phase The overriding goal of the elaboration phase is to analyze the problem domain, establish a architectural foundation, develop the project plan, and eliminate the project’s high-risk elements.

Elaboration Phase: Objectives Refine support environment Define, validate and baseline the architecture as rapidly as is practical Baseline the vision Baseline a detailed plan for the construction phase Demonstrate that the baseline architecture will support the vision at a reasonable cost in a reasonable period of time

Construction Phase The overriding goal of the construction phase is to develop all remaining components and features and integrate them into the product.

Construction Phase: Objectives Completing the software product for transition to production Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework Achieving adequate quality as rapidly as is practical Achieving useful versions (alpha, beta, and other test releases) as rapidly as possible

Transition Phase The overriding goal of the transition phase is to move the product to the user community.

Transition Phase: Objectives Achieving user self-supportability Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision Achieving final product baseline as rapidly and cost-effectively as possible

What Is an Iteration?

Phases and Iterations Planned (Business) Decision Points Commit resources for the elaboration phase Commit resources for construction (Understand the problem) (Understand the solution) Inception Preliminary Iteration Elaboration Architect. Iteration Product sufficiently mature for customers to use (Have a solution) Construction Architect. Iteration Devel. Iteration Acceptance or end of life Devel. Iteration Transition Devel. Iteration Planned (Technical) Visibility Points Transition Iteration

Iteration: Number and Duration driven by + size of organization + size of project - familiarity with the process, maturity - technical simplicity 6, plus or minus 3 Inception: 0. . 1 Elaboration: 1. . 3 Construction: 1. . 3 Transition: 1. . 2

One Iteration In an iteration, you walk through all disciplines.

Content Organization Based on Content

Key RUP Elements: Roles, Activities, Artifacts performs Role Activity responsible for Artifact

Roles Perform Activities and Produce Artifacts Example: Requirements-> Workflow Detail-> Define the System

Key RUP Element: Role A Role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team. Team members can “wear different hats, ” that is, each member can play more than one Role.

Roles Are Used for Resource Planning Resource Role Activities Paul Designer Define Operations Mary Requirements Specifier Detail a Use Case Joe System Analyst Find Actors and Use Cases Sylvia Implementer Perform Unit Tests Stefan Architect Identify Design Mechanisms Each individual in the project is assigned to one or several roles

Key RUP Element: Activity A piece of work a Role is responsible for, that the Role may be asked to perform Granularity: a few hours to a few days Repeated, as necessary, in each iteration

Key RUP Element: Artifact A document or model produced, evolved, or used by a process The responsibility of a Role Likely to be subject to configuration control May contain other artifacts

Key RUP Elements: Roles, Activities, Artifacts performs Role Activity responsible for Artifact Disciplines also contain Workflows and Workflow Details, as you will see.

Nine Disciplines

Elements of a Discipline If you expand any Discipline in the RUP tree browser, you will see the following:

Key RUP Element: Workflow The conditional flow of high-level activities that produces a result of observable value.

Example: Environment: Workflow Details Example: Workflow Detail: Prepare Environment for Project

Workflow Path Is Adapted to: Position in l Lifecycle l Phase Artifacts being produced Technology Iteration goals Example: Analysis & Design

Workflows Guide Iterative Modeling: Development Business Workflow Details Requirements: Workflow Details

Iteration Plan Includes relevant portions of Discipline for a particular iteration

Iteration Plan (cont. ) Instantiation of the discipline One for each iteration A fine-grained plan Expressed in terms of selected Workflow Details or Activities from the disciplines Shows assigned resources

Summary of Major Artifacts

Summary of Organization

Additional Process Elements Discipline l Introduction l Concepts l Workflow l Activity l And associated Tool Mentors and Guidelines l Artifact l Overview And associated Templates and Guidelines l Guidelines Overview l Roadmaps

Process Element: Concepts Attached to the relevant Discipline Explanation of key ideas Examples of Concepts l Requirements Management l Types of Requirements l Traceability l Analysis and Design l Software Architecture l Analysis Mechanisms l Web Architecture Patterns

Process Element: Guidelines These are Rules, recommendations, heuristics that support activities and their steps. They: Describe specific techniques. l Transformations l Use from one artifact to another of UML Are attached to relevant discipline. Are kept short and to the point. Describe well-formed artifacts and focus on qualities. Are used also to assess the quality of artifacts. Are tailored for the project.

Process Element: Tool Mentors Attached to relevant activity Explain how to use a specific tool to perform an activity or steps in an activity Linked by default to Rational tools: l Requisite. Pro: requirements management l Rational Rose: visual modeling, using UML l So. DA: documentation generation l Clear. Quest: change management, defect tracking l …and more

Process Element: Templates Attached to relevant document type Predefined artifacts, prototypes: l Documents (Microsoft® Word™, Adobe® Framemaker™) l MS Project l HTML Tailored for the process

Process Element: Roadmaps are used to: Apply the general-purpose process to solve specific types of problems. Describe process variants using phases. Provide a mechanism for extending and adapting the process. Highlight certain process features to achieve a particular goal.

Discipline: Environment Purpose: Support the development organization, both with process and tools l Process configuration l Adapt RUP to organization l Process implementation l Train and mentor RUP users l Process improvement l Managing organizational change l Development environment l l Tool selection and acquisition Tool instillation and configuration

Discipline: Environment The primary roll in the Environment Discipline is the Process Engineer. The primary artifact produced by the Process Engineer is the Development Case. The Development Case describes, for each process discipline, how the project will apply the process.

Discipline: Project Management Purpose: l Provide a framework for managing software -intensive projects l Provide practical guidelines for planning, staffing, executing, and monitoring projects l Provide a framework for managing risk

Discipline: Project Management Questions that must be addressed by the project manager: l How many iterations are needed? l How long should each iteration be? l How are the contents and objectives of an iteration determined? l How is the progress of an iteration tracked?

Discipline: Project Management Project planning takes place at two levels Phase Plan Level 1. l l l Dates of major milestones: end of each phase and its objectives Staffing profiles: which resources are required over time. Dates of minor milestones: end of each iteration and its objectives Iteration Plan Level 2. § § Current iteration plan Next iteration plan (built toward end of current iteration)

Discipline: Requirements Purpose: l Establish and maintain agreement with the customers and other stakeholders on what the system should do. l Provide system developers with a better understanding of the system requirements. l Define the boundaries of (delimit) the system. l Provide a basis for planning the technical contents of iterations. l Provide a basis for estimating cost and time to develop the system. l Define a user-interface for the system, focusing on the needs and goals of the users.

Primary Requirements Artifacts Requirement Functional Non. Functional (URPS) Supplementary Specification Use-Case Model

Discipline: Business Modeling Purpose l Understand structure and dynamics of organization in which system is to be deployed l Understand problems in target organization and identify improvement potentials l Ensure customer/end user common understanding of target organization l Derive system requirements to support target organization

What a Business Model Shows Customers Business processes Organizational structure Roles and responsibilities Products Internal deliverables Events Two business models Business Use-Case Model Business Object Model

Discipline: Analysis & Design Purpose: l To transform the requirements into a design of the system-to-be l To evolve a robust architecture for the system l To adapt the design to match the nonfunctional requirements and the implementation environment Design is a refinement of analysis Primary artifact is Design Model

The Design Model Artifact: Consists of a collection of models that collaborate to describe the structure and behavior of the system. Is an object model describing the realization of use cases. Serves as an abstraction of the implementation model and its source code. Is used as essential input to activities in implementation and test.

Use Cases Drive Analysis & Design Analysis Model (optional) Use-Case Model Analysis and Design Model Supplementary Specifications Architecture Document Data Model

Use-Case Realization <<realizes>> Use Case (Use-Case Model) Use Case Use-Case Realization (Design Model) Sequence Diagrams Class Diagrams Collaboration Diagrams

Discipline: Test Purpose: Testing focuses primarily on the evaluation or assessment of quality realized through a number of core practices: l Finding and documenting defects in software quality. l Generally advising about perceived software quality. l Proving the validity of the assumptions made in design and requirement specifications through concrete demonstration. l Validating the software product functions as designed. l Validating that the requirements have been implemented appropriately. Test discipline acts in many respects as a service provider to the other disciplines.

Discipline: Implementation The purposes of Implementation are: l To implement classes and objects in terms of components l To define the organization of the components in terms of implementation subsystems l To test the developed components as units l To create an executable system Implementation results in an Implementation Model

Implementation Model An Implementation Model consists of: l Components l Implementation Subsystems Components include: l Deliverable components, such as executables l Components from which the deliverables are produced, such as source code files Telephone Banking A <<import>> <<compilation>> Trading Services B Components and implementation subsystems in a Telephone Banking System.

Concept: Build Operational version of a system or part of a system Demonstrates a subset of the capabilities provided in the final product Integral part of the iterative lifecycle Provides review points Helps uncover integration problems as soon as they are introduced

Discipline: Deployment Purpose: Manage the activities associated with ensuring that the software product is available for its end users, such as: l Product deployment l Testing at the installation and target sites l Beta testing l Creating end-user support material l Creating user training material l Releasing to customer (in the form of shrinkwrapped package, download site, etc. )

Use Cases and End-User Documentation Use-Case Model Deployment Supplementary Specification End-User Support Material • User’s Guide • Online Help • Demos • Tutorials • Training Material

Discipline: Configuration & Change Management Purpose: Track and maintain integrity of project artifacts l Change control l Configuration identification and management l Configuration status accounting l Change tracking l Version selection l Software manufacture l Workspace management

The Configuration and Change Management (CCM) Cube

Configuration Management (CM) Describes the product structure (logically correct configurations) Identifies which artifacts are to be tracked Identifies dependencies among artifacts Maintaining traceability between artifacts Isolate individual and team workspaces

Change Request Management (CRM) Addresses: The capture and management of requested changes to one or more artifacts by various stakeholders. l. A change request has a lifecycle: new, logged, approved, assigned and complete. l Not all change requests are acted on. The potential impact of a proposed change determines if it will be acted on.

RUP Overview Seyyed Jamaleddin Pishvayi seyyedjamal@asta. ir