1. Introduction to Rational Unified Process
Chapter 2 Text
Modified in many cases to support instructional needs. Original developed by Rational

2. What Is a Process?
It can be very difficult to explain what a process is, if people aren’t already familiar with it. An informal example most people can relate to is the process of balancing a checkbook at the end of the month. Most of us have developed a process we use - the same steps every month. It shortens the time required to accomplish the task and ensures that we don’t forget any steps. The same applies to a software engineering process. We want it to be repeatable and ensure that all required tasks are accomplished when required. Of course, a software engineering process is much more complex than balancing a checkbook and there is a tremendous amount of information contained in the RUP.
A process defines Who is doing What, When and How to reach a certain goal. In software engineering the goal is to build a software product or to enhance an existing one
New or changed
requirements
system
Software Engineering
Process
We will use the RUP - a generic process that uses UML as a modeling language.
The RUP can be used for any kind of software system (information system,
scientific or engineering-oriented system, etc.)
Workers: the WHO
Activities: the HOW
Artifacts: the WHAT
Workflows: the WHEN

3. RUP Characteristics Iterative Use-case driven Architecture-centric
Rational Unified Process is best described as an
Iterative
Use-case driven
Architecture-centric

4. RUP: Iterative Development
Iteration 1
Iteration 2
Iteration 3
 Earliest iterations address greatest risks
Each iteration produces an executable release
Each iteration includes integration, test, and assessment!
Objective Milestones: short-term focus; short term successes!

5. Iterative Process Produces a Release
Initial
Planning
Requirements
Analysis & Design
Implementation
Test
Deployment
Evaluation
Management
Environment
Each iteration results in an executable release

6. Source Code edit, compile, debug, link
RUP: Use-case driven
A use-case driven process means that the use-cases designed for a system are the basis for the entire development process:
The point to be made is that the UML is the language we use to visually model. Since it is a widely-adopted standard, it facilitates understanding and communication of the visual models we create.
Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering.
Use-Case Diagram
Class Diagram
State Diagram
use-case 1
Actor A
Actor B
use-case 2
Customer
<<entity>>
addr
name
Domain
Expert
use-case 3
withdraw()
receive()
send()
fetch()
Deployment Diagram UI
Class
MFC
DocumentApp
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼­¹ö
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
RogueWave
Persistence
Repository
DocumentList
9: sortByName ( )
Window95
Windows95
Windows95
User Interface
Definition
global
mainWnd : MainWnd
Package Diagram
FileManager
¹®¼­°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼­°ü¸® ¾ÖÇø´
1: Doc view request ( ) L
Document
Windows NT
2: fetchDoc( )
Solaris
4: create ( )
gFile : GrpFile
¹®¼­°ü¸® ¿£Áø.EXE
8: fillFile ( )
Alpha
UNIX
user : »ç¿ëÀÚ
GraphicFile
Windows NT
ÀÀ¿ë¼­¹ö.EXE
fileMgr : FileMgr
3: create ( )
File
FileList
Mainframe
IBM
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼­¹ö
7: readFile ( )
repository : Repository
5: readDoc ( )
document : Document
Component Diagram
Forward Engineering (Code Generation)
and
Reverse Engineering
Collaboration Diagram
user
mainWnd
fileMgr :
FileMgr
Document
document :
gFile
repository
Source Code edit, compile, debug, link
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
7: readFile ( )
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
º¸¿©ÁØ´Ù.
È­¸é °´Ã¼´Â ÀоîµéÀÎ
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
9: sortByName ( )
8: fillFile ( )
Sequence Diagram
Executable System

7. RUP: An Architecture-Centric Process:
Architecture is a primary focus of the early iterations
Building, validating, and base lining the architecture constitute the primary objectives (but not all) of Elaboration Phase – especially the first iteration…
Benefits of an Architecture-Centric Process
(Think ‘parts’: layers, subsystems, packages, relationships, components, etc….)
Manage its complexity,
Provides an effective basis for large-scale reuse
Provides a basis for project management – allocation to teams
Architecture was defined and explained in the Best Practices module already presented. Here we assume that the student remembers this material. You may wish to briefly review the definition of architecture and relate it to blueprints,etc.

8. The Three-Tier Layered System Architecture

9. RUP Structure
The Rational Unified Process is structured along two dimensions:
Time (Dynamic Structure) — division of the life cycle into phases and iterations
Process components (Static Structure)—production of a specific set of artifacts with well-defined activities
Both dimensions must be taken into account for a project to succeed.

10. Process components are applied to each time-based phase
Each activity of the process component dimension typically is applied to each phase of the time-based dimension. However, the degree to which a particular process component is applied is dependent upon the phase of development. For example, you may decide to do a proof of concept prototype during the Inception Phase, and thus, you will be doing more than just capturing requirements (you will be doing the analysis, design, implementation, and test needed to complete the prototype).

11. Structuring a project along the time dimension involves the adoption of the following time-based phases:
Inception
Elaboration
Construction
Transition
The student notes are quite extensive. There is no need to go into that much detail in class. The important thing is to understand how the RUP uses phases to organize the life cycle.
You can also mention that we deliberately chose names that do not match the waterfall names (analysis, design, implementation, and test) to emphasize that they are NOT the same as the waterfall phases.
Some ways of describing the phases in common terminology:
Inception - bid and proposal
Elaboration - Building blueprints
Construction - I think I’m done
Transition - how do users react?
time
Inception - Define the scope of project
What is included; what is not; identify all actors and use cases; draft about 20% of essential use cases; High level identification.
Lots of artifacts: Business Rules, Vision, desired Features, Domain Model, costs, schedule, Risk List, Business modeling, and more)
Elaboration - Plan project, Specify features, use cases are detailed and architectural decisions are made, have about 80% of essential requirements identified; (for us, use-cases)
Good grasp of requirements and architecture.
Most key analysis and design done. (often a couple of iterations…)
Construction - Construction is where the bulk of the coding is done. Build the product via several iterations; up to beta release; Essentially programming and unit test; iterations; assessment, …Several iterations (time-boxed)…
Transition - Transition the product to end user community; end-user training and support; installation, etc.
The majority of the analysis process component occurs during the Elaboration Phase. However, it is also advisable to complete the first few iterations of the system during this phase. These first few iterations typically are used to validate the analysis decisions made for the architecture of the system. Hence, you are doing more than just analyzing the problem.
During the Construction Phase of development, the system is completed as a series of iterations. As with any type of development structure, things always crop up as the system is built; thus, you are still doing some analysis.
The diagram is meant to be a guideline for the life cycle of your project. The main point is if you are still trying to figure out what you are supposed to be building as you are writing the code, you are probably in trouble. You should also note that testing is applied throughout the iteration process—you do not wait until all the code is done to see if it all works together!

12. Process Component (Workflows) Dimension
Structuring the project along the process component dimension includes the following
Business Modeling —the study of an organization so we can identify the desired system capabilities and user needs
Requirements—a narration of the system vision along with a set of functional and nonfunctional requirements
Analysis and Design —a description of how the system will be realized in the implementation phase
Implementation —the production of the code that will result in an executable system
Test —the verification of the entire system
Deployment —the delivery of the system and user training to the customer activities:

13. Phase Boundaries Mark Major Milestones
Inception
Elaboration
Construction
Transition
The student notes are extensive and there is no need to go into detail with each milestone. The most important point to get across is that there are formal milestones marking major decision points with the RUP lifecycle just like there is in the waterfall.
The criteria listed in the student notes are extensive because they are thorough. However, only one or two of the criteria at each point are really important. The ones to emphasize are:
LCO: scope agreed upon and risks understood and reasonable
LCA: high risks addressed and architecture stable
IOC: product is complete and quality acceptable
time
Lifecycle
Objective
Milestone
Architecture
Initial Operational
Capability
Product
Release
Note the titles of the Milestones.
At each of the major milestones, the project is reviewed and a decision made
as to whether to proceed with the project as planned, to abort the project,
or to revise it.
These are indeed MAJOR milestones!

14. Iterations and Phases – Closer Look at Process Architecture
Preliminary
Iteration
Architect.
Devel.
Transition
Inception
Elaboration
Construction
Minor Milestones: Releases
An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an ‘executable’ release (internal or external) and assessment of the iteration
Number of iterations per phase is variable.
Each iteration can result in an executable release where the system
evolves into a large system.

15. Bringing It All Together: The Iterative Model
In an iteration, you walk through all Workflows.
Relative
amount of
color shows
level of
activity in
each
iteration
Development Team Focus
Phases
Can iterations overlap?
No. Our model is to show no overlap among iterations. In a large project, several teams may work in parallel on their portions of the iteration, but we do not consider these to be separate iterations.
How many iterations should you have?
It depends on many factors. Err on the side of too many iterations.
Animation note: The callouts and black rectangle appear 2 seconds after the slide.
Process Workflows
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration & Change Mgmt
Workflows group activities logically
Project Management
Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Iterations

16. Example
For example, a two-year project would have the following:
A 2 ½ month inception phase
A 7 month elaboration phase
A 12 month construction phase
A 2 ½ month transition phase
Phases length varies greatly depending on the specific circumstances of the project. What is important is the goal of each phase and the milestone that concludes it.

17. Process Notation – Figures used in the RUP
A unit of work that a worker may perform.
A role played by an individual or a team.
A piece of information that is produced, modified or used by a process.

18. One of nine core workflows
Key Concept: Workflow
Sequence of activities that produce a result of observable value
One of nine core workflows
Core workflow = disciplines
Iteration workflow
Workflow details

19. Requirements Workflow
The Systems Analyst has MUCH to do…
Develop
Elicit Stakeholder
This is not the business model
Vision
Needs
Find Actors
and Use Cases
(Domain modeling)
Structure the
Manage
Capture a
Use-Case Model
Dependencies
Common
Requirements
Vocabulary
Reviewer
You will likely be
doing many of
These activities individually
or as part of a team
Detail a
Review
Use-Case
Use Case
Specifier
Requirements
Purpose: To come
to agreement with
customers and
users on what the
system should do.
To give developers
a better under-
standing of the
requirements of
the system.
User-Interface
User-Interface
User-Interface
Modeling
Prototyping
Designer
Prioritize
Architect
Use Cases

20. Summary: Rational Unified Process
A software development process defines Who is doing What, When and How in building a software product
The Rational Unified Process has four phases: Inception, Elaboration, Construction and Transition
Each phase ends at a major milestone and contains one or more iterations
An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release

21. Summary (cont.): Rational Unified Process
A workflows groups related activities together
Each workflow is exercised (to a greater or lesser degree…) during an iteration and results in a model that is incrementally produced
An artifact is a piece of information that is produced, modified, or used by a process
A worker is a role that may be played by an individual or a team in the development organization
An activity is a unit of work a worker may be asked to perform