RUP Fundamentals Instructor Notes

RUP Fundamentals Instructor Notes
Rational Unified Process Fundamentals Module 2: RUP Structure and Content Module 2 - RUP Structure and Content

Objectives: Rational Unified Process Structure
RUP Fundamentals Instructor Notes Objectives: Rational Unified Process Structure 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 Module 2 - RUP Structure and Content

A Development Process Should:
RUP Fundamentals Instructor Notes A Development Process Should: 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. Not be another process gathering dust. A software development process should not only tell you what to do, it should also provide assistance on how to do it. Process should provide you with a structure which allows you to manage risk. Communication lies at the heart of process. Process can help team members speak the same development language and understand common goals. A software development process should also contain the cumulative experience of software professionals, with specific guidelines to convey those experiences. Module 2 - RUP Structure and Content

Rational Unified Process
RUP Fundamentals Instructor Notes Rational Unified Process Provides guidelines for efficient development of quality software Reduces risk and increases predictability Captures and presents best practices Provides learning from others’ experiences Acts as a mentor on your desktop Provides an extension of training material Promotes common vision and culture Mentors successful use of our tools For students accustomed to thinking in terms of business process, it may be useful to explain how RUP is a business process. RUP is a generic business process for object oriented software engineering. RUP describes a family of related software engineering business processes Common structure Common process architecture RUP assigns tasks and responsibilities in a development organization. RUP represents the combined experience of many people on a variety of projects. RUP provides information on how to manage risk. You can automate process through the effective use of tools. RUP shows how to use Rational Software tools to accomplish work described in the process. RUP is a Web-enabled, searchable knowledge base which is integrated with Rational tools and provides project members with an online mentor covering the full lifecycle. Tool mentors provide guidance on how to effectively use Rational tools in the context of Rational Unified Process. Module 2 - RUP Structure and Content

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. Some have the notion that just by using UML you are following a process. Clear up any confusion that exists on that point. UML is integral to RUP, but it is a modeling language, not a process. Clarification of UML and Process: Rational has worked with OMG on the definition of a meta model for software development processes. This work is called SPEM. It provides a consistent way to describe processes, but is not a process in its own right. In order for development organizations to reap the true benefits of the UML, they need to know how to use it effectively. Module 2 - RUP Structure and Content

RUP Structure Organization along time Lifecycle structure: phases, iterations Process enactment: planning, executing Activity management, project control Organization based on content Disciplines, roles, artifacts, activities Process configuration, process enhancement The module is organized according to the time (dynamic) and content (static) structures. The time structure refers to the lifecycle aspect of the process, in other words, how the process rolls out within the duration of a project. The content structure refers to the Disciplines, which group activities logically by nature. Module 2 - RUP Structure and Content

Organization Along Time
RUP Fundamentals Instructor Notes Organization Along Time Time The time aspect of the process as it is enacted is shown by phases, iterations, and milestones. Use of these helps minimize risk of your resource allocation since resources are allocated only on a firm basis. Organization by phases helps minimize the risks of resource allocation. Module 2 - RUP Structure and Content

Major Milestones: Business Decision Points
RUP Fundamentals Instructor Notes Major Milestones: Business Decision Points Customer acceptance or end of life Product Release Product sufficiently mature for customers Initial Operational Capability Milestone Phases represent the management perspective of the project, the “35,000 foot level.” The details are left to the engineering perspective, which is at the iteration level. The names of the milestones are identical to the ones proposed by Barry Boehm in the article “Anchoring the Software Process,” IEEE Software, July 1996, pp Commit resources for construction Lifecycle Architecture Milestone Commit resources for the elaboration phase Lifecycle Objective Milestone Inception Elaboration Construction Transition The phases of RUP were chosen such that phase boundaries correspond to significant decision points in the life of a project. For example, at the end of Inception, enough work has been done to capture the problem to be solved, and a vision of the system has been developed. An initial set of risks has also been identified and evaluated. Based on this information, a decision must be made whether to fund the project. Similar decision points correspond to the end of Elaboration, Construction, and Transition. Milestones help us assess the progress of a project at key points. Management can use these to establish clear criteria from which to decide the course of a project. They provide opportunities to change course. But unlike the waterfall approach, phases contain iterations which yield executable results. time Module 2 - RUP Structure and Content

Inception Phase The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these. We don’t have time to go into them in that much detail. Note: In addition to an estimate for the elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of elaboration. Module 2 - RUP Structure and Content

Inception Phase: Objectives
RUP Fundamentals Instructor Notes 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) We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these. We don’t have time to go into them in that much detail. Note: In addition to an estimate for the elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of elaboration. Module 2 - RUP Structure and Content

Inception Phase: Artifacts
RUP Fundamentals Instructor Notes Inception Phase: Artifacts The outcome of the inception phase is the creation of these artifacts A vision document outlining the core requirements, key features and main constraints A high-level use-case model Initial project glossary (project terms and definitions) An initial business case containing ROI, etc. An initial risk assessment A project plan showing phases and iterations. Don’t spend too much time on the details of this slide. The Iterative Development module goes into this in much more depth. Module 2 - RUP Structure and Content

Inception Phase: Evaluation Criteria
RUP Fundamentals Instructor Notes Inception Phase: Evaluation Criteria Stakeholder concurrence on scope definition and cost/schedule estimates Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate All risks have been identified and a mitigation strategy exists for each Don’t spend too much time on the details of this slide. The Iterative Development module goes into this in much more depth. Milestone: Lifecycle Objectives (LCO) Module 2 - RUP Structure and Content

Elaboration Phase The overriding goal of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the project’s high-risk elements. We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these. We don’t have time to go into them in that much detail. Note: In addition to an estimate for the elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of elaboration. Module 2 - RUP Structure and Content

Elaboration Phase: Objectives
RUP Fundamentals Instructor Notes 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 The cost and schedule to complete are re-estimated at the end of this phase. At this point they are considered stable (high confidence), and firm commitments can be made. Module 2 - RUP Structure and Content

Elaboration Phase: Evaluation Criteria
RUP Fundamentals Instructor Notes Elaboration Phase: Evaluation Criteria Product Vision and requirements are stable. Use-case model is at least 80% complete. Supplementary requirements largely completed. Architecture is stable. Executable architectural prototype developed Key test and evaluation approaches are proven; major risk elements have been addressed and resolved. Revised risk list Iteration plans for construction phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates. Milestone: Lifecycle Architecture (LCA) Module 2 - RUP Structure and Content

Elaboration Phase: Evaluation Criteria
RUP Fundamentals Instructor Notes Elaboration Phase: Evaluation Criteria Iteration plans for construction phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates. All stakeholders agree that current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture. Actual resource expenditure versus planned expenditure are acceptable. Preliminary users manual developed. Milestone: Lifecycle Architecture (LCA) Module 2 - RUP Structure and Content

Construction Phase The overriding goal of the construction phase is to develop all remaining components and features and integrate them into the product. We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these. We don’t have time to go into them in that much detail. Note: In addition to an estimate for the elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of elaboration. Module 2 - RUP Structure and Content

Construction Phase: Objectives
RUP Fundamentals Instructor Notes 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 Module 2 - RUP Structure and Content

Construction Phase: Evaluation Criteria
RUP Fundamentals Instructor Notes Construction Phase: Evaluation Criteria The evaluation criteria for the construction phase involve the answers to these questions: Is this product release stable and mature enough to be deployed in the user community? Are all the stakeholders ready for the product’s transition into the user community? Are actual resource expenditures versus planned still acceptable? For later iterations in this phase Deployment plan packaging pricing roll-out support training production transition strategy User documentation Milestone: Initial Operational Capability (IOC) “beta” Module 2 - RUP Structure and Content

Transition Phase The overriding goal of the transition phase is to move the product to the user community. We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these. We don’t have time to go into them in that much detail. Note: In addition to an estimate for the elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of elaboration. Module 2 - RUP Structure and Content

Transition Phase: Objectives
RUP Fundamentals Instructor Notes 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 During the transition phase, a decision is made whether to release the product. Module 2 - RUP Structure and Content

Transition Phase: Evaluation Criteria
RUP Fundamentals Instructor Notes Transition Phase: Evaluation Criteria The primary evaluation criteria for the transition phase involve the answers to these questions: Is the user satisfied? Are actual resources expenditures versus planned expenditures acceptable? The decision about whether or not to release the product will be based primarily on the level of user satisfaction achieved during the transition phase. Often this milestone coincides with the initiation of another development cycle to improve or enhance the product. In many cases, this new development cycle may already be underway. Milestone: Product release (“GA”) Module 2 - RUP Structure and Content

What Is an Iteration? An iteration is one pass through all disciplines. An iteration can be seen as a mini project with a plan, deliverables and assessment, in which periodic corrections are applied to the remainder of the project. If you are using the four phases of RUP, you are already using iterations, but more iterations can be added to each phase if needed. Module 2 - RUP Structure and Content

Phases and Iterations Iterations represent the engineering perspective of the project. This is what concerns the developers on a day-to-day basis. Planned (Business) Decision Points Commit resources for the elaboration phase Commit resources for construction Product sufficiently mature for customers to use Acceptance or end of life (Understand the problem) (Understand the solution) (Have a solution) Inception Elaboration Construction Transition Preliminary Iteration Architect. Devel. Transition The focus of an iteration changes across the cycle. Recall that each iteration is, in a sense, a mini-waterfall. The iteration plan contains the activities of requirements elicitation and analysis, of design and implementation, and of integration and test. The emphasis on the various activities changes, however, from one iteration to the next. Planned (Technical) Visibility Points Module 2 - RUP Structure and Content

Iteration: Number and Duration
RUP Fundamentals Instructor Notes Iteration: Number and Duration Duration driven by + size of organization + size of project - familiarity with the process, maturity - technical simplicity 6, plus or minus 3 Inception: Elaboration: Construction: Transition: “+” indicates factors which might cause longer iterations. “-” indicates factors which might shorten an iteration. Once you know the length of an iteration appropriate to your organization, you can decide how many iterations to plan in each phase. If Inception consists only of planning and marketing, then there may be no real iteration. If you need a prototype or need to immediately address a technical risk, you will need an iteration. The number of iterations in Elaboration may depend on the complexity of the architecture, where you’re starting from, and the experience of the team. During Construction, you can use iterations to do a good job of testing and integration. Sufficient automation can make more iterations easier to deal with. Also, a mature process could accommodate more iterations. Transition would require at least one iteration, and more if conditions at the time of transition make more iterations necessary. Module 2 - RUP Structure and Content

One Iteration In an iteration, you walk through all disciplines. A given iteration includes multiple disciplines. The form the discipline will take varies, depending on its position within the overall lifecycle, and the nature of the project. Module 2 - RUP Structure and Content

Organization Based on Content
RUP Fundamentals Instructor Notes Organization Based on Content Content Organization into disciplines shows the content of the process—the activities, artifacts, and roles. Module 2 - RUP Structure and Content

Key RUP Elements: Roles, Activities, Artifacts
RUP Fundamentals Instructor Notes Key RUP Elements: Roles, Activities, Artifacts Role Activity Artifact responsible for performs In UML terms: Role = active object Activity = operation on a Role Artifact = parameter of the Activity If a process describes who is doing what and how, then the primary elements of Rational Unified Process can be described as: Roles: the who Activities: the how Artifacts: the what A Role performs certain Activities and is responsible for certain Artifacts. Module 2 - RUP Structure and Content

Roles Perform Activities and Produce Artifacts
RUP Fundamentals Instructor Notes Roles Perform Activities and Produce Artifacts Example: Requirements-> Workflow Detail-> Define the System An Artifact is a work product of the process: roles use artifacts to perform activities and produce artifacts in the course of performing activities. Artifacts are the responsibility of a single role, to promote the idea that every piece of information in the process must be the responsibility of a specific person. Even though one person may "own" the artifact, many other people may use the artifact, perhaps even updating it if they have been given permission. The workflow detail diagram shows a set of activities that are often done as a group. It also shows input and output artifacts (indicated with arrows), as well as the roles involved. Module 2 - RUP Structure and Content

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 have a set of cohesive activities that they perform. These activities are closely related and functionally coupled. The activities are cohesive in the sense that they are best achieved when combined and performed by one person. However, it is possible for one Role to be played by more than one team member, in which case that group of team members would be responsible for the related activities and artifacts. Module 2 - RUP Structure and Content

Roles Are Used for Resource Planning
RUP Fundamentals Instructor Notes Roles Are Used for Resource Planning This is really standard resource allocation and should be familiar to all project managers and tech leads. The only point to be made is that typically the roles defined in the RUP do not correspond to the activities of just one individual (with the exception of the architect, perhaps). Otherwise, it is a many to many mapping. Resource Paul Mary Joe Sylvia Stefan Role Designer Requirements Specifier System Analyst Implementer Architect Activities Define Operations Detail a Use Case Find Actors and Use Cases Perform Unit Tests Identify Design Mechanisms In developing a project plan, a project manager assigns the individuals available to roles according to their skills and abilities. The project manager assigns each individual on the project to one or more roles. The association of individuals to roles is dynamic over time. An individual may act as several different roles during the same day. We can informally call this “wearing several hats.” Sylvia may be both a design reviewer and a use-case designer. Several individuals may act as the same role to perform a certain activity as a team. Paul and Mary may serve as the use-case designer for a single use case. Each individual in the project is assigned to one or several roles Module 2 - RUP Structure and Content

Key RUP Element: Activity
RUP Fundamentals Instructor Notes 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 Examples of Activities: Develop Iteration Plan Find Actors and Use Cases Review the Design Execute Test Module 2 - RUP Structure and Content

Key RUP Element: Artifact
RUP Fundamentals Instructor Notes 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 Anything produced, evolved, or used by the process is considered to be an artifact, including: Model Model element Document Source code Executables Artifacts are produced while working toward the final product. If we look in a workflow at the Workflow Detail level, we see that artifacts are input to and output from Workflow Details. Only one role is responsible for a given artifact. However, an artifact may contain other artifacts which are the responsibility of other roles (see Artifact: Software Development Plan). An artifact can evolve or change as the iterations progress. Module 2 - RUP Structure and Content

Key RUP Elements: Roles, Activities, Artifacts
RUP Fundamentals Instructor Notes Key RUP Elements: Roles, Activities, Artifacts In UML terms: Role = active object Activity = operation on a Role Artifact = parameter of the Activity Role Activity Artifact responsible for performs Disciplines also contain Workflows and Workflow Details, as you will see. Module 2 - RUP Structure and Content

Nine Disciplines RUP uses the term Discipline to describe all activities you may go through to produce a particular set of artifacts—a summary of all roles, activities, artifacts, concepts and guidelines that are involved. The disciplines partition the roles and activities into logical groupings. The groupings should not be taken as a waterfall process. You visit these disciplines repeatedly throughout the lifecycle. The emphasis and levels of intensity change with each iteration. Module 2 - RUP Structure and Content

Elements of a Discipline
RUP Fundamentals Instructor Notes Elements of a Discipline If you expand any Discipline in the RUP tree browser, you will see the following: This simply lists the “pieces” of the discipline. Disciplines consist of the following: Introduction Purpose of the discipline and relationships to other disciplines. Concepts Key concepts that are important for understanding the discipline. Workflow A conditional flow of events when conducting the discipline, expressed in terms of workflow details. A workflow detail is a grouping of activities that are done together. Activity Overview The activities that are performed in this discipline, and the roles that perform them. Artifact Overview The artifacts that are produced in this discipline, and the roles that are responsible. Guidelines Overview More detailed explanations on how to use and produce the artifacts of the process. Module 2 - RUP Structure and Content

Key RUP Element: Workflow
RUP Fundamentals Instructor Notes Key RUP Element: Workflow The conditional flow of high-level activities (Workflow Details) that produces a result of observable value. Workflows describe a conditional flow of Workflow Details that produce a valuable result. RUP uses a UML activity diagram to represent workflows. Workflow Details show closely related activities. Module 2 - RUP Structure and Content

Workflow Details Example: Environment: Workflow Example: Workflow Detail: Prepare Environment for Project Workflow Details are: A grouping of activities that are performed in close collaboration to accomplish some result. A unit of planning. Typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows. Module 2 - RUP Structure and Content

Workflow Path Is Adapted to:
RUP Fundamentals Instructor Notes Workflow Path Is Adapted to: Position in Lifecycle Phase Artifacts being produced Technology Iteration goals Example: Analysis & Design Module 2 - RUP Structure and Content

Workflows Guide Iterative Development
RUP Fundamentals Instructor Notes Workflows Guide Iterative Development Business Modeling: Workflow Details This slide shows how the discipline can be decomposed into smaller pieces. You can reinforce the structure by showing the equivalent in RUP. The paths through the disciplines vary depending on the phases and iterations of the lifecycle. Requirements: Workflow Details Module 2 - RUP Structure and Content

Iteration Plan Includes relevant portions of Discipline for a particular iteration A given iteration includes multiple disciplines. The form a discipline will take varies, depending on its position within the overall lifecycle and the nature of the project. The Iteration Plan includes all relevant portions of the disciplines for that particular iteration. Module 2 - RUP Structure and Content

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 Module 2 - RUP Structure and Content

Sample Iteration Plan Example: Table of Steps for an Inception Iteration Show the student the example iteration plans found in the top level of the tree structure. RUP contains sample iteration plans. Each sample iteration plan shows the context and a table of steps. Each step points to the involved roles, activities and artifacts. Module 2 - RUP Structure and Content

Artifact Set Evolution Over the Development Phases
RUP Fundamentals Instructor Notes Artifact Set Evolution Over the Development Phases With the iterative approach, artifact sets mature over time. Artifacts are organized into sets, one set per discipline. In an iterative development process, the various artifacts are not produced in one phase, completed or even frozen before moving on to the next phase. Instead, the artifact sets evolve throughout the development cycle. Module 2 - RUP Structure and Content

Summary of Major Artifacts
RUP Fundamentals Instructor Notes Summary of Major Artifacts Having been introduced to the concept of disciplines, students should understand that Artifacts evolve Can be used in more than one discipline This figure shows some of the major artifacts and the approximate flow of information between them. Information flows through the project via the artifacts. Arrows show how changes in one artifact ripple through other artifacts along the arrows. Many artifacts are omitted from this picture. The design model would, for example, contain many other artifacts. Module 2 - RUP Structure and Content

Economy of Artifacts RUP’s use of Artifacts allows you to: Produce only the artifacts that get used Keep the artifact in the most appropriate tool, in electronic form (Rose, Excel, RequisitePro, etc.) Use reports to extract snapshots of information out of models in tools, for review (SoDA, scripts, etc.) Put effort into artifacts that are part of the product (e.g. models) Artifacts are produced in each phase and iteration, but you produce only the ones that will be used. Most artifacts of the process are models (for example, use-case model or design model), and they can be kept in the most appropriate development tool. Very few artifacts are documents (for example, plans and status assessments). The process also defines reports. Reports are documentation generated for review purposes. Reports come “for free” in the sense that tools can automate report creation. For example, the Use-Case Model Survey would be an extraction of the use-case model elements relevant for this report. Artifacts are baselined and configuration-managed; reports are generated when needed and are not baselined. Module 2 - RUP Structure and Content

Additional Process Elements
RUP Fundamentals Instructor Notes Additional Process Elements Discipline Introduction Concepts Workflow Activity Overview And associated Tool Mentors and Guidelines Artifact Overview And associated Templates and Guidelines Guidelines Overview Roadmaps Module 2 - RUP Structure and Content

Process Element: Concepts
RUP Fundamentals Instructor Notes Process Element: Concepts Attached to the relevant Discipline Explanation of key ideas Examples of Concepts Requirements Requirements Management Types of Requirements Traceability Analysis and Design Software Architecture Analysis Mechanisms Web Architecture Patterns If RUP is a knowledge base, many of the main ideas are to be found in the Concepts attached to each discipline. You can find important ideas central to RUP, such as Use-Case Driven Development and Architecture-centric, under Concepts. Concepts present topics which are relevant for a given discipline. They are essential ideas associated with a discipline. The information contained in concepts can provide information necessary to completing a task. Suppose, for example, you must create an Artifact: Software Requirements Specification. Concepts allow you to tap into the RUP knowledge base and gain essential expertise. In this case, you might use concepts such as: Concepts: Requirements Concepts: Requirement Types Concepts: Requirements Management Concepts: Traceability Module 2 - RUP Structure and Content

Process Element: Guidelines
RUP Fundamentals Instructor Notes Process Element: Guidelines These are Rules, recommendations, heuristics that support activities and their steps. They: Describe specific techniques. Transformations from one artifact to another Use 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. Guidelines are both artifacts and elements of the process. They are developed as needed on a project for use by other roles in the production of artifacts. Guidelines are artifacts created during the process which become part of the process. Guidelines are used throughout system development to ensure consistency of all artifacts produced. They are developed by the following roles: Business Process Analyst System Analyst User Interface Designer Software Architect Technical Writer Test Designer Module 2 - RUP Structure and Content

Process Element: Tool Mentors
RUP Fundamentals Instructor Notes 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: RequisitePro: requirements management Rational Rose: visual modeling, using UML SoDA: documentation generation ClearQuest: change management, defect tracking …and more Tool Mentors provide detailed descriptions on how Rational Software Tools can be used to support particular steps and activities. Module 2 - RUP Structure and Content

Process Element: Templates
RUP Fundamentals Instructor Notes Process Element: Templates Attached to relevant document type Predefined artifacts, prototypes: Documents (Microsoft® Word™, Adobe® Framemaker™) MS Project HTML Tailored for the process There are a number of ready-to-use templates, which present documents and artifacts. RUP provides templates for use with Microsoft® Word™, Adobe® FrameMaker™, HTML, and Microsoft®Project. It also provides guidance on how to use standard templates which are provided with Rational Rose™ and Rational SoDA™. The Microsoft® Word™ templates can be used with Rational Requisite®Pro. Module 2 - RUP Structure and Content

Process Element: Roadmap
RUP Fundamentals Instructor Notes Process Element: Roadmap 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. Show the roadmaps currently present in RUP. Module 2 - RUP Structure and Content

RUP Fundamentals Instructor Notes

Similar presentations

Presentation on theme: "RUP Fundamentals Instructor Notes"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

RUP Fundamentals Instructor Notes

Similar presentations

Presentation on theme: "RUP Fundamentals Instructor Notes"— Presentation transcript:

Similar presentations

About project

Feedback