4. RUP 2007

What Is the Rational Unified Process? The RUP is a software development approach that is iterative, architecture-centric, and use-case-driven The RUP is a well-defined and well-structured software engineering process The RUP is also a process product that provides you with a customizable process framework for software engineering

Use Case driven A use case is a piece of functionality in the system that gives a user a result of value Use cases capture functional requirements Use case answers the question: What is the system supposed to do for the user?

Architecture centric Architecture centric similar to architecture for building a house Embodies the most significant static and dynamic aspects of the system Influenced by platform, OS, DBMS etc. Primarily serves the realization of use cases

Iterative and Incremental commercial projects continue many months and years to be most effective - break the project into iterations Every iteration - identify use cases,create a design, implement the design Every iteration is a complete development process

Waterfall and Iterative Process

Iterative and Incremental Development Process Iteration No. 1 2 3 867 868 Test whole Integrate Test units Implement Design Analyze requirements

Classification of iterations (Classically called “phases”) UP Terminology (1) Classification of iterations Individual iteration Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. ….. … Requirements Analysis UP calls these “disciplines” (Classically called “phases”) Design Implemen- tation Test

The Unified Process Look at the whole process Life cycle Artifacts Disciplines (Workflows) Phases Iterations

UP Phases: Classification of Iterations Inception iterations: preliminary interaction with stakeholders primarily customer users financial backers etc. Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline Construction iterations : results in initial operational capability Transition iterations : completes product release

Requirements analysis UP Terminology (2) Requirements Analysis Design Implementation Test Requirements analysis UP Terminology Classical Terminology Integration

Unified Process Matrix Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. ….. ….. Requirements Analysis Amount of effort expended on the requirements phase during the first Construction iteration Design Implemen- tation Test

Inception Phase Overriding goal is obtaining buy-in from all interested parties Initial requirements capture Cost Benefit Analysis Initial Risk Analysis Project scope definition Defining a candidate architecture Development of a disposable prototype Initial Use Case Model (10% - 20% complete) First pass at a Domain Model

Elaboration Phase Requirements Analysis and Capture Use Case Analysis Use Case (80% written and reviewed by end of phase) Use Case Model (80% done) Scenarios Sequence and Collaboration Diagrams Class, Activity, Component, State Diagrams Glossary (so users and developers can speak common vocabulary) Domain Model to understand the problem: the system’s requirements as they exist within the context of the problem domain Risk Assessment Plan revised Architecture Document

Construction Phase Focus is on implementation of the design: cumulative increase in functionality greater depth of implementation (stubs fleshed out) greater stability begins to appear implement all details, not only those of central architectural value analysis continues, but design and coding predominate

Transition Phase The transition phase consists of the transfer of the system to the user community It includes manufacturing, shipping, installation, training, technical support and maintenance Development team begins to shrink Control is moved to maintenance team Alpha, Beta, and final releases Software updates Integration with existing systems (legacy, existing versions, etc.)

Elaboration Phase in Detail Use Case Analysis Find and understand 80% of architecturally significant use cases and actors Prototype User Interfaces Prioritize Use Cases within the Use Case Model Detail the architecturally significant Use Cases (write and review them) Prepare Domain Model of architecturally significant classes, and identify their responsibilities and central interfaces (View of Participating Classes)

Use Case Analysis What is a Use Case? A sequence of actions a system performs that yields a valuable result for a particular actor. What is an Actor? A user or outside system that interacts with the system being designed in order to obtain some value from that interaction Use Cases describe scenarios that describe the interaction between users of the system and the system itself. Use Cases describe WHAT the system will do, but never HOW it will be done.

Use Cases Describe Function not Form Use Cases describe WHAT the system should do, but never HOW it will be done Use cases are Analysis products, not design products

Benefits of Use Cases Use cases are the primary vehicle for requirements capture in RUP Use cases are described using the language of the customer (language of the domain which is defined in the glossary) Use cases provide a contractual delivery process (RUP is Use Case Driven) Use cases provide an easily-understood communication mechanism When requirements are traced, they make it difficult for requirements to fall through the cracks Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

Difficulties with Use Cases As functional decompositions, it is often difficult to make the transition from functional description to object description to class design Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?) Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious

Analysis Model In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer: Boundary Classes Entity Classes Control Classes

Why spend time on the Analysis Model, why not just “face the cliff”? By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system By providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a ‘bird’s eye view’, without having to get bogged down with implementation details. The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By “speaking the developer’s language”, comprehension is improved and by abstracting, simplicity is achieved Nevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along.

Boundary Classes Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems) Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.) Boundary classes can often be abstractions of external APIs (in the case of an external system actor) Every boundary class must be associated with at least one actor:

4+1 Architecture

4+1 Architecture Use-Case View, which contains use-cases and scenarios that encompasses architecturally significant behavior, classes, or technical risks. It is a subset of the total use-case model. Logical View, which contains the most important design classes and their organization into packages and subsystems, and the organization of these packages and subsystems into layers. It can also contain some use case realizations. It is a subset of the total design model

4+1 Architecture Implementation View, which contains an overview of the implementation model and its organization in terms of modules into packages and layers. The allocation of packages and classes (from the Logical View) to the packages and modules of the Implementation View is also described. It is a subset of the total implementation model Process View, which contains the description of the tasks (process and threads) involved, their interactions and configurations, and the allocation of design objects and classes to tasks. This view need only be used if a system has a significant degree of concurrency

4+1 Architecture Deployment View, which contains the description of the various physical nodes for the most typical platform configurations, and the allocation of tasks (from the Process View) to the physical nodes. This view shows how a system is distributed.

Architectural focus The architecture concerns itself only with some specific aspects: The structure of the model - the organizational patterns, e.g. layering The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the elements present in the model A few key scenarios showing the main control flows throughout the platform The services, to capture modularity, optional features, product-line aspects

RUP— The Approach

Underlying Principles of the RUP Approach Attack major risks early and continuously . . . or they will attack you Ensure that you deliver value to your customer

The Spirit of the RUP – Essential Principles Attack major risks early and continuously…or they will attack you Ensure that you deliver value to your customer Stay focused on executable software Accommodate change early in the project Baseline an executable architecture early on Build your system with components Make quality a way of life, not an afterthought

RUP and Iterative Development

The Iterative Approach It accommodates changing requirements Integration is not one "big bang" at the end of a project Risks are usually discovered or addressed during early integrations Management has a means of making tactical changes to the product Reuse is facilitated Defects can be found and corrected over several iterations It is a better use of project personnel Team members learn along the way The development process itself is improved and refined along the way

The Phased Iterative Approach – example In the first iteration we will do 90% analysis, 10% design In the second iteration we will do 30% analysis, 50% design, 20% coding In the third iteration we will do 10% analysis, 30% design, 60% coding In the fourth iteration we will do 10% design, 50% coding, 40% testing and bug fixing In the fifth iteration we will do 50% testing and bug fixing, 30% integration, 20% deployment

Iterative Development with Incremental Delivery First, we go through several iterations of analysis and design, until we are pretty sure these phases are mostly complete. We can then select the content and schedule of the increments to be developed. Let’s have identified three increments A, B and C, to be delivered in this order to the users. For increment A, we iterate through all required phases, until the software can be released. We expect to rework the analysis and design very little. For increment B, we iterate through all required phases, until the software can be released. We expect almost no analysis or design work. For increment C, we iterate through all required phases, until the software can be released. The amount of analysis and (architectural) design decreases in each step. The process delivers functionality after the second, third and fourth steps.

RUP—A Well-Defined Software Engineering Process 01.11

The RUP—A Well-Defined Software Engineering Process Dynamic structure – time dimension Static structure – describes how process elements—activities, disciplines, artifacts, and roles—are logically grouped into core process disciplines

Basic Concepts in the Rational Unified Process

The Dynamic Structure of the Rational Unified Process

RUP Lifecycle

RUP Lifecycle (detail)

Iteration

The Dynamic Structure of the Rational Unified Process Inception Elaboration Construction Transition

The Four Phases

Objectives of the Phases Inception: Understand what to build Elaboration: Understand how to build it Construction: Build a beta version of the product Transition: Build the final version of the product time

Milestones

Resources

Models

Inception

Inception Establish a good understanding of what system to build by getting a high-level understanding of all the requirements and establishing the scope of the system Mitigate many of the business risks, Produce the business case for building the system Get buy-in from all stakeholders on whether to proceed with the project

Inception Phase Objectives: Milestone: Understand the scope of the project Build the business case Get stakeholder buy-in to move ahead Milestone: Lifecycle Objective Milestone (LCO)

Relative cost to fix defect at different lifecycle phases

Stakeholder Needs

Early Lifecycle Activities

Detailing and Review Activities for Use Cases

Software Requirements

Derived business rules at the summary meeting

Elaboration

Elaboration Take care of many of the most technically difficult tasks: Design, implement, test, and baseline an executable architecture, including subsystems, their interfaces, key components, and architectural mechanisms, such as how to deal with inter-process communication or persistency Address major technical risks, such as resource contention risks, performance risks, and data security risks, by implementing and validating actual code

Elaboration Phase Objectives: Milestone: Mitigate major technical risks Create a baselined architecture Understand what it takes to build the system Milestone: Lifecycle Architecture Milestone (LCA)

Workflow for Architectural Analysis

Use-Case Analysis activity

The steps of use case analysis

Use Case Design activity

The steps of Use Case Design

Requirements Management: Discipline Details

Workflow Detail: Analyze the Problem

Workflow Detail: Understand Stakeholder Needs

Workflow Detail: Define the System

Workflow Detail: Manage the Scope of the System

Workflow Detail: Refine the System Definition

Workflow Detail: Manage Changing Requirements

Requirements Artifacts

Construction

Construction Do most of the implementation as you move from an executable architecture to the first operational version of your system Deploy several internal and alpha releases to ensure that the system is usable and addresses user needs End the phase by deploying a fully functional beta version of the system, including installation and supporting documentation and training material (although the system will likely still require tuning of functionality, performance, and overall quality)

Construction Phase Objective: Milestone: Build the first operational version of the product Milestone: Initial Operational Capability Milestone (IOC)

Design artifacts drive development of source code

Transition

Transition Ensure that software addresses the needs of its users This includes testing the product in preparation for release and making minor adjustments based on user feedback At this point in the lifecycle, user feedback focuses mainly on fine-tuning the product, configuration, installation, and usability issues; all the major structural issues should have been worked out much earlier in the project lifecycle

Transition Phase Objective: Milestone: Build the final version of the product and deliver it to the customer Milestone: Product Release Milestone (PR)

The Static Structure of the Rational Unified Process

RUP—A Well-Defined Software Engineering Process

The Static Structure of the Rational Unified Process

Four Key Modeling Elements of the RUP Roles. The who Activities. The how Artifacts. The what Workflows. The when

Roles A role is like a "hat" that an individual (or group) wears during a project. One individual may wear many different hats. This is an important point because it is natural to think of a role as an individual on the team, or as a fixed job title, but in the RUP the roles simply define how the individuals should do the work, and they specify the competence and responsibility that the individual(s) playing that role should have. A person usually performs one or more roles, and several people can perform the same role.

People and Workers John

Activities An activity of a specific role is a unit of work that an individual in that role may be asked to perform The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, a component, or a plan Each activity is assigned to a specific role An activity generally takes a few hours to a few days to complete, usually involves one person, and affects one or only a small number of artifacts An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have to be expressed in terms of an activity's parts Activities may be repeated several times on the same artifact—especially when going from one iteration to another, refining and expanding the system—by the same role, but not necessarily by the same individual

Steps Activities are broken down into steps, which fall into three main categories: Thinking steps, where the person playing the role understands the nature of the task, gathers and examines the input artifacts, and formulates an outcome Performing steps, where the role creates or updates some artifacts Reviewing steps, where the role inspects the results against some criteria Not all steps are necessarily performed each time an activity is invoked, so steps can be expressed in the form of alternate flows.

Artifacts An artifact is a piece of information that is produced, modified, or used by a process Artifacts are the tangible project elements: things the project produces or uses while working toward the final product Artifacts are used as input by roles to perform an activity and are the result or output of other activities

Artifacts Artifacts may take various shapes or forms: A model, such as the Use-Case Model or the Design Model A model element, that is, an element within a model, such as a class, a use case (UC), or a subsystem A document, such as the Vision or Business Case Source code Executables, such as an executable Prototype

Workflows A mere listing of all roles, activities, and artifacts does not quite constitute a process You need a way to describe meaningful sequences of activities that produce some valuable result and to show interactions between roles—this is exactly what workflows do

Workflows Workflows come in different shapes and forms Disciplines, which are high-level workflows Workflow Details, which are workflows within a discipline

Disciplines All process elements—roles, activities, artifacts, and the associated concepts, guidelines, and templates—are grouped into logical containers called Disciplines: Business modeling Requirements management Analysis and design Implementation Deployment Test Project management Change management Environment

The Spirit of the RUP: Guidelines for Success

Attack Major Risks Early and Continuously, or They Will Attack You

Attack Major Risks Early and Continuously, or They Will Attack You At the beginning of each iteration, the RUP advises you to make, or revise, a list of top risks Prioritize the risk list Risks need to be addressed from multiple perspectives such as requirements design, and testing For each of these perspectives, start with a coarse solution and successively detail it to diminish the risk Then decide what you need to do to address, typically, the top three to five risks

Attack Major Risks Early

Ongoing Focus on Risk Addressing the most critical risks early in the life cycle. The goal is to mitigate risks to the greatest extent possible during each iteration, so each iteration poses fewer risks of less importance than its predecessors.

Ongoing Focus on Risk (cont.) Three categories of risks useful in discussing the Unified Process. Technical risks Architectural risks Requirements risk

Technical risks Technical risks are those associated with the various technologies that will come into play during the project and with issues such as performance and the reliability, scalability, etc. The process doesn't specifically address technical risks; however, the emphasis on architecture reflects the principle that the team should address technical risks early, before coding starts.

Architectural risks Architectural risks are those associated with the ability of the architecture to serve as a strong foundation of the system and also be sufficiently resilient and adaptable to the addition of features in future releases of the system. Risks associated with "make versus buy" decisions are also part of this category. The process addresses architectural risks by defining activities that involve analyzing, designing, and implementing the architecture, and by defining a number of other activities that include keeping the architecture description up to date so it can assume its place front and center within the development effort.

Requirements risk Requirements risk is the risk of not building the right system — the system that the customers are paying for — by not understanding the requirements and not using associated use cases to drive development. The process addresses requirements risk with activities specifically defined to facilitate the discovery and negotiation of requirements and with its premise that use cases should drive all aspects of development.

Ensure That You Deliver Value to Your Customer Use-case-driven approach Use cases are a way of capturing functional requirements Since they describe how a user will interact with the system, they are easy for a user to relate to And since they describe the interaction in a time-sequential order, it is easy for both users and analysts to identify any holes in the use case A use case can almost be considered a section in the future user manual for the system under development, but it is written with no knowledge about the specific user interface Use cases force you to stay externally focused on the user's perspective, and they allow you to validate the design and implementation with respect to the user requirements

Accommodate Change Early in the Project We group changes into four categories: Cost of change to the business solution Cost of change to the architecture Cost of change to the design and implementation Cost of change to the scope

Cost of change RUP

Cost of change to the business solution There is a fair amount of flexibility in making this type of modification during the Inception phase, but costs escalate as you move into the Elaboration phase This is why you force an agreement on the vision for the system in Inception

Cost of change to the architecture You can make fairly significant architectural changes at low cost until the end of Elaboration After that, significant architectural changes become increasingly costly, which is why the architecture must be baselined at the end of Elaboration

Cost of change to the design and implementation Because of the component-based approach, these types of changes are typically localized and can hence be made at fairly low cost throughout the Construction phase These types of changes are, however, increasingly expensive in the Transition phase, which is why you typically introduce "feature freeze" at the end of Construction

Cost of change to the scope The cost of cutting scope—and hence postponing features to the next release—is relatively inexpensive throughout the project, if done within limits Scope cutting is greatly facilitated by iterative development; project managers should use it as a key tool to ensure on-time project delivery

Cost of change

Baseline an Executable Architecture Early On The architecture comprises the software system's most important building blocks and their interfaces, that is, the subsystem, the interfaces of the subsystems, and the most important components and their interfaces The architecture provides a skeleton structure of the system, comprising perhaps 10 to 20 percent of the final amount of code

Baseline an Executable Architecture Early On A strict layered architecture states that design elements (classes, components, packages, subsystems) only use the services of the layer below them.  Services can include event-handling, error-handling, database access, and so forth. It contains more palpable mechanisms, as opposed to raw operating system level calls documented in the bottom layer.

Build Your System with Components Functional Decomposition Architecture vs. Component-Based Architecture

Quality

Adopting the Rational Unified Process

The RUP—A Customizable Process Product Best practices The RUP comes with a library of best practices, produced by IBM Software and its partners These best practices are continually evolving and cover a broader scope than this book can cover The best practices are expressed in the form of phases, roles, activities, artifacts, and workflows

The RUP—A Customizable Process Product Process delivery tools The RUP is literally at the developers' fingertips because it is delivered online using Web technology, rather than using books or binders This delivery allows the process to be integrated with the many software development tools in the Rational Suite and with any other tools so developers can access process guidance within the tool they are using

The RUP—A Customizable Process Product Configuration tools The RUP's modular and electronic form allows it to be tailored and configured to suit the specific needs of a development organization

The RUP—A Customizable Process Product Process authoring tools Rational Process Workbench (RPW) is a process authoring tool, allowing you to capture your own best practices into the RUP format

The RUP—A Customizable Process Product Community/Marketplace The Rational Developer Network (RDN) online community allows users to exchange experiences with peers and experts, and provides access to the latest information in terms of artifacts, articles, or additional RUP content

“Right-size" the Process Right-sizing: Allow projects to "right-size" the process they use; that is, allow projects to use "just enough" process. Users should be able to start with a small process, and as project needs expand, to grow the process to address those needs. Process guidance: Make a wide array of process guidance available to users, including specific guidance on how to develop software for a variety of architectures, target devices, and hardware/software platforms.

Configuring the RUP Producing a RUP Process Configuration The RUP process framework contains a vast amount of guidance, artifacts, and roles. Because no project should use all of these artifacts, you need to specify a subset of the RUP to use for your project. This is done by selecting or producing a RUP Process Configuration, which constitutes a complete process from the perspective of a particular project's requirements. You can use one of the ready-made configurations as is or use a ready-made configuration as a starting point or create a process configuration from scratch.

Producing a RUP Process Configuration A RUP Process Component is a coherent, quasi-independent "chunk" or module of process knowledge that can be named, packaged, exchanged, and assembled with other process components. A RUP Library is a collection of Process Components out of which a set of RUP Process Configurations may be "compiled" with RUP Builder. New Process Components can be added to a RUP Library through the means of RUP Plug-Ins. A RUP Base is a collection of Process Components meant to be extended by applying plug-ins to generate RUP Process Configurations. It resides in a RUP Library. A RUP Plug-In is a deployable unit for one or several Process Components that can be readily "dropped" onto a RUP Base to extend it. A RUP Plug-In can be compiled into a single physical file (with extension ".cfu"), allowing it to be moved around and added to a RUP Library with a compatible RUP Base. To explain this via a simple analogy, a RUP Plug-In is a set of "precompiled" RUP Process Components, ready to be "linked" into a RUP Base to create one or more RUP Configurations.

MyRUP

Configurable RUP

Rational Process Workbench and Process Engineering Process You create RUP Plug-Ins by using Rational Process Workbench, a process authoring tool that consists of the following: RUP Modeler. This tool allows a process engineer to visually model process elements such as activities, artifacts, roles, disciplines, and tool mentors and their relationships, and to compile them into RUP Process Components. RUP Modeler is an add-in to Rational XDE and works in conjunction with RUP Organizer. RUP Organizer. This tool allows you to associate content files to process elements such as activities, artifacts, roles, disciplines, and tool mentors, all of which comprise a Process Component, and to compile these RUP Process Components and create a RUP Plug-In with the new or modified files. The files can be examples, guidelines, or reusable assets (among others). RUP Organizer also allows you to modify Extended Help. RUP Process Library. This contains process models with all the process elements such as roles, artifacts, activities, and tool mentors defined in the RUP as well as related content files for each model element. Process Engineering Process. This provides process guidance for customizing, implementing, and improving the process, as well as templates for content authoring, such as HTML templates for descriptions and guidelines, a template for producing plug-ins, and all graphics needed for process authoring.

Summary

Methods’ scopes

Project Management

Enterprise Unified Process

Teams Organized Around Architecture

When to Sign a Contract?

The Six UP Models (Views of the Application) Use-case model Test model Analysis model Implementation model Design model Deployment model