Rational Unified Process

1
Rational Unified Process
BCI3023 / BCI3063 CURRENT ISSUES IN ICT CHAPTER
1 ISSUES IN SOFTWARE DEVELOPMENT
2
Introduction

• The Unified Process was developed by Philippe
  Kruchten, Ivar Jacobson and others at Rational as
  the process complement to the UML.
• The Rational Unified Process (RUP) is a process
  product developed and marketed by Rational
  Software Corporation that provides the details
  required for executing projects using the UP,
  including guidelines, templates, and tool
  assistance essentially, it is a commercial
  process product providing the details or content
  for the UP framework.

3
Introduction

• provides a disciplined approach to assigning
  tasks and responsibilities within a development
  organization.
• Rational Unified Process is a guide for how to
  effectively use the Unified Modeling Language
  (UML)
• supported by tools, which automate large parts of
  the process. They are used to create and maintain
  the various artifacts-models in particular-of the
  software engineering process visual modeling,
  programming, testing, etc.

4
Introduction

• Goal To ensure the production of high-quality
  software that meets the needs of its end-users
  within predictable schedule and budget.
• Enhanced team productivity providing every
  team member with easy access to a knowledge base
  with guidelines, templates and tool mentors for
  all critical development activities.
• Activities create and maintain models
  emphasizes the development and maintenance of
  models.
• Captures many of the best practices in modern
  software development in a form that is suitable
  for a wide range of project and organizations

5
Introduction

• Language establishes the boundaries of thought
  and behavior, it defines concepts methodology
  and process establish behavior within that
  boundary, they apply concepts and tools
  establish the automation of behavior within that
  boundary, they automate the application of
  concepts.
• Quite simply, if we can't think it, we can't do
  it nor communicate it, and if we can't do it, we
  can't automate it! Within the information systems
  and technology industry, the Unified Process
  (UP), Rational Unified Process (RUP), Unified
  Modeling Language (UML), and Software Process
  Engineering Metamodel (SPEM) are at the heart of
  this evolution.

6
Unified Process

• The Unified Process (UP) is a use-case-driven,
  architecture-centric, iterative and incremental
  development process framework that leverages the
  Object Management Group's (OMG) UML and is
  compliant with the OMG's SPEM. The UP is broadly
  applicable to different types of software
  systems, including small-scale and large-scale
  projects having various degrees of managerial and
  technical complexity, across different
  application domains and organizational cultures.

7
Unified Process

• The UP is an "idea," a process framework that
  provides an infrastructure for executing projects
  but not all of the details required for executing
  projects essentially, it is a software
  development process framework, a lifecycle model
  involving context, collaborations, and
  interactions.

8
Rational Unified Process

• The UP emerged as the unification of Rational
  Software Corporation's Rational Approach and
  Objectory AB's Objectory process in 1995 when
  Rational Software Corporation acquired Objectory
  AB. Rational Software Corporation developed the
  Rational Approach as a result of various customer
  experiences, and Ivar Jacobson created the
  Objectory process primarily as a result of his
  experience with Ericsson in Sweden.

9
Rational Unified Process

• The Rational Unified Process (RUP) is a process
  product developed and marketed by Rational
  Software Corporation that provides the details
  required for executing projects using the UP,
  including guidelines, templates, and tool
  assistance essentially, it is a commercial
  process product providing the details or content
  for the UP framework.

10
Unified Modeling Language (UML)

• As the UML is an industry-standardized modeling
  language for communicating about systems,the
  Software Process Engineering Metamodel (SPEM) is
  an industry-standardized modeling language for
  communicating about processes and process
  frameworks (families of related processes) but it
  does not describe process enactment (the planning
  and execution of a process on a project).
• The SPEM began to emerge after the UML
  standardization effort, gained significant
  industry support from various organizations, and
  was adopted by the OMG as a standard (November
  2001).

11
System Development

• The system development lifecycle process involves
  a problem-solving process at a macro-level and
  the scientific method at a micro-level.
• Requirements may be characterized as problems.
• Systems that address requirements may be
  characterized as solutions.
• Problem solving involves understanding or
  conceptualizing the problem or requirements by
  representing and interpreting the problem,
  solving the problem by manipulating the
  representation of the problem to derive or
  specify a representation of the solution, and
  implementing or realizing and constructing the
  solution or system that addresses the
  requirements by mapping the representation of the
  solution onto the solution world.

12
System Development UML

• The UML facilitates and enables the
  problem-solving process. It facilitates
  specifying, visualizing, understanding, and
  documenting the problem or requirements
  capturing, communicating, and leveraging
  strategic, tactical, and operational knowledge in
  solving the problem and specifying, visualizing,
  constructing, and documenting the solution or
  system that satisfies the requirements. It
  enables capturing, communicating, and leveraging
  knowledge concerning systems using models,
  architectural views, and diagrams.

13
System Development System

• A system is a purposefully organized collection
  of elements or units. The architecture of a
  system entails two dimensions, the structural
  dimension and behavioral dimension, within its
  context.
• The structural or static dimension involves what
  elements constitute the system and their
  relationships.
• The behavioral or dynamic dimension involves how
  these elements collaborate and interact to
  satisfy the purpose of the system and provide its
  functionality or behavior.

14
Model

• A model is a complete abstraction of a system
  that captures knowledge (semantics) about a
  problem and solution.
• An architectural view is an abstraction of a
  model that organizes knowledge in accordance with
  guidelines expressing idioms of usage.
• A diagram is a graphical projection of sets of
  model elements that depicts knowledge (syntax)
  about problems and solutions for communication.
• Within the fundamental UML notation, concepts are
  depicted as symbols and relationships among
  concepts are depicted as paths (lines) connecting
  symbols.

15
Methodology Process Framework

• A program is a collection or portfolio of
  projects. A project is a specific problem-solving
  effort that formalizes the "work hard and hope
  for the best" approach.
• A method specifies or suggests how to conduct a
  project. A method's descriptive aspect specifies
  or suggests what knowledge is captured and
  communicated regarding a problem and solution.
• A method's prescriptive aspect specifies or
  suggests how knowledge is leveraged to solve the
  problem. A process is the execution of a method
  on a project.

16
Methodology

• A methodology is a discipline or taxonomy, or
  well-organized collection, of related methods
  that addresses who does what activities on what
  work products, including when, how, why, and
  where such activities should be done.
• Workers (who), activities (how), work products
  (what), and the heuristics concerning them are
  commonly known as process elements.
• Methodologies group methods as a family, methods
  describe processes, and processes execute methods
  on projects.

17
Process Framework

• A process framework specifies or suggests who
  does what activities on what work products,
  including when, how, why, and where such
  activities should be done for various types of
  projects.
• A process instance specifies or suggests who does
  what activities on what work products, including
  when, how, why, and where such activities should
  be done for a specific project.
• Process frameworks describe process instances as
  a more flexible and scaleable family of related
  processes, and process instances execute a subset
  of a process framework on projects.
• The UP is a process framework and Development
  Cases are process instances.

18
(No Transcript)
19
Collaboration

• A collaboration involves an interaction within a
  context.
• A collaboration captures who does what activities
  (how) on what work products. Thus, it establishes
  the elements of a project.
• A role is an individual or team who has
  responsibility for activities and artifacts.
• An activity is a unit of work, composed of steps,
  that is performed by a role.
• An artifact is an element of information that is
  the responsibility of a role and that is produced
  or consumed by activities.
• The UP defines numerous roles, artifacts, and
  activities.

20
Context

• A context emphasizes the structural or static
  aspect of a collaboration, the elements that
• collaborate and their conglomeration or spatial
  relationships.
• A context captures when and where such activities
  should be done and work products produced and
  consumed.
• Thus, it establishes the context for a project.
  Figure 2 shows the context established by the UP.

21
Iteration

• An iteration is planned, executed, and evaluated.
  Use cases and risks are prioritized, and use
  cases are ranked against the risks they mitigate.
  When planning an iteration, those use cases that
  address the highest risks and can be accommodated
  given the iteration's limiting factors (funding,
  time, resources, and so forth) are selected for
  driving the iteration. When executing an
  iteration, use cases evolve through the core
  disciplines and the system and its architecture
  evolve.

22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
Interaction

• An interaction emphasizes the behavioral or
  dynamic aspect of a collaboration, the elements
  that collaborate and their cooperation or
  temporal communication.
• An interaction captures when and why such
  activities should be done and work products
  produced and consumed.
• Thus, it establishes the execution of a project
  as it is governed by various forces.

27
System Architecture

• A system has an architecture. For example, the
  architecture of a system includes a collection of
  elements and how they collaborate and interact,
  including various subsystems for handling
  security, input and output, data storage,
  external communications, reporting, and so forth.
  
• As the UP is architecture-centric, iterations
  focus on architecture and evolving the system.
  That is, iterations demonstrate progress by
  evolving a puzzle of "chunks" such as to manage
  the complexity and integrity of the system. Thus,
  accounting for technical forces by demonstrating
  progress via the production and evolution of the
  real system.

28
UP Phases

• The Inception phase, concluding with the
  Objective milestone, focuses on establishing the
  project's scope and vision that is, establishing
  the business feasibility of the effort and
  stabilizing the objectives of the project.
• The Elaboration phase, concluding with the
  Architecture milestone, focuses on establishing
  the system's requirements and architecture that
  is, establishing the technical feasibility of the
  effort and stabilizing the architecture of the
  system.
• The Construction phase, concluding with the
  Initial Operational Capability milestone, focuses
  on completing construction or building of the
  system.
• The Transition phase, concluding with the Product
  Release milestone, focuses on completing
  transitioning or deployment of the system to the
  user community.

29
Supporting Discipline

• The Configuration Change Management discipline
  focuses on managing the configuration of the
  system and change requests.
• The Project Management discipline focuses on
  managing the project.
• The Environment discipline focuses on the
  environment for the project, including the
  process and tools.
• The UP defines the following six core
  disciplines
• The Business Modeling discipline focuses on
  understanding the business being automated by the
  system and capturing such knowledge in a Business
  model.
• The Requirements discipline focuses on
  understanding the requirements of the system that
  automates the business and capturing such
  knowledge in a Use-case model.

30
Supporting Discipline (cont)

• The Analysis Design discipline focuses on
  analyzing the requirements and designing the
  system and capturing such knowledge in an
  Analysis/Design model.
• The Implementation discipline focuses on
  implementing the system based on the
  Implementation model.
• The Test discipline focuses on testing
  (evaluating) the system against the requirements
  based on the Test model.
• The Deployment discipline focuses on deploying
  the system based on the Deployment model.

31
(No Transcript)
32
Rational Unified Process Tools
33

• supported by a vast palette of tools that
  automate steps in many activities
• The tools are used to
• a) create and maintain the various
  artifacts
• b) models in particular
• c) of the software engineering process,
  namely, visual modeling,
• programming, and testing

34
Tool mentor

• A step-by-step guide describing in detail how to
  operate a tool
• It is to carry out an activity within the process
  
• It allows us to link the tool-independent process
  to the actual manipulation of the tools in your
  daily work

35
Rational's tools

• Rational RequisitePro - Keeps the entire
  development team updated and on track throughout
  the application development process by making
  requirements easy to write, communicate and
  change.
• Rational ClearQuest - A Windows and Web-based
  change-request management product that enables
  project teams to track and manage all change
  activities that occur throughout the development
  lifecycle.

36

• Rational Rose 98 - The world's leading visual
  modeling tool for business process modeling,
  requirements analysis, and component architecture
  design.
• Rational SoDA - Automates the production of
  documentation for the entire software development
  process, dramatically reducing documentation time
  and costs.
• Rational Purify - A run-time error checking tool
  for application and component software developers
  programming in C/C helps detect memory errors.

37

• Rational Visual Quantify - An advanced
  performance profiling tool for application and
  component software developers programming in C,
  Visual Basic, and Java helps eliminate
  performance bottlenecks.
• Rational TeamTest - Creates, maintains and
  executes automated functional tests, allowing you
  to thoroughly test your code and determine if
  your software meets requirements and performs as
  expected.

38

• Rational Visual PureCoverage - Automatically
  pinpoints areas of code not exercised in testing
  so developers can thoroughly, efficiently and
  effectively test their applications.
• Rational PerformanceStudio - An easy-to-use,
  accurate and scalable tool that measures and
  predicts the performance of client/server and Web
  systems.
• Rational ClearCase - Market-leading software
  configuration management tool, giving project
  managers the power to track the evolution of
  every software development project.

39
Who Is Using the Rational Unified Process?

• Telecommunications Ericsson, Alcatel
• Transportation, aerospace, defense
  Lockheed-Martin, British Aerospace
• Manufacturing Xerox, Volvo, Intel
• Finances Visa, Merrill Lynch, Schwab
• System integrators CAP Gemini Ernst Young,
  Oracle, Deloitte Touche

40
(No Transcript)
41
Core Workflows
42
The Nine Core Process Workflow

• Business modeling workflow
• Requirements workflow
• Analysis Design workflow
• Implementation workflow
• Test workflow
• Deployment workflow

43
Three supporting workflows

• Project Management workflow
• Configuration and Change Management workflow
• Environment workflow

44
Business Modeling

• Common language and process
• Create and maintain direct trace ability between
  business and software models
• Business use cases
• Common understanding among all stakeholders

45
Requirements

• Goal-describe what the system should do and
  allows the developers and customer to agree on
  the description
• How?-elicit, organize, and document functionality
  and constraints, track and document tradeoffs and
  decisions

46
Analysis and Design

• Goal- show how the system will be realized in the
  implementation phase
• The design model acts as a blueprint of how the
  source code is structured and written

47
Implementation

• How you reuse existing components
• Implement new components
• Making the system easier to maintain
• Increasing the possibilities to reuse

48
Test

• Purpose
• -verify the interaction between objects
• -verify the proper integration of all components
  of the software
• -verify that all requirements have been
  correctly implemented
• -identify and ensure defects are addressed prior
  to the deployment of the software

49
DEPLOYMENT

• The purpose of deployment workflow is to
  successfully
• produce product releases, and deliver the
  software to its
• end users. It covers a wide range of activities
  including
• Producing external releases of the software
• Packaging the software
• Distributing the software
• Installing the software
• Providing help and assistance to the user

50

• In many cases, it also includes the activities
  such as
• Planning and conduct of beta test
• Migration of existing data or software
• Formal acceptance
• Although deployment activities are mostly
  centered around the transition phase, many of
• the activities need be included in earlier phases
  to prepare for deployment at the end of
• the construction phase. 
• The Deployment and Environment workflows of the
  Rational Unified Process contain less detail than
  
• other workflows.

51
PROJECT MANAGEMENT

• Software project management is the art of
  balancing competing objective, managing risk,
• and overcoming constraint to deliver,
  successfully, a product which meets the needs of
• both customers (payer of bills) and the users.
  The fact that so few projects are
• unarguably successful is comment enough on the
  difficulty of the task.
•  
• The workflow focuses mainly on the specific
  aspect of an iterative development process.
• The goal with this section is to make the task
  easier by providing
• A framework for managing software intensive
  projects
• Practical guidelines for planning, staffing,
  executing, and monitoring projects
• A framework for managing risk
• It is not a recipe for success, but it presents
  an approach to managing project that will be
  markedly improve the odds of delivering
  successful software.

52
CONFIGURATION AND CHANGE MANAGEMENT

• In this workflow it is describe how to control
  the numerous artifacts
• produced by the many people who work on a common
  project. Control
• helps avoid costly function, ensures that
  resultant artifacts are not in
• conflict due to some of the following kind of
  problems
•  
•     Simultaneous Update When two worker work
  separately on the same artifact, the last one to
  make changes destroys the work of the former.
•        Limited notifications When a problem is
  fixed in artifacts shared by several developers,
  and some of them are not notified of the change.
•      Multiple version Most large programs are
  developed in evolutionary releases. One release
  could be in customer use, while another is in
  test, and the third is still in development. If
  problems are found in any of the versions, fixes
  need to be propagated between them. Confusion can
  arise leading to costly fixes and re-work unless
  changes are carefully controlled and monitored.
•  

53

• This workflow provides guidelines for managing
  multiple variants of evolving software systems,
  tracking which version are used in given software
  builds, performing builds of individual programs
  or entire releases according to user-defined
  version specifications, and enforcing site
  specific development policies.
• It is also described here on how to manage
  parallel development, development done at
  multiple sites, and how to automate the build
  process. This is especially important in an
  iterative process where you may want to be able
  to do builds as often as daily, something that
  would become impossible without powerful
  automation. It is also described on how to keep
  an audit trail on why, and by whom the artifact
  was changed.
• This workflow covers the change request
  management, i.e. how to report defects, manage
  them through their lifecycle, and how to use
  defect data to track progress and trends.

54
ENVIRONMENT

• The purpose of the environment workflow is to
  provide the software development organization
  with the software development environment-both
  processes and tools-that are needed to support
  the development team.
• This workflow focuses on the activities to
  configure the process in the context of a
  project. It also focus on activities to develop
  the guidelines needed to support a project.
• A step-by-step procedure is provided describing
  how you implement a process in an organization.
•  
• The environment workflows also contain a
  Development Kit providing u with the guidelines,
  templates and tools necessary to customize the
  process.
• Certain aspects of the Environment workflows are
  not covered in the process such as selecting,
  acquiring and making the tools work, and
  maintaining the development environment.