1.
z

2.
z
Software Engineering-II

3.
z
Introduction
Bilawal HBK 16-ARID-06
Afrasiyab Haider 16-ARID-02

4.
z
Rational Unified
Process

5.
z
Agenda

6.
z
 Unified Process
 What is RUP?
 History of RUP
 Iterative and Incremental
Development
 Advantages of RUP.
 Building blocks of RUP.
 Development Life Cycle.
 Disciplines of RUP
 The IBM RMC.
 Eclipse Process Framework

7.
z
Unified Process

8.
z
 The Unified Software Development Process or Unified
Process is a popular iterative and incremental software
development process framework.
 Framework:
Framework is a real or conceptual structure
intended to serve as a support or guide for the
building of something that expands the structure
into something useful.

9.
z
WHAT IS RUP?

10.
z The best-known and extensively documented refinement of the Unified
Process is the Rational Unified Process (RUP).
 RUP is a method of managing OO Software Development
 It can be viewed as a Software Development Framework which is
extensible and features:
 Iterative Development
 Requirements Management
 Component-Based Architectural Vision
 Visual Modeling of Systems
 Quality Management
 Change Control Management

11.
z
History of RUP

12.
z
 This journey began with the creation of the Rational
Objectory Process (ROP) in 1996, when Rational
acquired the Objectory Process that had been
written by Ivar Jacobson and company in
collaboration with IBM. This was renamed Rational
Unified Process (RUP) in subsequent releases, in
part to align the name with that of the Unified
Modeling Language.

13.
z

14.
z
Iterative and Incremental
Development

15.
z Incremental on the top and Iterative on the bottom :

16.
z Incrementing development
 Iterating development

17.
z
Advantages

18.
z
 Allows for the adaptive capability to deal with changing
requirements throughout the development life cycle, whether they
be from customers or from within the project itself.
 Emphasizes the need (and proper implementation of) accurate
documentation.
 Diffuses potential integration headaches by forcing integration to
occur throughout development, specifically within the construction
phase where all other coding and development is taking place.

19.
z
Building Blocks of
RUP

20.
z
The main building blocks, or content elements, are the following:
 Roles (who) – A role defines a set of related skills, competencies
and responsibilities.
 Tasks (how) – A task describes a unit of work assigned to a Role
that provides a meaningful result.
 Work products (what) – A work product represents something
resulting from a task, including all the documents and models
produced while working through the process.

21.
z
Development Life
Cycle

22.
z
1. Inception
2. Elaboration
3. Construction
4. Transition
Four Phases

23.
z
Inception

24.
z 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

25.
z
Elaboration

26.
z
 Requirements Analysis
 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)
 Risk Assessment
 Architecture Document

27.
z
Construction

28.
z
 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 (prioritize).

29.
z
Transition

30.
z
 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.)

31.
z

32.
z
Disciplines of
RUP

33.
z
1. Business Modeling
2. Requirements
3. Analysis and Design
4. Implementation
5. Test
6. Deployment
7. Change Management
8. Project Management
9. Environment

34.
z
 Business Modeling:
 Understand organization and its structure in which system is to be deployed.
 Drive system requirements and achieving common understandings of system.
 Requirements Management:
 Capture and manage requirements
 Design a user friendly interface
 Define boundaries of system
 Estimates cost and time to develop product
 Analysis and design:
 Translate requirements into a visualize form
 Fulfils user’s all requirements

35.
z Implementation:
 Create, assemble, and integrate components and subsystem into an executable
system.
 Test:
 Test the developed components as a unit.
 Verify the interactions between objects.
 Verify that all the requirements have been correctly implemented.
 Deployment:
 Hand over the product to its users.

36.
z
 Change Management:
 Assess Product quality
 Simultaneous update
 Multiple versions
 Project Management:
 Plan an iterative process.
 Decide duration and content of an iteration
 Provides a framework for managing risks.
 Environment:
 Turn the finished software product over to its users
 Process improvement

37.
z
The IBM
RMC

38.
z
 RMC stands for Rational Method Composer
 The IBM Rational Method Composer product is a tool for authoring, configuring,
viewing, and publishing processes.
 It tells that which process model is suitable for the project.
 IBM Rational Method Composer is a flexible process management platform with a
method authoring tool and a process asset library to help you implement measured
improvement of your enterprise, systems engineering, or software delivery
processes. Rational Method Composer tooling lets you create, edit, manage, and
publish process descriptions. The process and practice libraries provide best practice
content that you can reuse as is or that you can tailor to compose your own
processes.

39.
z
Eclipse Process
Framework

40.
z
 The Eclipse Process Framework (EPF) is an open source project that is
managed by the Eclipse Foundation. It lies under the top-level Eclipse
Technology Project. It has two goals:
 To provide an extensible framework and exemplary tools for software
process engineering - method and process authoring, library
management, configuring and publishing a process.
 To provide exemplary and extensible process content for a range of
software development and management processes supporting iterative,
agile, and incremental development, and applicable to a broad set of
development platforms and applications

41.
z