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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 3
Disciplines
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 4
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 5
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 6
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 7
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 8
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 9
Discipline: Project Management
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?
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 10
Discipline: Project Management
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)
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 11
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
Devel. Devel. 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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 12
#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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 13
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”
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 14
Concerns in Project Management
Significant concerns for iterative development are: Architecture Risk
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 15
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 16
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 17
Risk Reduction Drives the Iterative Lifecycle
Early iterations address the highest risks Risk assessment is a continuous process;
risks change over time
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 18
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)
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 19
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 20
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 21
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 22
Supplementary Specification
Primary Requirements Artifacts
Requirement
Functional NonFunctional (URPS)
Use-Case Model
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 23
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 24
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 25
Charlie asdepot staff
Charlie as depotmanager
Charlie
Depot Staff
Depot Manager
A User Can Act as Several Actors
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 26
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 27
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.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 28
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 29
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 30
Use Cases in the Development Process:
Drive many activities in the process. Trace to several models.
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 31
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 32
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)
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 33
Use Cases AnalysisClasses
SourceCode
ExecDesignClasses
Use Cases as a Basis for System Modeling (2)
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 34
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 35
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 36
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
Rational Unified Process FundamentalsCopyright © 1999-2001 Rational Software, all rights reserved 37
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