An Overview of RUP methodology

RUP Overview By Masoud Kalali November/2004 http://kalali.me

Presentation Goal What is RUP in some detail and a point to The product from IBM and understand how RUP compare to MSF. (Microsoft Solutions Framework) Have a better understanding of RUP

Agenda Terms and definitions What is RUP? Key aspect of RUP 6 Best practices RUP Architecture Dynamic aspect Static Aspect Workers RUP Workflows Software Architecture RUP – The Product RUP Vs MSF Conclusion QA References

RUP Terms And Definitions Cycle : A development cycle is the period of time that elapses from the very start of the project until product release (or project cancellation); it includes all the activities that are executed during that time. Phases : Each cycle in the RUP is broken down into a sequence of four phases, called Inception, Elaboration, Construction, and Transition. Remember that the phases always exist and are important, not because of what is executed or because of their length, but because of what is achieved at the major milestone that concludes them. Iteration : Inside each phase there may be one or more iterations. Software is developed in each iteration, which is concluded by a minor milestone, including a release (internal or external) that is a point for assessing the project progress. The software product grows incrementally as you iterate over the activities Milestone : The point at which an iteration formally ends; corresponds to a release point. workflow is a sequence of activities that produces a result of observable value . Discipline is a collection of activities that are related to a major "area of concern" within the overall project

RUP from Mars RUP is a process framework consisting of: process delivery tools configuration tools process authoring tools community/marketplace of process plug-ins. A process product developed and marketed by Rational Software with an interactive knowledge base integrated with tools

What is RUP? A software engineering process based on best practices in modern software development A disciplined approach to assigning and managing tasks and responsibilities in a development organization Focused on high-quality software that meets the needs of its end users within a predictable schedule and budget A process framework that can be tailored to specific organization or project needs RUP is a methodology for delivering projects in a maximum performance manner.

Key Aspects of RUP Risk-driven process Risk management integrated into the development process Iterations are planned based on high priority risks Use-case driven development Use cases express requirements on the system’s functionality and model the business as context for the system Use cases are defined for the intended system and are used as the basis of the entire development process Architecture-centric design Architecture is the primary artifact to conceptualize, construct, manage, and evolve the system Consists of multiple, coordinated views (or models) of the architecture

RUP 6 Best practices Develop Software Iteratively Driven by early risk identification and mitigation Each iteration results in an executable release Manage Requirements Requirements inherently dynamic across the system’s life Use Component-Based Architecture Architectures that are resilient to change are essential

RUP 6 Best practices Visually Model Software Promotes consistency and unambiguous communication of development information Continuously Verify Software Quality Identify defects early, objective measure of project status Control Changes to Software Create and release a tested baseline at the end of each iteration

RUP Architecture RUP produces a software generation A generation extends from idea to retirement of a single version of the system Dynamic Structure Describes the process in terms of how the process rolls out over time Expressed in terms of iterations, phases, and milestones Static Structure How RUP elements are co-works together. Expressed in term of core disciplines.

Dynamic Aspect The dynamic structure deals with the lifecycle or time dimension of a project Shows cycles which contains 4 phases Inception closed with Milestone : Lifecycle Objective Elaboration closed with Milestone: Lifecycle Architecture Construction closed with Milestone: Initial Operational Capability Transition closed with Milestone : Product Release Below table shows how project time and effort is divided between phases Transition Construction Elaboration Inception 30% 65% 20% 5% Effort 10% 50% 30% 10% Time

Inception phase Objective: Understand what to build. A vision document: Optional business model An initial project glossary Identify key system functionality. A initial use-case model (10% -20%) complete. Determine at least one possible solution. One or several prototypes. Understand the costs, schedule, and risks associated with the project. An initial risk assessment. Business case Decide what process to follow and what tools to use . A project plan Inception is the first of four RUP phase its all about getting familiar with Project goal and Scope .this phase help you determine the project feasibility , what customer want and how will you get into more resource consumable phase.

Milestone: cost/schedule estimates. Requirements understanding. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype . Actual expenditures versus planned expenditures. Lifecycle Objective Milestone Its first project Milestone which help to abort project or reconsider it early And let us not to focus on a doomed to fail project. time Inception Elaboration Construction Transition First Major Milestone

Elaboration phase Deeper Requirement understanding At least 80% complete use-case model Supplementary requirements capturing non functional requirements None Use case requirement Architect consideration. A Software Architecture Description. An executable architectural prototype. Risk mitigation and Accurate Cost/Scapulae A revised risk list and a revised business case. Development Case refinement A development plan for the overall project coarse-grained project plan showing iterations evaluation criteria for each iteration. Objectives: Elaboration is the second of the four phases in the RUP approach. The goal of the Elaboration phase is to define and baseline the architecture of the system in order to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risks.

Milestone : Lifecycle Architecture Is vision Stable? Is architecture stable? Does executable show true risk management? Is next phase (Construction) plane is accurate? Does current vision could be achieved? Is the actual resource expenditure versus planned expenditure acceptable? This milestone tell help to determine if project plane, vision , architecture Are enough good to achieve project goals? If not Abort the project or reconsider it very seriously time Inception Elaboration Construction Transition Major Milestones

Construction Phase Minimize development costs and achieve some degree of parallelism Iteratively develop a complete product that is ready to transition to its user community The software product integrated on the adequate platforms. The user manuals. A description of the current release. Construction is really about cost-efficient development of a complete product—an operational version of your system—that can be deployed in the user community Objectives:

Milestone : Initial Operational Capability Is this product release stable and mature enough to be deployed in the user community? Are all the stakeholders ready for the transition into the user community? Are actual resource expenditures versus planned expenditures still acceptable? time Inception Elaboration Construction Transition Major Milestones The Construction phase ends with an important project milestone, the Initial Operational Capability Milestone, which is used to determine whether the product is ready to be deployed into a beta test environment by answering (among others) the following questions

Transition Phase “ beta testing” to validate the new system against user expectations parallel operation with a legacy system that it is replacing conversion of operational databases training of users and maintainers roll-out the product to the marketing, distribution, and sales teams Improve future project performance through lessons learned The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed. Objectives:

Milestone: Product Release Is the user satisfied? Are the actual resources expenditures versus planned expenditures still acceptable? Transition ends with the fourth major project milestone, the Product Release Milestone, to determine whether the objectives were met and if you should start another development cycle. (Several development cycles may have been already planned during Inception.) In some cases this milestone may coincide with the end of the Inception phase for the next cycle time Inception Elaboration Construction Transition Major Milestones

System Evolution Four phases form one development cycle and produce a generation of the system Significant user enhancement, business or mission changes, or technology changes trigger a new generation V1 V3 V2 Initial Project Cycle Evolution Cycles RUP is So flexible , you finish the project and deliver it’s final operational version. But after a while you or your customer find some new requirement that will be better to add to project in this condition evolution cycles start . In each evolution you made some new feature or enhance some already available feature and announce a new version. its the evolutionary aspect or software generation I E C T I E C T I E C T

Dynamic Elements Phases and Milestones , a Review time Inception Define scope of project Lifecycle Objectives … Elaboration Plan project, specify features, baseline architecture Lifecycle Architecture … Initial Operational Capability Construction Build product … Major Milestones Transition Transition product to end user community … Product Release

Static Aspect of RUP Static Elements Worker (Who) Activity (How) Artifact (What) Workflows (when) Project Management Business Modeling Requirements Analysis and Design Implementation Test Configuration and Change Management Environment Deployment Static dimension of RUP consist of Some Roles ,Activities , Artifacts and workflows. Workflow is a way to describe meaningful sequences of activities that produce some valuable result and to show interactions between roles. Roles in RUP are assigned to Workers , and preparing an artifact assign to Roles . Activities shows how a Role will do an assignment.

Static Process Elements Roles (who) A role that defines the individuals or a team that should carry out the work Activity (how) Describes a piece of work a worker performs Artifact (what) A piece of information that is produced, modified, or used by an activity Workflow (when) Specifies when a set of related activities is performed, by which workers , producing some artifact , which provides some observable value to the project

Roles Any Worker Any of the workers identified in the Rational Unified Process Architect The architect leads and coordinates technical activities and artifacts throughout the project. Architecture Reviewer The architecture reviewer plans and conducts the formal reviews of the software architecture in general. Business Designer The business designer defines the responsibilities, operations, attributes, and relationships of one or several business workers and business entities. Business-Model Reviewer The business-model reviewer participates in formal reviews of the business use-case model and business object model.

Roles-Cont. Business-Process Analyst The business-process analyst leads and coordinates business use-case modeling. Capsule Designer The capsule designer focuses on ensuring that the system is able to respond to events in a timely manner, in accord with the concurrency requirements. Change Control Manager The change control manager (worker) oversees the change control process. In a small project, a single person, such as the project manager or software architect, may play this role. Code Reviewer responsible for ensuring the quality of the source code Configuration Manager The configuration manager ensures that the CM environment facilitates product review, change, and defect tracking activities. The configuration manager is also responsible for writing the CM plan and reporting change-request-based progress statistics.

Roles-Cont. Course Developer The course developer develops training material to teach users how to use the product. Database Designer The database designer defines the tables, indexes, views, constraints, triggers, stored procedures, table spaces or storage parameters, and other –database specific constructs needed to store, retrieve, and delete persistent objects. Deployment Manager The deployment manager is responsible for plans to transition the product to the user community. Design Reviewer The design reviewer plans and conducts the formal reviews of the design model. Designer The designer defines the responsibilities, operations, attributes, and relationships of one or several classes and determines how they should be adjusted to the implementation environment.

Roles-Cont. Implementer An implementer is responsible for developing and testing components in accordance with the project's adopted standards so that they can be integrated into larger subsystems. Process Engineer The process engineer is responsible for the software development process itself. Project Manager The project manager allocates resources, shapes priorities, coordinates interactions with the customers and users, and generally tries to keep the project team focused on the right goal. Project Reviewer The project reviewer is responsible for evaluating project planning artifacts and project assessment artifacts, at major review points in the project lifecycle. Requirements Reviewer The requirements reviewer plans and conducts the formal review of the use-case model.

Roles-Cont. Stakeholder Is anyone who is materially affected by the outcome of the project. System Administrator Maintains the development environment—both hardware and software—and is responsible for system administration, backup, and so on. System Analyst Leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system. System Integrator System integrators combine components to produce an internally released build. Also responsible for planning the integration of the system. Technical Writer The technical writer produces end-user support material, such as user guides, help texts, release notes, and so on.

Roles-Cont. Test Designer The test designer is responsible for the planning, design, implementation, and evaluation of testing and evaluation of test coverage, test results, and effectiveness. Tester The tester is responsible for executing testing, including test setup and execution; evaluating test execution and recovering from errors; and assessing the results of test and logging identified defects. Tool Specialist The tool specialist is responsible for the supporting tools in the project. This includes assessing the need for tool support and selecting and acquiring tools. Use-Case Specifier The use-case specifier details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases. User-Interface Designer Capturing usability requirements; building user-interface prototypes; involving other stakeholders of the use and reviewing and providing the appropriate feedback on the final implementation of the user interface.

RUP Disciplines In RUP, the process is described at two levels: the discipline level and the workflow detail level. A Workflow is a grouping of activities that are often performed "together" to produce a specific result. In particular, workflow details describe groups of activities performed together in a discipline. The workflows for the RUP disciplines and workflow details are described using Unified Modeling Language (UML) activity diagrams. Discipline diagrams contain the workflow details of the discipline.

RUP Disciplines- Business Modeling Business Modeling Understand the organization structure and dynamics in which a system is to be deployed Drive system requirements and achieving common understanding of system. Business-Process Analyst Business Architecture Document Business-Process Analyst Business Designer Business Designer Business Designer Business Object Model Organization Unit Business Worker Business Entity Business Designer Business Use-Case realization Business-Process Analyst Business Designer Business Designer Business Use-Case Model Business Use Case Business Actor Business-Process Analyst Supplementary Business Specification Business-Process Analyst Business Rules Business-Process Analyst Business Glossary Business-Process Analyst Business Vision Business-Process Analyst Target-Organization Assessment Role Artifact

RUP Disciplines: Requirements Management Requirements Management Capture and manage requirements Design a user interface focused on users needs and goals To define the boundaries of (delimit) the system To provide a basis for estimating cost and time to develop the system User-Interface Designer User-Interface Prototype User-Interface Designer Use-Case Storyboard User-Interface Designer Boundary Class System Analyst Use-Case Specifier Use-Case Specifier System Analyst User-Interface Designer Use-Case Model Use-Case Package Use Case Actor (system) Actor (human) Use-Case Specifier Software Requirements Specification System Analyst Supplementary Specification System Analyst Requirements Attributes System Analyst Vision System Analyst Glossary System Analyst Stakeholder Requests System Analyst Requirements Management Plan Role Artifact

RUP Disciplines: Analysis and Design Analysis and Design Translate requirements into a specification that describes how to implement the system Fulfills all its requirements. Is structured to be robust? Database Designer Data Model Capsule Designer Designer Designer Designer Capsule Protocol Signal Event Architect Designer Designer Designer Designer Design Model Design Subsystem Design Package Design Class Interface Designer Architect Analysis Model Analysis Class Designer Use-Case Realization Architect Software Architecture Document Architect Reference Architecture Fit/Gap Analysis Architect Reference Architecture Artifact Role

RUP Disciplines Implementation Implementation Create, assemble, and integrate components and subsystem into an executable system System Integrator Integration Build Plan Implementer Implementer System Integrator Implementation Model Implementation Subsystem Component Architect Implementation Model Artifact Role

RUP Disciplines Test Test test the developed components as units . integrate the results produced by individual implementers into executable verify the interaction between objects. verify that all requirements have been correctly implemented Test Designer Test Evaluation Summary Tester Test Results Implementer Implementer Test Subsystem Test Component Designer Designer Test Package Test Class Test Designer Workload Model Test Designer Test Script Test Designer Test Designer Test Designer Test Model Test Procedure Test Case Test Designer Test Plan Artifact Role

RUP Disciplines: Deployment Deployment Turn the finished software product over to its users Producing external releases of the software. In some case includes: Planning and conduct of beta tests. Migration of existing software or data. Formal acceptance. Graphic Artist Product Artwork Course Developer Training Material Technical Writer Support Material Implementer Installation Component Deployment Manager Release Notes Deployment Manager Bill of Materials Deployment Manager Deployment Plan Artifact Role

RUP Disciplines Configuration and Change Management Configuration and Change Management Assess product quality Simultaneous Update Multiple Versions Change Control Manager Change Request Configuration Manager Configuration Audit Findings Configuration Manager Project Repository Configuration Manager Configuration Management Plan Artifact Role

RUP Disciplines: Project Management Project Management Plan an iterative process Decide duration and content of an iteration provide practical guidelines for planning, staffing, executing, and monitoring projects provide a framework for managing risk Project Reviewer Review Record Project Manager Project Measurements Project Manager Work Order Project Manager Status Assessment Project Manager Iteration Assessment Project Manager Project Manager Project Manager Project Manager Project Manager Project Manager Software Development Plan Iteration Plan Problem Resolution Plan Risk Management Plan Product Acceptance Plan Measurement Plan Project Manager Business Case Artifact Role

RUP Disciplines: Environment Environment Track and maintain the integrity of evolving project assets Support the development organization with processes and tools Turn the finished software product over to its users Process improvement Tool Specialist Tools Tool Specialist Tool Support Assessment System Administrator Supporting Environment Process Engineer Many Workers Development Case Guidelines (Design, Test, etc.) Process Engineer Project-Specific Templates Process Engineer Development Organization Assessment Process Engineer Quality Assurance Plan Artifact Role

Additional Static Elements Guidelines Rules, recommendations, techniques, or heuristics to support activities and artifacts Templates Models of artifacts that can be used to create the artifact Usually associated with a tool Concepts Discussions on particular concepts (e.g., iteration, risk) associated with the process Tool mentors Show how to perform a set of process steps using a specific tool

Static and Dynamic Aspect in view Core Workflows Supporting Workflows Project Management Environment Business Modeling Implementation Test & Assessment Analysis & Design Deployment Configure. & Change Mgmt Requirements Preliminary Iteration(s) Iter. #1 Phases Iterations Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Elaboration Transition Inception Construction Time : Dynamic Aspect Stat ic Aspect

Models and Workflows Each major workflow describes how to create and maintain a particular model. Business Modeling Business Model implemented by Implementation Model Implementation Workflow Test Model Test Workflow verified by Use-Case Model Requirements Workflow Build upon realized by Design Model Analysis Design Workflow Deployment Workflows Used by Deployment model

Software Architecture In each project there are different interests upon the architecture based on the role who is looking at the project. implementers view of project is difference with the designers view And Deployer’s is different with End-user. So architecture is multidimensional . Based on the definition of Architecture: Architecture should be easy to understand for all stakeholders Different interests look at architecture. ,interests are based on roles, Stakeholders have different roles and different specialties . Architecture should bring an useful , understandable view for each stakeholder. Architecture should be multi view.

Architecture activities: the 4+1 view logical view object model of the design (when an object-oriented design method is used) process view captures the concurrency and synchronization aspects of the design Deployment view describes the mapping(s) of the software onto the hardware and reflects its distributed aspect development view describes the static organization of the software in its development environment Use-Case view It contains a few key scenarios or use cases RUP & Software Architecture

More on The “4+1 View” Model Table 5-1. The Relationship between Models and Views Process View Deployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance Scalability Throughput System integrators System topology Delivery, installation communication System engineering Analysts/Designers Structure Use-case view Use-case model Deployment view Deployment model Implementation view Implementation model Process view Design model Logical view Design model Architectural View Model

RUP a product designed and documented using the Unified Modeling Language (UML) delivered online using Web technology easy to access regular upgrades are released process is never obsolete users benefit from the latest development All team members access the same version of the process modular and in electronic form can be tailored and configured to suit the specific needs of a development organization integrated with the many software development tools in the Rational Suites developers can access process guidance within the tool they are using

RUP VS. MSF MSF Lack of details Simple, direct and flexible Method Waterfall and Iterative Based on spiral and waterfall than iterative Mostly disciplines , not methodology RUP Process and methodology Object Orientation Detail roles description Give models and examples to each artifact UML documents compatible Can be used as a full version or be customized by project Iterative Very detailed (~30 roles) 6 basic roles Team Model 4 phases with activities detailed 5 Phases Process Model Difficult easy Utilization Complex Simple Complexity RUP MSF Aspect

Overall Comparison Project Management Risk Management Readiness Management Business Modeling Requirements Analysis & Design Implementation , Test Deployment , Environment Project Management Configuration & Change Management Disciplines Product Management Role Cluster Developer Role Cluster Testing , User Experience Release Management Additional Team Members Analyst Role Set Developer Role Set Tester Role Set Manager Role Set Additional Role Set Team Model Envisioning , Planning Development ,Stabilizing Deployment Interception , Elaboration Construction , Transition Phases Iterative Iterative Process Model MSF RUP

Phases comparison Implementation Development Complete Visional Scope Approved Release Readiness Approved Project Plans Approved Scopes Complete Envisioning Planning Development Stabilizing Deployment Initial Planning Planning Requirements Analysis and Design Deployment Test Evaluation Management Environment

Phases comparison The above show how phases in MSF and RUP are mapped , but there is one thing that We should consider about , there is a phase named Stabilizing in MSF which address issues about project tests of all kind , about 40 percent of the stabilizing phase of MSF is distributed between all Phase of RUP , mostly in construction and elaboration. I can not find a way to show this mater so pleas consider it yourself and draw some N* dimensional image on your head yourself. Inception Elaboration Construction Transition Development Planning Envisioning Stabilizing Deployment MSF RUP

MSF and RUP wide Acceptance comparison search engine process *Search have Done after Microsoft Wide Search update (November-2004) **RUP And MSF alone can not be used in search because each of them are used in other industries like Motor Cycle production ,… ***search have done with exact phrase mentioned above. 6 34 2 6 Amazon ** ** 4210 17217 MSN ** ** 48,900 141,000 Google MSF RUP “ Microsoft Solutions Framework” “ Rational Unified Process”

Conclusion... It is important to have a Process Engineer dedicated to the project The Process Engineer of the Company must to: Have enough experience and qualification on RUP Have the capability to customize RUP Should know the Company and it procedures Preference be a PMP Should have experience in Process Area Guarantee the Process * Big companies should have one or more dedicated people * Small companies can share the role with the Project Manager

Conclusion... The Project Manager of each project must to: Know deeply and apply at least the RUP six best practices; Follow the RUP and help people on the all disciplines integration; Work close with the people of the disciplines “CCM” and “Environment”; Guarantee and do the peer review on the Disciplines Guidelines; Create and maintain: Business Case, Issue List, Risk List and Software Development Plan. Create and validate a Iteration Assessment for each iteration; Create and Maintain a Iteration Plan for each iteration .

Final Conclusion No vision? No process? No Plan No Risk List? No Business Case? No Architecture? No Prototype? No Evaluation? No Change Request? No user Support? Chaotic situation! No guarantee of a project delivery! No satisfaction of our customer! Project failure!

References The Rational Unified Process An Introduction, Second Edition Philippe Kruchten , Publisher: Addison Wesley Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B, Rev 11/01 MSF Process Model v. 3.1 , Microsoft June 2002 Software Development for Small Teams: A RUP-Centric Approach By Gary Pollice, Liz Augustine, Chris Lowe, Jas Madhur .Publisher : Addison Wesley The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, By Per Kroll, Philippe Kruchten. Publisher : Addison Wesley The Rational Unified Process An Introduction, Second Edition Philippe Kruchten. Publisher: Addison Wesley From Waterfall to Iterative Lifecycle – A tough transition for project managers P. Krutchen, Architectural Blueprints - The "4+1" View Model of Software Architecture, www.rational.com RUP 2002 product documentation.

Thank you Thank you for your attentions. All your suggestion and comment are welcome. You can contact me by looking at : http:// weblogs.java.net/blog/kalali/ Masoud Kalali . http:// weblogs.java.net/blog/kalali / November 2004

An Overview of RUP methodology

In this document

More Related Content

What's hot

Viewers also liked

Similar to An Overview of RUP methodology

More from Masoud Kalali

Recently uploaded

An Overview of RUP methodology