Rational Unified Process

1
Rational Unified Process

• Group 8
• ??? ??? ???

2
Unified Process
3
Unified Process

• Unified Software Development Process
• A popular iterative and incremental software
  development process framework
• The best-known and extensively documented
  refinement of the Unified Process is the Rational
  Unified Process or RUP
• The Unified Process is not simply a process, but
  rather an extensible framework which should be
  customized for specific organizations or projects

4
Iterative Development
5
Refinements and Variations

• Agile Unified Process (AUP)
• Basic Unified Process (BUP)
• Enterprise Unified Process (EUP)
• Essential Unified Process (EssUP)
• Open Unified Process (OpenUP)
• Rational Unified Process (RUP)
• Oracle Unified Method (OUM)
• Rational Unified Process-System Engineering
  (RUP-SE)

6
Rational Unified Process
7
Introduction

• Software engineering process
• An iterative software development process
  framework
• Adaptable process framework
• Also a software process product

8
History

• Rational software Corporation
• Sold to IBM
• Spiral model

9
History

• Objectory Process 3.8
• Rational Objectory Process 4.0
• Rational Objectory Process 4.1
• Rational Unified Process 5.0

Rational Objectory Process 4.1
Rational Approach
Rational Objectory Process 4.0
Rational unified process 5.0
Objectory Process 3.8
10
Symptoms of Software Development Problem

• Inaccurate understanding of end-user needs
• Inability to deal with changing requirements
• Modules that dont fit together
• Software thats hard to maintain or extend
• Late discovery of serious project flaws
• Poor software quality
• Unacceptable software performance

11
Root Cause of Software Development Problem

• Ad hoc requirements management
• Ambiguous and imprecise communication
• Brittle architecture (architecture that does not
  work properly under "stress")
• Overwhelming complexity
• Undetected inconsistencies in requirements,
  designs, and implementations
• Insufficient testing
• Subjective project status assessment
• Failure to attack risks
• Uncontrolled change propagation
• Insufficient automation

12
Software Best Practices

• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software

13
Iterative Development

• Take into account changing requirements
• Elements are integrated progressively
• Can make tactical change to the product
• Easy to reuse
• Result in robust architecture
• Developers abilities and specialties are more
  fully employed during the entire life cycle

14
Requirement Management

• Better control of complex projects
• Improved software quality and customer
  satisfaction
• Reduced project costs and delays
• Improved team communication

15
Architecture and Use of Components

• Decide which ones to develop, which ones to
  reuse, and which ones to buy
• Concept of packages, subsystems, and layers can
  be used to organize components
• Testing from single component to a large sets of
  integrated components

16
Modeling and the UML

• Understand and shape both the problem and solution

17
Quality of Process and Product

• Product quality
• Process quality
• RUP focuses on verifying and objectively
  assessing whether or not the product meets the
  expected level of quality

18
Configuration and Change Management

• Keep track of changes and ensure everything and
  everyone is in sync
• Change management is tied to configuration
  management and to measurement

19
Other Key Features of RUP

• Use-case-driven development
• Process configuration
• Tools support

20
Six Key Principles of Business-Driven Development
ABCDEF

• Adapt the process
• Balance stakeholder priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

21
Project Lifecycle

• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

22
Disciplines and Workflows
23
Core Process Workflows

• Business modeling
• Requirements
• Analysis and design
• Implementation
• Test
• Deployment

24
Core Supporting Workflows

• Project management
• Configuration and change management
• Environment

25
RUP Main Building Blocks

• Roles (who)
• Work Products (what)
• Tasks (how)

26
Business Modeling Discipline

• The aim of business modeling is to first
  establish a better understanding and
  communication channel between business
  engineering and software engineering
• Understanding the business means that software
  engineers must understand the structure and the
  dynamics of the target organization (the client),
  the current problems in the organization and
  possible improvements
• They must also ensure a common understanding of
  the target organization between customers, end
  users and developers.
• Business modeling explains how to describe a
  vision of the organization in which the system
  will be deployed and how to then use this vision
  as a basis to outline the process, roles and
  responsibilities

27
Requirements Discipline

• The goal of the requirements discipline is to
  describe what the system should do and allows the
  developers and the customer to agree on that
  description. To achieve this, analysts elicit,
  organize, and document required functionality

28
Analysis and Design Discipline

• The goal of analysis and design is to show how
  the system will be realized in the implementation
  phase
• Performsin a specific implementation
  environmentthe tasks and functions specified in
  the use-case descriptions
• Fulfills all its requirements
• Is easy to change when functional requirements
  change

29
Implementation Discipline

• To define the organization of the code, in terms
  of implementation subsystems organized in layers
• To implement classes and objects in terms of
  components (source files, binaries, executables,
  and others)
• To test the developed components as units
• To integrate the results produced by individual
  implementers (or teams), into an executable system

30
Test Discipline

• To verify the interaction between objects
• To verify the proper integration of all
  components of the software
• To verify that all requirements have been
  correctly implemented
• To identify and ensure that defects are addressed
  prior to the deployment of the software
• Ensure that all the defects are fixed, retested
  and closed

31
Deployment Discipline

• Producing external releases of the software
• Packaging the software and business application
• Distributing the software
• Installing the software
• Providing help and assistance to users

32
Configuration and Change Management Discipline

• Configuration management
• Change request management
• Status and measurement management

33
Project Management Discipline

• Phase plan
• Iteration plan
• Work Product (Artifact)

34
Environment Discipline

• Prepare Environment for Project
• Prepare Environment for an Iteration
• Support Environment During an Iteration

35
Summary

• RUP is a software development process covering
  the entire software development life cycle
• RUP is a process product that brings a wealth of
  knowledge, always up-to-date, to the developers
  workstation
• RUP embeds guidance on many modern techniques and
  approaches
• RUP is not a frozen product rather, it is alive,
  constantly maintained, and continuously evolving
• RUP is based on solid process architecture, and
  that allows a development organization to
  configure and tailor it to suit its needs

36
End of Presentation

• Thanks for listening