rational unified process fundamentals module 3: disciplines i

Rational Unified Process Fundamentals

Module 3: Disciplines I

Rational Unified Process Fundamentals

Module 3: Disciplines I

Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 2

Objectives

Understand how models result from Disciplines

Understand discipline concepts for: Business Modeling Environment Project Management Requirements


Disciplines


Discipline: Environment

Purpose: Support the development organization, both with process and tools Process configuration

• Adapt RUP to organization Process implementation

• Train and mentor RUP users Process improvement Managing organizational change Development environment

• Tool selection and acquisition• Tool instillation and configuration


Discipline: Environment

The primary roll in the Environment Discipline is the Process Engineer.

The primary artifact produced by the Process Engineer is the Development Case.

The Development Case describes, for each process discipline, how the project will apply the process.


Development Case

Describes the development process that you have chosen to follow in your project

Contained in Environment discipline Created early in Inception Updated during project

Development Case

Select from RUP knowledge base

Minimize cost of process definition


Development Case ExampleBrief Outline: 1. Introduction: Purpose,

Scope, Definitions, References, Overview

2. Overview of the Development Case: Lifecycle Model, Discipline Configuration, Artifact Classification, Review Procedures, Sample Iteration Plans

3. Disciplines: Describes artifacts used for each discipline

4. Roles: Describes any changes in Role Sets

Example below shows Requirements artifacts to be used as defined in the Development Case


Discipline: Project Management

Purpose: Provide a framework for managing software-

intensive projects Provide practical guidelines for planning,

staffing, executing, and monitoring projects Provide a framework for managing risk



Questions that must be addressed by the project manager: How many iterations are needed? How long should each iteration be? How are the contents and objectives of an

iteration determined? How is the progress of an iteration tracked?



Project planning takes place at two levels1. Phase Plan Level

• Dates of major milestones: end of each phase and its objectives

• Staffing profiles: which resources are required over time.

• Dates of minor milestones: end of each iteration and its objectives

2. Iteration Plan Level Current iteration plan Next iteration plan (built toward end of current

iteration)


Coarse-Grained and Fine-Grained Planning

Single coarse-grained plan (the phase plan)Single coarse-grained plan (the phase plan)

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration

Architect.Architect.IterationIteration

Devel. Devel. IterationIteration



TransitionTransitionIterationIteration

TransitionTransitionIterationIteration

Series of fine-grained plans (the iteration plans)Series of fine-grained plans (the iteration plans)

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition


#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter. No.

Prel.Iteration

Elabo-ration Construction TransitionInception

Incremental (1)

#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter.No.

Prel.Iteration

Elaboration

Cons-truc-tion TransitionInception

Evolutionary (2)

#1 #2 #n+1 # . . #m #m+1 #m+2 . . Iter.No.

Prel.Iteration

Elabo-ration

Cons-truc-tion TransitionInception

Incremental delivery (3)

#1 #2 #3 . . Iter.No.

Elabo-ration Construction TransitionInception

“Grand design” (4)

Strategies for Iterative Development


Planning for Iterative Development

Iteration Plan (next)

Iteration Plan (current)

Phases and major milestones What and when

Project Plan Phase Plan

Iterations for each phase Number of iterations Objectives Duration

Fine-grained Plans

Coarse-grained Plan

“Roadmap”


Concerns in Project Management

Significant concerns for iterative development are: Architecture Risk


Architecture Concerns in Project Management Early elimination of architectural risk in the

project. Other concerns:

Consistent architecture and development guidelines

Relationship between the architecture and organizational structures

Separation of development concerns, which will provide a basis for separation of work

Stability of the technical infrastructures Adherence to standards Required skills


Definition of Risk

Success is meeting the entire set of all requirements and constraints, and satisfying stakeholder expectations.

A risk is whatever may stand in the way of our success or in the way of achieving major milestones.


Risk Reduction Drives the Iterative Lifecycle

Early iterations address the highest risks Risk assessment is a continuous process;

risks change over time


Risk Terms

Direct risk - the project has a large degree of control

Indirect risk - the project has little or no control

Risk attributes: Probability of occurrence Impact on the project (severity)


Risk Management Strategies Risk avoidance

Reorganize project so that it cannot be affected by risk

Risk transfer Reorganize project so that risk is passed off onto some

other stakeholder

Risk acceptance Live with the risk and hope that it never materializes

Risk mitigation (deal with risk head-on) Confront risks Plan for contingencies Monitor risks


Some Sample Risks

Resource risks People, skills, funding

Business risks Competition, ROI, supplier interfaces

Technical risks Unproven technology, uncertain scope

Schedule risks Only 24 hours in a day


Discipline: Requirements

Purpose: Establish and maintain agreement with the customers

and other stakeholders on what the system should do. Provide system developers with a better understanding

of the system requirements. Define the boundaries of (delimit) the system. Provide a basis for planning the technical contents of

iterations. Provide a basis for estimating cost and time to develop

the system. Define a user-interface for the system, focusing on the

needs and goals of the users.


Supplementary Specification

Primary Requirements Artifacts

Requirement

Functional NonFunctional (URPS)

Use-Case Model


Major Concepts in the Use-Case Model

Actor Use Case

An actor represents a person or another system that interacts with the system.

A use case defines a sequence of actions a system performs that yields a result of observable value to an actor.


Actor

System

Actor

Actors are not part of the system. They represent roles a user of the system can play.

An actor can actively interchange information with the system.

An actor can be a passive recipient of information.

An actor can be a giver of information.

An actor can represent a human, a machine or another system.


Charlie asdepot staff

Charlie as depotmanager

Charlie

Depot Staff

Depot Manager

A User Can Act as Several Actors


Use Case

Use Case

A use case specifies a dialogue between an actor and the system.

A use case is initiated by an actor to invoke a certain functionality in the system.

A use case is a complete and meaningful flow of events.

Taken together, all use cases constitute all possible ways of using the system.


Register for Courses

StudentCourse Catalog

A Scenario - One Path Through a Use Case

A use case can have many instances. A scenario is a described use-case

instance: a specific sequence of actions that illustrates behaviors of the system.


A Sample UML Diagram: Use CasesA University Course Registration System

Professor

Select Courses to Teach

Student

Course Catalog

Register for Courses

Maintain Student Information

Maintain Professor Information

Registrar

Billing System

Close Registration


What Is in a Use-Case Model? Actors and their descriptions Use-case diagrams showing relationships For each use case:

Name and brief description Textual specification of:

• Flow of events• Preconditions and postconditions (optional)• Special requirements• Other diagrams, such as activity or state

diagrams


Use Cases in the Development Process:

Drive many activities in the process. Trace to several models.


Use Cases as a Basis for Iteration PlanningUse Cases as a Basis for Iteration Planning

Use-Case Model

Iteration Plan

Fine-grained plan for a single iteration

SupplementarySpecification

Project Management

Constraints


Use Cases as a Basis for System Modeling (1)

verificationrealization

Use-Case Model(requirements)

Implementation Model(source code)

Test Scripts

influence

Design Model(classes and objects)


Use Cases AnalysisClasses

SourceCode

ExecDesignClasses

Use Cases as a Basis for System Modeling (2)


Use Cases as a Basis for Test Planning

The complete behavior of a use case is tested using Test Scripts and Test Suites.

Test Suite

Test Script

Test Script

Test Suite


Requirements TraceabilityTrace product requirements (features) into detailed requirements

Trace requirements into designTrace requirements into test proceduresTrace requirements into user documentation and training materials

Design Model Test Suite End-User Documentation Materials and Training

Materials

1

2 43

1

2

3

4

Vision

Use-Case Model

Supplementary Specification

Stakeholder Needs


Discipline: Business Modeling

Purpose Understand structure and dynamics of

organization in which system is to be deployed Understand problems in target organization and

identify improvement potentials Ensure customer/end user common

understanding of target organization Derive system requirements to support target

organization


Two business models

What a Business Model Shows

Customers Business processes Organizational

structure Roles and

responsibilities Products Internal deliverables Events

Business Object Model

Business Use-Case Model

rational unified process fundamentals module 3: disciplines i

Documents