2 Agenda Part I: Introduction Part II: Disciplines & Workflows Part III: Phases & Iterations Part IV: Configuring RUP
3 Whats Rational?
Three important contributors Grady Booch (Booch Method) James Rumbaugh (OMT Method) Ivar Jacobson (OOSE Method)
Introduction 4 Why Unified? Unification of Development Approaches using UML
Unification of the Work Of many Methodologists
Introduction 5 Whats Process? Defines Who is What, When to do it, and How to reach a certain goal. A Software Development Process is the set of activities needed to transform a users requirements into a software system[Jacobson]
Introduction 6 History Of RUP Rational Unified Process 1998 Rational Objectory Process 1996-1997 Objectory Process 1987-1995 The Ericsson Approach UML Introduction 7 Process Product Process must be built on Technologies People: limit the skill set needed to operate Tools are integral to process Organization Pattern Balance "Software processes are software, too"
Features 8 Like a software product is based on UML
Is delivered online using Web technology, not in books or binders
Released by Rational Software approximately twice a year Process Product continue Features 9 Process Framework Rational Unified Process My Development Process My Project Is specialized to Is enacted as Features 10 The Architecture of RUP time and the lifecycle process disciplines or workflows Features 11 The 3+1 Keywords Architecture Centric
Use Case Driven
Iterative and Incremental
Risk Confronting 3+1 Keywords
} From USDP 12 Use-Case Model Implementation Model Design Model Analysis Model Test Model Deployment Model RUP is Use Case Driven Specified by Realized by Implemented by Distributed by Verified by 3+1 Keywords
13 RUP is I terative & I ncremental Code and unit test Design Subsystem integration Requirements analysis System test 3+1 Keywords
Iteration 1 Code and unit test Design Subsystem integration Requirements analysis System test Iteration 2 14 RUP is Architecture Centric Process View Deployment View Logical View Implementation View Programmers Software management Performance Scalability Throughput System Integrators System topology Delivery, installation communication System Engineering Use-Case View Structure Analysts/ Designers End-user Functionality 3+1 Keywords
15 RUP is Risk Confronting 3+1 Keywords
Iteration 3... Construction Inception Architectural prototype Draft specifications & models Elaboration Initial executable system Refined specifications & models Final system Intermediate system Transition Focus on the 20% that really matter: The primary use cases The architectural components The driving scenarios R i s k R i s k Inception 16 Part I I Process Disciplines & Workflows 17 Definition Workflow The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business
Core workflow A core workflow shows all activities you may go through to produce a particular set of artifacts.
Workflow detail A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows.
18 Workflows in RUP Workflows Core Process Workflows Support Process Workflows 19 Business Modeling To understand the structure and the dynamics of the target organization). To understand current problems in the target organization and identify improvement potentials. To ensure that customers, end users, and developers have a common understanding of the target organization. To derive the system requirements needed to support the target organization
20 Requirements To agreement with stakeholders To provide system developers better understanding of the system requirements. define the boundaries of the system. To provide a basis for planning the technical contents of iterations. To provide a basis for estimating cost and time to develop the system. To define a user-interface for the system, focusing on the needs and goals of the users. Workflows vision glossary 21 Analysis and Design To transform the requirements into a design of the system to-be.
To evolve a robust architecture for the system.
To adapt the design to match the implementation environment, designing it for performance. Workflows 22 I mplementation To define the organization of the code, in terms of implementation subsystems organized in layers
To implement classes and objects in terms of components (source files, binaries, executables, and others)
To test the developed components as units
To integrate the results produced by individual implementers (or teams), into an executable system. Workflows 23 Test To verify the interaction between objects.
To verify the proper integration of all components of the software.
To verify that all requirements have been correctly implemented.
To identify and ensure defects are addressed prior to the deployment of the software. Workflows Test Model Test Case 24 Deployment The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users Workflows 25 Environment The environment workflow focuses on the activities necessary to configure the process for a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team
Workflows 26 Configuration and Change Management supports development methods maintains product integrity ensures completeness and correctness of the configured product provides a stable environment within which to develop the product restricts changes to artifacts based on project policies provides an audit trail on why, when and by whom any artifact was changed.
Workflows 27 Project Management To provide a framework for managing software- intensive projects. To provide practical guidelines for planning, staffing, executing, and monitoring projects. To provide a framework for managing risk. Managing people: hiring, training, coaching Managing budget: defining, allocating, etc. Managing contracts, with suppliers and customers NOT Workflows 28 Key Concepts Workflows 29 I mplementation Workflow Plan the Integration Implement Components Structure the Implementation Model Implement Components Implement Components [more components to implement in this iteration] [more system builds for this iteration] [more subsystem integration for this iteration] Workflows 30 Structure the I mplementation Model Worker Activity Structure the Implementation Model Use-Case Specifier Workflow Details Design Model Implementation Model Software Architecture Document Artifact 31 Activity: Structure the Implementation Model Purpose To establish the structure in which the implementation will reside. To assign responsibilities for Implementation Subsystems and their contents.
Steps Create the initial implementation model structure Adjust implementation subsystems Define imports for each implementation subsystems Decide how to treat executables (and other derived objects) Decide how to treat test assets Update the implementation view Evaluate the implementation model
Resulting Artifacts: Implementation View section of the Software Architecture Document Implementation Subsystems Implementation Model
Worker: Architect Guidelines: Guidelines: Implementation Subsystems Tool Mentor: Structuring the Implementation Model Using Rational Rose Setting Up the Implementation Model Using Rational ClearCase
32 Artifact: Software Architecture Document Software Architecture Document The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. Worker: Architect Template: Microsoft Word Template HTML Template
Examples: Course Registration System Collegiate Sports Paging System (e-Business)
More Information: Checkpoints: Software Architecture Document Guidelines: Software Architecture Document
Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)
33 Checkpoints: Design Model Topics General Layers
General The model appears to be able to accommodate reasonably expected future change. The design is appropriate to the task at hand (neither too complex nor too advanced) The design appears to be implementable Layers The design appears to be understandable and maintainable There are no more than seven (plus or minus two) layers. The rationale for layer definition is clearly presented and consistently applied. 34 Use-Case SpecificationHTML Template <Project Name> Use Case Specification: <Use-Case Name>
Version <1.0>
Use Case Specification: <Use-Case Name> 1. Use Case Name [The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use case properties] [The diagrams of the use case can be developed in a visual modeling tool, such as Rational Rose. A use-case report (with all properties) may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.] 1.1 Brief Description [The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description.] 2. Flow of Events 2.1 Basic Flow [This use case starts when the actor does something. An actor always initiates use Cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information. It is better to say the Actor enters the customers name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageableyou may want to define things like customer information there to keep the use case from drowning in details. 35 Part I I I Phases and I terations 36 Lifecycle Phases I nception Understand what to build Define the Scope of Project and Develop Business Case and Critical Use-Case Elaboration Understand how to build it Plan Project, Specify Features, and Baseline the Architecture Construction Build the Product Produce a beta product Transition Transition the Product to its Users Produce final product Phases I nception Elaboration Construction Transition time 37 Milestones I nception Elaboration Construction Transition time Lifecycle Objectives Milestone Lifecycle Architecture Milestone Initial Operational Capability
Product Release 38 Phases and I terations An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external) Within each phase are a number of iterations Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Inception Elaboration Construction Transition Minor Milestones: Releases Phases 39 I teration as Waterfall In an iteration, you walk through all workflows Phases 40 The I teration Life Cycle: A Mini- Waterfall Results of previous iterations Up-to-date risk assessment Controlled libraries of models, code, and tests Release description Updated risk assessment Controlled libraries Iteration Planning Requirements Capture Analysis & Design Implementation Test Prepare Release Selected scenarios Phases 41 I teration Phases Initial Planning Planning Requirements Capture Analysis & Design Implementation Test Deployment Evaluation Management Environment 42 What the I terative Lifecycle I s It is planned and managed It is predictable It accommodates changes to requirements with less disruption It is based on evolving executable prototypes, not documentation It involves the user/customer throughout the process It is risk driven
Phases 43 Phases and I terations: A Sample Phases Short e-Business Project 5 Project Member No of Iterations I nception Elaboration Construction Transition Project Length I teration Length 1 1 3 1 3-4 month 2-3 weeks 10% 30% 50% 10% Time: 44 Risk Profile of an I terative Development Risk Transition Inception Elaboration Construction Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Post- deployment Waterfall Time Copyright 1997 by Rational Software Corporation
Phases 45 Part I V Configuring RUP 46 Why Do You Need To Configure RUP RUP is a Framework not a single Process No one process fits all projects All thing will be changed Technologies Organization Each have different Risk Each have different Equipment Each have different Objectives Each have different Safety and Security Essentials Configure RUP 47 Which Do I Need for My Project Configure RUP 48 Who Configures The RUP? Configure RUP Assess Current Organization Engineer Process Development Organization Assessment Development Case Project Specific Templates Develop Development Case Develop Project Specific Templates Launch Development Case 49 How To Configure The RUP? Development Case: The development-case description describes the development process that you have chosen to follow in your project Roadmap: Roadmaps provide a way of describing how to use the general-purpose process described in the Rational Unified Process to solve specific types of problems
Configure RUP 50 Tools: Rational Suite Rose TeamTest RequisitePro SoDA ClearCase ClearQuest Purify Quantify PureCoverage Content Studio Project Console Rational Unified Process Jacobson: a process without integral tools is just an academic idea! 51 References Unified Software Development Process, Ivar Jacobson, Grady Booch, Jim Rumbaugh Ten Essential Of RUP, Leslee Probasco Trends in Software Engineering a personal view, Ivar Jacobson Object Oriented Methodology, William F. Nazzaro What is RUP, Philippe Kruchten Introduction to Rational Unified Process, Philippe Kruchten Rational Unified Process, www.rational.com/rup www.therationaledge.com 52 Rational Unified Process http://www.BaridSoft.ca This presentation can be download from: