rup

Rational Unified Process : 

Rational Unified Process (RUP)

INTRODUCTION : 

INTRODUCTION The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

RUP : 

RUP The Rational Unified Process (RUP) is a software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.

7 BEST PRACTICES : 

7 BEST PRACTICES By 1997, Rational combined the experience base of these companies led to the articulation of seven best practices for modern software engineering: Develop iteratively, with risk as the primary iteration driver Manage requirements Employ a component-based architecture Model software visually Continuously verify quality Control changes Customization

RUP building blocks : 

RUP building blocks RUP is based on a set of building blocks, or content elements, describing what are to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. The main building blocks, or content elements, are the following: Roles (who) – A Role defines a set of related skills, competencies, and responsibilities. Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process. Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Four Project Lifecycle Phases : 

Four Project Lifecycle Phases The RUP has determined a project lifecycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished.

Inception Phase : 

Inception Phase In this ,the project is checked against the following criteria: Stakeholder concurrence on scope definition and cost/schedule estimates. Requirements understanding as evidenced by the fidelity of the primary use cases. Credibility of the cost/schedule estimates, priorities, risks, and development process. If the project does not pass this milestone, called the Lifecycle Objective Milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration Phase : 

Elaboration Phase This phase must pass the Lifecycle Architecture Milestone by meeting the following deliverables: A description of the software architecture in a software system development process. An executable architecture that realizes architecturally significant use cases. Business case and risk list which are revised. A development plan for the overall project. Prototypes that demonstrably identified technical risk.

Construction Phase : 

Construction Phase The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system.

Transition Phase : 

Transition Phase The primary objective is to 'transition' the system from development into production, making it available to and understood by the end user.

Slide 11: 

Six Engineering Disciplines

Business Modeling Discipline : 

Business Modeling Discipline 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.

Requirements Discipline : 

Requirements Discipline Requirements explain how to elicit stakeholder requests and transform them into a set of requirements work products that scope the system to be built and provide detailed requirements for what the system must do.

Analysis and Design Discipline : 

Analysis and Design Discipline The goal of analysis and design is to show how the system will be realized. The aim is to build a system that: Performs — in a specific implementation environment — the tasks and functions specified in the use-case descriptions. Fulfills all its requirements. Is easy to change when functional requirements change.

Implementation Discipline : 

Implementation Discipline The purposes of implementation are: To define the organization of the code in terms of implementation subsystems that are 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.

Test Discipline : 

Test Discipline The purposes of test are: 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.

Deployment Discipline : 

Deployment Discipline The purpose of deployment is to successfully produce product releases, and to deliver the software to its end users. It covers a wide range of activities including producing external releases of the software, packaging the software and business application, distributing the software, installing the software, and providing help and assistance to users.

Slide 18: 

Three supporting disciplines

Environment discipline : 

Environment discipline The environment discipline focuses on the activities necessary to configure the process for a project.

Configuration and Change management discipline : 

Configuration and Change management discipline The Change Management discipline in RUP deals with three specific areas: configuration management, change request management, and Status and measurement management.

Project management discipline : 

Project management discipline The project management discipline contains a number of other Plans and Artifacts that are used to control the project and monitoring its performance. Such Plans are: The Phase Plan (The Software Development Plan) The Iteration Plan

Slide 22: 

Project Management Disciplines

Phase plan : 

Phase plan Each Phase is treated as a project, controlled and measured by the Software Development Plan, it includes: Measurement Plan Risk Management Plan Risk list Problem Resolution Plan Product Acceptance Plan

Iteration plan : 

Iteration plan The iteration plan is a fine-grained plan with a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration. There are typically two iteration plans active at any point in time: current iteration plan used to track progress in the current iteration next iteration plan used to plan the upcoming iteration

Slide 25: 

THANKYOU !!!