1. 11 Rational Unified Process

2. 22 Agenda Part I: Introduction Part II: Disciplines & Workflows Part III: Phases & Iterations Part IV: Configuring RUP Part I: Introduction Part II: Disciplines & Workflows Part III: Phases & Iterations Part IV: Configuring RUP

3. 33 What’sRational What’s Rational? Three important contributors – –Grady Booch (Booch Method) – –James Rumbaugh (OMT Method) – –Ivar Jacobson (OOSE Method) Introduction

4. 44 Unified Why Unified?  Unification of Development Approaches using UML  Unification of the Work Of many Methodologists  Unification of Development Approaches using UML  Unification of the Work Of many Methodologists Introduction

5. 55 What’s 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 user’s requirements into a software system[Jacobson] Introduction

6. 66 History Of RUP Rational Unified Process 1998 Rational Objectory Process 1996-1997 Objectory Process 1987-1995 The Ericsson Approach UML Introduction

7. 77 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. 88  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  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. 99 Process Framework Rational Unified Process My Development Process My Project Is specialized to Is enacted as Features

10. 1010 The Architecture of RUP time and the lifecycle process disciplines or workflows Features

11. 1111 The 3+1 Keywords  Architecture Centric  Use Case Driven  Iterative and Incremental  Risk Confronting  Architecture Centric  Use Case Driven  Iterative and Incremental  Risk Confronting 3+1 Keywords } } From USDP

12. 1212 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. 1313 RUP is Iterative & Incremental 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. 1414 RUP is Architecture Centric 3+1 Keywords

15. 1515 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 RiskRisk RiskRisk Inception

16. 1616 Part II Process Disciplines & Workflows Process Disciplines & Workflows

17. 1717 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.  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. 1818 Workflows in RUP Workflows Core Process Workflows Workflows Support Process Workflows Workflows

19. 1919 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 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. 2020 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. 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. Workflowsvisionvision glossaryglossary

21. 2121 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.  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. 2222 Implementation  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.  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. 2323 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.  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. 2424 Deployment  The Deployment Workflow describes the activities associated with ensuring that the software product is available for its end users Workflows

25. 2525 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  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. 2626 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.  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. 2727 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. 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. 2828 Key Concepts Workflows

29. 2929 Implementation Workflow Plan the Integration Implement Components Structure the Implementation Model Structure the Implementation Model Implement Components [more components to implement in this iteration] [more system builds for this iteration] [more subsystem integration for this iteration] Workflows

30. 3030 Structure the Implementation Model Worker Activity Structure the Implementation Model Use-Case Specifier Workflow Details Design Model Implementation Model Software Architecture Document Artifact

31. 3131 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. 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 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 Input Artifacts: Software Architecture Document Supplementary Specifications Design Guidelines Design Model Input Artifacts: Software Architecture Document Supplementary Specifications Design Guidelines Design Model Resulting Artifacts: Implementation View section of the Software Architecture Document Implementation Subsystems 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 Tool Mentor: Structuring the Implementation Model Using Rational Rose Setting Up the Implementation Model Using Rational ClearCase

32. 3232 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 Microsoft Word Template HTML Template Examples: Course Registration System Collegiate Sports Paging System (e-Business) Course Registration System Collegiate Sports Paging System (e-Business) More Information: Checkpoints: Software Architecture Document Guidelines: Software Architecture Document Checkpoints: Software Architecture Document Guidelines: Software Architecture Document Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window) Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)

33. 3333 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. 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. 3434 Use-Case Specification—HTML Template Use Case Specification: Version Use Case Specification: Version Use Case Specification: 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 customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable¾you may want to define things like customer information there to keep the use case from drowning in details. Use Case Specification: 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 customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable¾you may want to define things like customer information there to keep the use case from drowning in details.

35. 3535 Part III Phases and Iterations

36. 3636 Lifecycle Phases InceptionUnderstand what to build Define the Scope of Project and Develop Business Case and Critical Use-Case ElaborationUnderstand how to build it Plan Project, Specify Features, and Baseline the Architecture ConstructionBuild the Product Produce a beta product TransitionTransition the Product to its Users Produce final product Phases InceptionElaborationConstructionTransition timetime

37. 3737 Milestones InceptionElaborationConstructionTransition time Lifecycle Objectives Milestone Lifecycle Architecture Milestone Initial Operational Capability Product Release

38. 3838 Phases and Iterations  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  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 PreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransitionIterationTransitionIteration InceptionElaborationConstructionTransition Minor Milestones: Releases Phases

39. 3939 Iteration as Waterfall In an iteration, you walk through all workflows Phases

40. 4040 The Iteration 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. 4141 Iteration PhasesInitialPlanning PlanningRequirementsCapture Analysis & Design Implementation Test Deployment Evaluation ManagementEnvironment

42. 4242 What the Iterative Lifecycle Is  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  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. 4343 Phases and Iterations: A Sample Phases Short e-Business Project 5 Project Member No of Iterations InceptionInception ElaborationElaborationConstructionConstruction TransitionTransition ProjectLengthProjectLengthIterationLengthIterationLength 1 1 1 1 3 3 1 1 3-4 month 3-4 month 2-3 weeks 2-3 weeks 10% 30% 50% 10% Time:Time:

44. 4444 Risk Profile of an Iterative 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. 4545 Part IV Configuring RUP

46. 4646 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 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 different Risk Each have different Risk different Risk Each have different Equipment different Equipment Each have different Equipment different Equipment Each have different Objectives Each have different Objectives Each have different Safety and Security Each have different Safety and Security EssentialsEssentials Configure RUP

47. 4747 Which Do I Need for My Project Configure RUP

48. 4848 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. 4949 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. 5050 Tools: Rational Suite Rose TeamTest RequisiteProSoDA ClearCase ClearQuest Purify Quantify PureCoverage Content Studio Project Console Rational Unified Process Process Jacobson : a process without integral tools is just an academic idea! Jacobson : a process without integral tools is just an academic idea!

51. 5151 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  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. 5252 Rational Unified Process http://www.BaridSoft.ca This presentation can be download from: