Rational Unified Process

From StudyWiki

Contents 1 Overview 2 Phases and Iterations 2.1 Inception Phase 2.1.1 Milestone: Lifecycle Objectives 2.2 Elaboration Phase 2.2.1 Milestone: Lifecycle Architecture 2.3 Construction Phase 2.3.1 Milestone: Initial Operational Capability 2.4 Transition Phase 2.4.1 Milestone: Product Release 3 Static Structure of the Process 4 Core Workflows 4.1 Business Modelling 4.2 Requirements 4.3 Analysis & Design 4.4 Implementation 4.5 Test 4.6 Deployment 4.7 Project Management 4.8 Configuration Management 4.9 Environment 5 References

Overview

The Rational Unified Process (or RUP) is a software engineering process.

It aims to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.

Phases and Iterations

• organisation of the process along time
• the software lifecycle is broken into cycles
  • each cycle works on a new generation of the product
• 1 development cycle consists of 4 phases
  • Inception Phase
  • Elaboration Phase
  • Construction Phase
  • Transition Phase
• each phase has a specific purpose and concludes with a milestone
  • critical decisions are made
  • key goals must be achieved
• phases can be further broken down into iterations
  • an iteration is a complete development loop resulting in an executable product which grows incrementally from iteration to iteration to become the final product
• benefits of iterative approach
  • risks are mitigated earlier
  • change is more manageable
  • higher level of reuse
  • project team can learn along the way
  • better overall quality

Inception Phase

During this phase:

• establish business case for system:
  • establish success criteria
  • risk assessment
  • estimate of required resources
  • phase plan showing dates of milestones
• delimit project scope:
  • identify all external entities that the system will interact with (actors)
  • define high level nature of these interactions
    • identify all use cases
    • describe a few significant cases

Outcomes:

• vision document
  • general vision of the core project's requirements, key features, and main constraints
• initial use case model
  • (10% - 20% complete)
• initial project glossary
• initial business case
  • includes business context, success criteria, and financial forecast
• initial risk assessment
• project plan
  • showing phases and iterations
• one or several prototypes

Milestone: Lifecycle Objectives

evaluation criteria are:

• stakeholder concurrence on scope definition and cost/schedule estimates
• understanding of requirements
  • evidenced by accurate primary use cases
• credibility of cost/schedule estimates, priorities, risks, and development process
• depth and breadth of any architectural prototype (if developed)
• actual expenditures vs. planned expenditures

The project may be cancelled or re-thought if it fails this milestone.

Elaboration Phase

purpose is to

• analyse problem domain
• establish architectural foundation
• develop project plan
• eliminate highest risk elements of project

architectural decisions must be made with understanding of whole system:

• scope
• major functionality
• non-functional requirements
  • e.g. performance

At the end of this phase:

• most analysis and design is complete
  • decision is taken whether or not to proceed to construction
• transition from light, low-risk to high-cost, high-risk operation

elaboration phase ensures architecture, requirements, and plans are stable enough, and risks are mitigated, to enable accurate costing and scheduling for completion of project

During elaboration phase:

• architectural prototype is built
  • over 1 or more iterations
  • depending on scope, size, risk, and novelty of project
  • should cover key use cases identified in inception phase
    • exposes technical risks of project
  • goal is evolutionary prototype of production-quality component
    • doesn't exclude exploratory, throwaway prototypes to mitigate specific risks e.g. design/requirements trade-offs, component feasibility study, or demonstrations

Outcome of elaboration phase:

• use case model
  • at least 80% complete
  • all use cases and actors identified, most descriptions developed
• supplementary requirements capturing non-functional requirements and requirements not associated with a use case
• a software architecture description
• executable architectural prototype
• revised risk list and business case
• development plan for whole project
• updated development case specifying process to be used
• preliminary user manual (optional)

Milestone: Lifecycle Architecture

• examine detailed system objectives, scope, choice of architecture, and the resolution of major risks

main evaluation criteria for elaboration phase involves answers to these questions:

• is the vision of the product stable?
• is the architecture stable?
• does the executable demonstration show that the major risk elements have been addressed and credibly resolved?
• is the plan for the construction phase sufficiently detailed and accurate?
  • is it backed up with a credible basis of estimates
• do all stakeholders agree that the current vision can be achieved is the current plan is executed to develop the complete system, in the context of the current architecture?
• is the actual resource expenditure versus planned expenditure acceptable?

Construction Phase

During Construction phase:

• all remaining component and application features are developed and integrated into the product
• all features are thoroughly tested

• In 1 sense, it is a manufacturing process, rather than development
• some projects are large enough for parallel construction increments
  • this can accelerate development progress
  • can also increase complexity of resource management and workflow synchronisation

• construction phase ends with a product that users can use
• at a minimum it includes
  • software product integrated on the adequate platforms
  • user manuals
  • description of the current release

Milestone: Initial Operational Capability

• decide if the software, sites, and users are ready to go operational without high risks
  • this is often called a beta release

• evaluation criteria involve these questions:
  • is this product release stable and mature enough to be deployed in the user community?
  • are all stakeholders ready for the transition into the user community
  • are actual vs. planned expenditures still acceptable?

Transition may be postponed by 1 release if this milestone is failed

Transition Phase

• purpose is to release software product to user community
• once released
  • issues arise that require
    • new releases
    • correction of problems
    • completion of postponed features
• focusses on activities to place software in hands of users
• typically includes several iterations including
  • beta releases
  • general availability releases
  • bug-fix and enhancement releases

• major focus is on
  • developing user-orientated documentation
  • training users
  • supporting users in initial use
  • reacting to user feedback
    • user feedback should be confined to
      • product tuning
      • configuring
      • installation
      • usability

• Transition Phase is entered when the product is mature enough to be deployed in the end-user domain
• this requires
  • usable subset of systems functionality
  • acceptable level of quality
  • user documentation available

• Transition Phase includes
  • beta testing to validate system against user expectations
  • parallel operation with a legacy system that it is replacing
  • conversion of operational databases
  • training of users and maintainers
  • roll-out of product to marketing, distribution, and sales teams

• Primary Objectives
  • achieving user self-supportability
  • achieving stakeholder concurrence that deployment baselines are complete and consistent with evaluation criteria from vision
  • achieving final product baseline as rapidly and cost effectively as practical

Milestone: Product Release

at this point, decide:

• if objectives were met
• if another development cycle should be started

the primary evaluation criteria involve answering these questions:

• is the user satisfied?
• are actual resource expenditures vs. planned expenditures still acceptable?

Static Structure of the Process

A process describes who is doing what, how, and when. They are represented in the RUP using these terms:

• Workers (who)
• Activities (what)
• Artefacts (what)
• Workflows (when)

Worker

A role (behaviour and responsibilities) given to an individual or team.

In RUP, a worker is not the team or individual, but the role they perform (or "hat they wear" to use an common analogy). The responsibilities cover the performance of certain activities and ownership of certain artefacts.

Activity

Unit of work that is associated with a worker and can be assigned to an individual/team in that role.

Activities have clear purposes, and each is assigned to a specific worker.

It usually only involves one worker and affects a small number of artefacts.

The size (granularity) of an activity ranges from a few hours to a few days.

An activity should be usable as a planning element, so should not be too small or too large.

Examples of Activities:

• Plan an iteration (for Project Manager worker)
• Find use cases and actors (for System Analyst worker)
• Review the design (for Design Reviewer worker)

Artefact

A tangible piece of information that is produced, modified, or used by a process.

Artefacts are the inputs to or outputs of activities performed by workers.

Examples of Artefacts:

• Models, such as Use Case Models
• Elements within a model, such as a class
• Documents, such as Requirements specifications
• Source Code
• Executables

Workflow

Sequence of activities that produces a result of observable value.

Core Workflows

The RUP is divided into 6 core "engineering" workflows and 3 core "supporting" workflows

Engineering Workflows:

• Business Modelling
• Requirements
• Analysis & Design
• Implementation
• Test
• Deployment

Supporting Workflows:

• Project Management
• Configuration and Change Management
• Environment

Due to the iterative nature of the RUP, these workflows are not sequential, but present with various emphasis and intensity during each iteration.

Business Modelling

Business modelling seeks to bridge the gap between business engineers and software engineers. It aims to provide a common understanding and language between stakeholders of what business processes need to be supported.

Business use cases are used to document these processes.

Requirements

The goal of requirements engineering is to convert the client's needs into a something that can be designed, implemented, and delivered.

To achieve this, requirements are elicited, organised, and documented. Requirements describe required functionality and constraints, and track and document trade-offs and decisions.

Analysis & Design

Transforms requirements into designs that can be implemented.

Implementation

Produces actual working software according to the design.

Test

Testing aims to verify:

• interaction between objects
• proper integration of components of software
• all requirements have been correctly implemented

and to identify and ensure defects are dealt with.

Deployment

The purpose of deployment is to produce product releases and deliver software to end users

Project Management

Software project management is concerned with balancing competing objectives, managing risk, and overcoming constraints to deliver a product that meets customer and user needs.

Configuration Management

Configuration management provides guidelines for managing multiple variants of systems, tracking the versions used in different builds, parallel development, and change request management

Environment

The environment workflow is aims to provide the necessary processes and tools to support the development team.

References

Gornik, Davor. 2003: Rational Unified Process: Best Practices for Software Development Teams. IBM [1]