RUP - Rational Unified Process

Rational Unified Process, It is an software development approach which uses rational objectory model to develop a software on predefined principlas

1. Software Engineering-II

2. Introduction Bilawal HBK 16-ARID-06 Afrasiyab H aider 16-ARID-02

3. Rational Unified Process

4. Agenda

5. 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

6. Unified Process

7. 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.

8. WHAT IS RUP?

9. 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

10. History of RUP

11. 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 .

12. Iterative and Incremental Development

13. Incremental on the top and Iterative on the bottom :

14. Incrementing development Iterating development

15. Advantages

16. 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.

17. Building Blocks of RUP

18. 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.

19. Development Life Cycle

20. Inception Elaboration Construction Transition Four Phases

21. Inception

22. 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

23. Elaboration

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

25. Construction

26. 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).

27. Transition

28. 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.)

29. Disciplines of RUP

30. Business Modeling Requirements Analysis and Design Implementation Test Deployment Change Management Project Management Environment

31. 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

32. 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.

33. 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

34. The IBM RMC

35. 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.

36. Eclipse Process Framework

37. 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