IBM Rational Unified Process For Software Engineering - Introduction

THE IBM
THE IBM
RATIONAL UNIFIED PROCESS
(RUP)
(RUP)

Table of Content
Table of Content
• Impetus For Change
• Definition
• Purpose
• Introduction
• History
• Strategic Tripod
• Key Principles
• Process Essentials
• Process Meta-Model
• RUP Best Practices
• Process Model Nomenclature
• Phase
Coverage
Coverage
IBM Rational Unified Process

Table of Content
Table of Content
• RUP Artifact
• Development Case
• Life Cycle Activity
• References
Coverage
Coverage

• Ad hoc Requirements
• Ambiguous Communication
• Brittle Architecture
• Overwhelming Complexity
• Inconsistencies in Requirement, Design & Implementation
• Insufficient testing
• Inaccurate assessment of Project status
• Failure to manage risks
• Uncontrolled change propagation
• Insufficient automation
Impetus For Change
Impetus For Change Theory
Theory

• IBM Rational Unified Process is a dynamic iterative and incremental
Software Engineering methodology.
Definition
Definition Concept
Concept

• A framework of Process(es) & Artifact(s) for Iterative Software
Development, intended to be tailored by software development
organization units or teams (s), that will select the elements of the
process appropriate for their needs.
Purpose
Purpose Theory
Theory

• Created by Rational Software Corporation, now a division of IBM
• An Iterative & Incremental Software Development Process
• Available as a Process Product
• An extensive refinement of a generic Unified Process
• An adaptable Process framework
Introduction
Introduction Theory
Theory

• Advantages
• Early Risk Mitigation
• Early Visible Progress
• Early User Feedback and Adaptation
• Managed Complexity
• Component Reuse
• Combination of Architecture Driven & Customer Centric Focus
• Visual specification for quick and better clarity
• Highly Customizable
Theory
Theory
Introduction
Introduction

• Disadvantages
• First Time Complexity To Implement
• Very Few Tools provide IBM RUP process template or compatibility
• Mainly useful for large evolving / generational software development
projects.
Theory
Theory
Introduction
Introduction

• 1967 Ericsson Approach
• Modelled A System As Traffic Cases
• Interconnected Blocks Realized The Cases
• Low Level Blocks Assembled Blocks Into Subsystems
• Design Resulted In Subsystem Interfaces
• Interconnectivity Between Blocks Through Interfaces
• Signals Passed Between Interconnected Blocks
• Software Architecture Description For Developers & Users
• Sequence / Collaboration Diagram For Case Realization
• Ivar Jacobson Worked For Ericsson
Theory
Theory
History
History

• 1976 CCITT Issuance Of Standard for Specification & Description
Language (SSDL)
• Modelled Functional Behaviour Of Telecom Systems
• Inherited Semantics From Ericsson Approach
• Blocks Owned Process Instances
• Process Instances Interacted Through Messages
• Recommended Diagrams Which Were Like UML Class & Activity
Theory
Theory
History
History

• 1987 Ivar Left Ericsson To Establish Objectory AB In Stockholm
• 1988 Ivar Jacobson Established Objectory
• Objectory Process Product
• Objectory Extended To Industries Outside Telecom
• Use Case Nomenclature
• Model Based Approach Across SDLC
• Introduced Traceability From Code To Requirements
• Finally Implemented As A Product
Theory
Theory
History
History

• 1994 James Joined Rational
• 1995 -1998 Rational Objectory
• Rational Software Corporation Acquired Objectory AB in 1995
• Rational Had Developed Practices Complementary To Objectory
• Objectory Process Product-Ver 3.8
• Added Abstraction, Information Hiding, Reusability & Prototyping
• Focus On Architecture & Iterative Development
• Philippe Kruchten of Rational Corp, authored papers on Architecture
• Architecture View
• Grady Booch & Jacobson Specifications
Theory
Theory
History
History

• 1995 -1998 Rational Objectory
• James Rumbaugh Was Principle Developer At GE R&D of OMT
• October 1995, UML Ver 0.8 Was Released (Booch & James)
• 1996, UML Ver 0.9 Was Released (Booch, James & Ivar)
• Motive to unify knowledge from OMT, Booch &
• Philippe was given the project to define & specify Rational Uniifed
Process.
• Consortium of companies (HP, IBM, MS etc.) contributed to UML
• Year End 1997, OMG Standardised Ver 1.1
• UML 1.1 Was Used In Objectory
Theory
Theory
History
History

• 1995 - 1998 Rational Objectory
• Rational Acquired / Merged With other Software Tool Co's
• Requirements Management by Requisite Inc.
• Test Process by SQA Inc.
• Business Modeling Discipline was added
• Configuration Management by Pure-Atria
• Performance Testing by Performance Awareness
• Data Engineering by Vigortech
• Update to reflect changes in UML 1.1
• Key Principles Defined
• In 1998, Rational Objectory Process Standardised
Theory
Theory
History
History

• 1999 - 2003
• A Project Management discipline was introduced
• Updates to reflect UML 1.3
• The first book to describe the process, The Unified Software Development
Process was published.
• Introduction of concepts and techniques from approaches such as eXtreme
Programming (XP), that would later come to be known collectively as agile
methods.
• Included techniques such as pair programming, test-first design, and papers
that explained how RUP enabled XP to scale for use on larger projects.
Theory
Theory
History
History

• 1999 - 2003
• Completely new testing discipline to better reflect how testing work was
conducted in different iterative development contexts.
• Introduction of supporting guidance known as "tool mentors“, for enabling
the RUP practices in various tools.
• Automating the customization of RUP to allow customers to select parts
from the RUP process framework.
Theory
Theory
History
History

• 2003 onwards
• IBM acquired Rational Software
• In 2006, IBM created a subset of RUP tailored for the delivery of Agile
projects, released as an OpenSource method called OpenUP through the
Eclipse web-site.
• The IBM Rational Method Composer product is a tool for authoring,
configuring, viewing, and publishing processes.
• An open source version Eclipse Process Framework (EPF) project also
defined.
Theory
Theory
History
History

• A tailorable process guide for software engineering & management
• A standard notation to communicate lifecycle artifacts across and
between team members.
• Tools to automate the engineering & management process
Tripod Of Success
Tripod Of Success Theory
Theory

• Adapt the Process
• Balance Competing Stakeholder Priorities
• Collaborate Across Teams
• Demonstrate Value Iteratively
• Elevate Level of Abstraction
• Focus Continuously On Quality
Key Principles
Key Principles Theory
Theory

• Adapt the Process
Theory
Theory
Key Principles
Key Principles

• Balance Competing Stakeholder Priorities
• Asset reuse & Stakeholder needs for Custom Development or New
Development.
Theory
Theory
Key Principles
Key Principles

• Demonstrate Value Iteratively
Theory
Theory
Key Principles
Key Principles

• Elevate Level of Abstraction
• Reduce complexity by raising the level of Abstraction by re-using Assets
Theory
Theory
Key Principles
Key Principles

• Focus Continuously On Quality
• Testing Is Initiated Early and Expanded Upon in Each Iteration
Theory
Theory
Key Principles
Key Principles

• Develop a Vision
• Manage to the Plan
• Mitigate Risks and Track Related Issues
• Examine the Business Case
• Design a Component Architecture
• Incrementally Build and Test the Product
• Regularly Assess Results
• Manage and Control Changes
• Deploy a Usable Product
• Adopt a Process that Fits Your Project
Theory
Theory
Process Essentials
Process Essentials

• Develop a Vision
• Captures High-level Requirements and Design Constraints, to provide an
understanding of the System to be developed.
• Provides input to the Project-approval process, and is intimately related
to the Business Case.
• Communicates the fundamental “Why and What related to the Project
and is a gauge against which all future decisions should be validated.
Theory
Theory
Process Essentials
Process Essentials

• Manage To The Plan
• The Product is only as good as the Plan for the Product
• A Software Development Plan
• Gathers information required to Manage the Project
• Is used to plan the Project Schedule and Resource Needs and track progress
against the Schedule.
• Addresses areas as Project Organization, Schedule, Budget and Resources
• May include Plans for Requirements Management, Configuration
Management, Problem Resolution, Quality Assurance, Evaluation & Test and
Product Acceptance.
Theory
Theory
Process Essentials
Process Essentials

• Mitigate Risks and Track Related Issues
• Identify and attack the highest Risk items early in the Project and track
them, along with other related issues.
• The Risk List is intended to capture the perceived risks to the success of
the Project.
• It identifies, in decreasing order of priority, the Events which could lead to a
significant negative outcome.
• Along with each Risk, should be a plan for mitigating that Risk
• This serves as a focal point for planning Project activities, and is the basis
around which iterations are organized.
Theory
Theory
Process Essentials
Process Essentials

• Examine the Business Case
• Provides necessary information from a business standpoint, to determine
whether or not the Project is worth investing in.
• To develop an Economic plan for realizing the Project Vision
• Used to make an accurate assessment of the return on investment (ROI)
provided by the project.
• The description should not delve deeply into the specifics of the problem,
but rather it should create a compelling argument why the Product is
needed.
Theory
Theory
Process Essentials
Process Essentials

• Define an Architectural representation, for describing important aspects
of an Architecture in multiple Views/Ways.
• A View addresses some specific set of concerns, specific to
Stakeholders in the Engineering Process.
• User, Designer, Manager, System Engineers, Maintainers, and so on
• Serves as a communication medium between the Software Architect and
other Project Team Members regarding Architecturally significant decisions
which have been made on the Project.
Theory
Theory
Process Essentials
Process Essentials

• Philippe Kruchten 4+1 Views
Theory
Theory
Process Essentials
Process Essentials

Theory
Theory
Process Essentials
Process Essentials
Diagram Source : IBM

• Extends to a Data View or 4+1+1 View
• Data View represents Data Modelling & Information Engineering
Theory
Theory
Process Essentials
Process Essentials

Process Meta-Model
Process Meta-Model Theory
Theory

Theory
Theory
Process Meta-Model
Process Meta-Model

RUP Best Practices
RUP Best Practices Theory
Theory

• Develop Software Iteratively
• Manage Requirements
• Use Component Based Architecture
• Visually Model Software
• Continuously Verify Software Quality
• Control Changes
Theory
Theory
RUP Best Practices
RUP Best Practices

• Develop Software Iteratively
• Work close to the Customer in each iteration
• Impossible to develop Systems in a single step
• Objective learning for improvement
• Successful refinement in order of risk prioritization
• Integration & testing of integrated parts is in small manageable steps
• Software Architecture improves continuously
• Single Phase Plan with multiple Iteration plans
• Time Boxing with short iterations
Theory
Theory
RUP Best Practices
RUP Best Practices

• Manage Requirements
• Measured problem analysis
• Understanding Stakeholder needs
• Defining the System
• Managing scope of the System
• Refine the System definition
• Manage changing requirements
Theory
Theory
RUP Best Practices
RUP Best Practices

• Use Component Based Architecture
• Architecture In Early Iteration
• Representation of Software System, Processes and Discipline for
implementing the design for such a System.
• Conveys the Information content of the Elements comprising the System
• This Architecture then becomes a prototype in the initial development cycle
• The Architecture evolves with each iteration to become the final System
Architecture.
• By developing iteratively it is possible to gradually identify Components
which can then be developed, bought or reused.
Theory
Theory
RUP Best Practices
RUP Best Practices

• Visually Model Software
• A picture speaks louder than a million words
• Abstracting programming from its code and representing it using
graphical building blocks to get an overall picture of a Solution.
• Technical resources can determine how best to implement a given set of
inter-related logic.
• Builds an intermediary between the Business Process and actual code
Theory
Theory
RUP Best Practices
RUP Best Practices

• Of Product, Process, Project & Resources
• Assists in quality control and assessment by building it into the entire
Process and involving all members of the Team.
• Each member of the Team is responsible for quality during the entire
Process.
• The Process focuses on meeting the expected level of quality and
provides test workflows to measure this level.
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Document
• Page Size
• Staff Time Units For Production, Change & Repair
• Number of Changes, Defects, Opened, Closed
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Models - Requirements
• Number of requirements & Use Cases/Packages
• Number of Use Case scenarios & Actors
• Use Cases Completed / Identified
• Staff-time Units
• No of Defects and change requests, opened/closed
• Use Case Scenarios Realized in Analysis Model / Total Scenarios
• Use Case Scenarios Realized in Design Model / Total Scenarios
• Use Case Scenarios Realized in Implementation Model / Total Scenarios
• Use Case Scenarios Realized in Test Model / Total Scenarios
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Models – Analysis & Design
• Number of Classes, Subsystems, Packages, Methods & Attributes per Class
• Depth of Inheritance Tree & No of Children
• Staff Time Units
• Number of Defects, change requests (opened/closed)
• Response For a Class
• Class Fan-in / Fan-out (Degree of Coupling)
• Number of Classes Completed / Number of Classes Identified
• Analysis Traceability
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Models – Implementation
• Number of Files
• Cyclomatic Complexity of Methods
• Message Passing Coupling
• Lack Of Cohesion in Methods (Henderson-Sellers)
• Implementation and Test Traceability
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Models – Test
• Number of Test Cases, Test Procedures, Test Scripts
• Staff Time Units
• Number of Defects, change requests (opened/closed)
• Number of Test Cases written / number of Test Cases estimated
• Test Traceability
Theory
Theory
RUP Best Practices
RUP Best Practices

• Product Metrics
• Models – Project Management
• Budgeted Cost for Work Scheduled
• Budgeted Cost for Work Performed
• Actual Cost for Work Performed
• Budget At Completion
• Estimate At Completion
• Contract Budget Base
• Latest Revised Estimate
Theory
Theory
RUP Best Practices
RUP Best Practices

• Control Changes to Software
• Change is inevitable
• Methods to control, track and monitor changes
• Also defines secure workspaces, guaranteeing a Software engineer's
System will not be affected by changes in another System.
Theory
Theory
RUP Best Practices
RUP Best Practices

• Phase
• Life Cycle Activity
• Milestone
• Artifact
Process Model Nomenclature
Process Model Nomenclature Theory
Theory

• A well define sequential stage, consisting of increments of SDLC
Phase
Phase Concept
Concept

• 4 Phases
• Each Phase consisting Single Or Multiple SDLC Iterations
Within a Phase.
• Each SDLC could follow any Process Model
• Single Phase Plan & Multiple Iteration Plans
Phase
Phase Theory
Theory

• Phase & Iteration Model
Phase
Phase Theory
Theory

• Milestones
• Inception (Life Cycle Objectives)
• Elaboration (Life Cycle Architecture)
• Construction (Initial Operational Capability)
• Transition (Product Release)
hase
hase Theory
Theory

• Identify phases and milestones for the software engineering process
that you will utilize for mySHOP.
hase
hase To-Do
To-Do

• They can be any one of the following
• A Document, such as Business Case or Software Architecture
Document.
• A Model, such as the Use-Case Model or the Design Model
• A Model Element, i.e. an Element within a model, such as a Class, or a
Subsystem.
• Code file such as Programs, Scripts etc
RUP Artifact
RUP Artifact Theory
Theory

• Associations
Theory
Theory
RUP Artifact
RUP Artifact

• Identify a few artifacts for the software engineering process that you
will utilize for mySHOP.
To-Do
To-Do
RUP Artifact
RUP Artifact

• The first Artifact in a Software Engineering Project
• Defines the choice of Artifacts that will be delivered in an iterative
manner across the Project lifecycle.
Concept
Concept
Development Case
Development Case

• Define an initial Development Case for the software engineering
process that you will utilize for mySHOP.
Development Case
Development Case To-Do
To-Do

• A specific stage of the SDLC with clearly defined ETVX
Life Cycle Activity Concept
Concept

• Project Management
• Environment
• Business Modelling
• Requirements
• Analysis & Design
• Coding
• Testing
• Deployment
Life Cycle Activity Theory
Theory

• Development Case
• myABC_WORK_ARTIFACT_CONTENT_MAP_MAIN_v1.0
References Theory
Theory

THE IBM
THE IBM
(RUP)
(RUP)
-
-
END
END

IBM Rational Unified Process For Software Engineering - Introduction

More Related Content

Similar to IBM Rational Unified Process For Software Engineering - Introduction

Recently uploaded

IBM Rational Unified Process For Software Engineering - Introduction