z
z
Software Engineering-II
z
Introduction
Bilawal HBK 16-ARID-06
Afrasiyab Haider 16-ARID-02
z
Rational Unified
Process
z
Agenda
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
z
Unified Process
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.
z
WHAT IS RUP?
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
z
History of RUP
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.
z
z
Iterative and Incremental
Development
z Incremental on the top and Iterative on the bottom :
z Incrementing development
 Iterating development
z
Advantages
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.
z
Building Blocks of
RUP
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.
z
Development Life
Cycle
z
1. Inception
2. Elaboration
3. Construction
4. Transition
Four Phases
z
Inception
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
z
Elaboration
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
z
Construction
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).
z
Transition
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.)
z
z
Disciplines of
RUP
z
1. Business Modeling
2. Requirements
3. Analysis and Design
4. Implementation
5. Test
6. Deployment
7. Change Management
8. Project Management
9. Environment
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
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.
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
z
The IBM
RMC
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.
z
Eclipse Process
Framework
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
z

RUP - Rational Unified Process

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 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.
  • 8.
    z  The UnifiedSoftware 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.
  • 10.
    z The best-knownand 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.
  • 12.
    z  This journeybegan 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.
  • 14.
  • 15.
    z Incremental onthe top and Iterative on the bottom :
  • 16.
    z Incrementing development Iterating development
  • 17.
  • 18.
    z  Allows forthe 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.
  • 20.
    z The main buildingblocks, 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.
  • 22.
    z 1. Inception 2. Elaboration 3.Construction 4. Transition Four Phases
  • 23.
  • 24.
    z Initial requirementscapture  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.
  • 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.
  • 28.
    z  Focus ison 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.
  • 30.
    z  The transitionphase 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.
  • 32.
  • 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.
  • 38.
    z  RMC standsfor 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.
  • 40.
    z  The EclipseProcess 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.