Software Engineering Learning Programme

RUP Life Cycle

Software Engineering Learning Programme

Software Engineering Foundation

Producer/ddmmyy
-

Title
-

author /
2

Module Objectives


To understand the main concepts
-

RUP Fundamentals
-

Terminology
/ context / deliverables


To understand the benefits and best practices



Understand the role of the SE within RUP


Understand what input deliverables are needed and where do they
come from


Which output deliverables are used as input for roles further in the
process and how they are used







Delivery Guidelines

Format:

Webcast / and intructor
-
intro

Duration:

3 hours / 60 Minutes

Producer/ddmmyy
-

Title
-

author /
3

Module Topics


What about RUP


Background and why use it,


RUP


Best practices


Model Visually


Requirements management


Importance of traceability


Importance of configuration management


RUP language


Terminology and symbols


Deliverables


SE role level 1

Producer/ddmmyy
-

Title
-

author /
4

RUP
–

what about it and why use it?


The "Rational Way" is:


Iterative and incremental


Object
-
oriented


Managed and controlled


Highly automated



It is generic enough to be tailorable to a wide variety of software
products and projects, both in size and application domain. It is
centered around three poles:


People


Process


Tools and methods


Producer/ddmmyy
-

Title
-

author /
5

RUP
–

history.


1998 Rational Unified Process (RUP) released to the public.


Result of from team collaborations and three software developers. “Three
Amigo’s”


RUP successor of Rational Objectory Process (ROP), includes all aspects of
the software development life
-
cycle.


1999 OMG issues a request for proposal (RFP).




Goal to provide an industry standard for tools and technologies for the software
development lifecycle.




May 2000, Rational Software Corporation, IBM, et al, submit the
Unified Process Model (UPM)


And now…

“Object
-
Oriented
Modelling and Design”
(1991)

“Object
-
Oriented Software
Engineering:

A Use Case Driven Approach”
(1992)

GRADY

BOOCH

IVAR

JACOBSON

JAMES

RUMBAUGH

“Object
-
Oriented
Design with

Applications” (1993)

Producer/ddmmyy
-

Title
-

author /
6

Phases, Disciplines and Milestones

Time

Content

Producer/ddmmyy
-

Title
-

author /
7

Best practices









Develop Iteratively

Manage Requirements

Model Visually

Use Component Architectures

Continuously Verify Quality

Control Change

Best
Practices

Producer/ddmmyy
-

Title
-

author /
8

Best Practice 4 Model Visually


Capture the structure and behavior of architectures and components


Show how the elements of the system fit together


Hide or expose details as appropriate for the task


Maintain consistency between a design and its implementation


Promote unambiguous communication


Visual modeling improves our ability to manage


software complexity


The Unified Modeling Language (UML) is a language for

•
specifying,

•
visualizing,

•
constructing, and

•
documenting

•
the artifacts of software systems
.

Producer/ddmmyy
-

Title
-

author /
9

Diagrams are view of a Model

Producer/ddmmyy
-

Title
-

author /
10

Best practice 2 Manage Requirements

Producer/ddmmyy
-

Title
-

author /
11

Requirement and Requirements Management


A
requirement

describes a condition or capability to which a system
must conform.
.


Types:


Functional requirements


Non
-
functional requirements


packaged
Software Requirements Specification (SRS
)



Requirements management is a systematic approach to finding,
documenting, organizing and tracking the changing requirements of a
system




White Paper: Applying Requirements Management with Use Cases



Producer/ddmmyy
-

Title
-

author /
12

Business Needs


drive


Customer Needs


which drive

User Needs


which demand


Product Features


that drive


Software Requirements



that we developers

Implement

and

Test

E . Magaziner ‘96

What is Requirements Traceability?

Producer/ddmmyy
-

Title
-

author /
13

Why Use Requirements Traceability?


The purpose is to:


Verify that all requirements of the system are fulfilled by the implementation.


Verify that the application does only what it was intended to do


Help manage change


A proven technique for assuring quality


Practiced by high
-
reliability system developers


Mandated by standards (e.g.: DOD, FDA)


Recommended by IEEE and CMM


A proven technique for understanding the impact of changes

Producer/ddmmyy
-

Title
-

author /
14

Sample Queries Using Requirement Links


Show me user needs which are not linked to product features


Show me the status of tests on all use cases in iteration #3?


Show me all supplementary requirements linked to tests whose
status is untested


Show me the results of all tests which failed, in order of criticality


Show me the features scheduled for this release, which user needs
they satisfy, and their status

Producer/ddmmyy
-

Title
-

author /
15

Determine Your Requirement Traceability Strategy

Stakeholder

Requests

Vision

Design Model

Supplementary

Specification

End
-
User Documentation

Materials and

Training Materials

Use
-
Case


Model

Test Model

Features

Software

Requirements

Needs

Producer/ddmmyy
-

Title
-

author /
16

1.

Trace top level
requirements into detailed
requirements

2.

Trace requirements into
design

3.

Trace requirements into test
procedures

4.

Trace requirements into
user documentation plan


Design

Software Design
Descriptions

Object Models

Test Suites


Test

2

3


Req A


1

Product

Requirements

(Features)

Detailed

Requirements

(Use Cases)


Req B

Documentation
Plan

User Docs

4

Establish Traceability Paths

Producer/ddmmyy
-

Title
-

author /
17

Viewing Links
-

Traceability Matrix

Producer/ddmmyy
-

Title
-

author /
18

Viewing Links
-

Tree Report

Tree reports provide the ability to trace linkages through the document hierarchy.

Producer/ddmmyy
-

Title
-

author /
19

What is Configuration Management?


Configuration Management is a discipline which enables you to
identify the components of a system, so that you can:


Control all changes to the components


Maintain integrity and traceability through the whole application
life cycle

Producer/ddmmyy
-

Title
-

author /
20

Why Configuration Management?


To follow the progress of developments


To follow the evolution of one particular component


To ensure the use of the right component


To allow sharing of one component between several developers
without conflicts and loss of data


To ensure the safety of components


To allow regeneration of complete and up
-
to
-
date application
versions


To provide visibility on the development / maintenance cycle

Producer/ddmmyy
-

Title
-

author /
21

Configuration Management Software


CM Software Provides the Ability to
:


Maintain a single copy of system elements


Control access to data


Maintain an exhaustive inventory of software components


Maintain a history of changes


Follow and control a defined process


Manage the security of different environments (development,
QA, production)

Producer/ddmmyy
-

Title
-

author /
22

RUP
–

terminology


RUP uses roles, disciplines, phases and artifacts


Some terms are new for developers;


Know the RUP language!


Producer/ddmmyy
-

Title
-

author /
23

Schedule oriented terms in the RUP

Inception

Construction

phase

Elaboration

Transition

proces iteration

development cycle

milestone

release

Final
production
release

product increment

=

delta

release

Initial

Operational

Capability

LifeCycle
Architecture
Milestone

LifeCycle
Objectives

Milestone

Producer/ddmmyy
-

Title
-

author /
24

RUP Terminology: Discipline

All activities you may go through to
produce a particular set of artifacts.


The contents of each
discipline in RUP are
organized as shown in
the Environment
discipline example.

Producer/ddmmyy
-

Title
-

author /
25

Disciplines Produce Models

Use
-
Case

Model

Implementation

Model

implemented

by

Test

Model

verified by

realized

by

(Analysis) Design


(Model) Model

automated

by

Analysis &
Design

Requirements

Implementation

Test

Business

Modeling

Business Use
-
Case Model

Business

Object Model

Producer/ddmmyy
-

Title
-

author /
26

RUP Terminology : Workflow


Disciplines

>
Test

> Workflow


Workflows: Each Discipline
contains one Workflow which
shows a typical sequence of
events when conducting the
flow of work.


Workflows are expressed in
terms of Workflow Details
which are ordered
conditionally.



Workflow
Details

Producer/ddmmyy
-

Title
-

author /
27

RUP Terminology : Workflow Details

Example:


Disciplines

>
Test

>
Workflow

> Improve Test Assets


Workflow Details are groupings of
activities that are done "together,"
presented with input and resulting
artifacts.


Disciplines are explained using
Workflow Details.


Producer/ddmmyy
-

Title
-

author /
28

RUP Terminology : Activity


A piece of work a role may be asked to perform


Granular: usually takes a few hours to a few days


Repeated, as necessary, in each iteration



Example

Thinking






Performing






Evaluating

Activity: Find use cases and actors


Step: Find Actors


Step: Find Use Cases



Step: Describe How Actors & Use Cases Interact


Step: Package Use Cases and Actors


Step: Present Use
-
Case Model in U
-
C Diagrams


Step: Develop a Survey of the Use
-
Case Model



Step: Evaluate Your Results

Producer/ddmmyy
-

Title
-

author /
29

RUP Terminology : Artifact


A piece of information that is produced, modified, or just used by a
process


Defines an area of responsibility


Likely to be subject to configuration control


Kinds of artifacts:


Models


Model elements


Documents


Artifacts may contain other artifacts

Producer/ddmmyy
-

Title
-

author /
30

Example: Artifact Overview Diagram

System
Analyst
Stakeholder
Requests
Vision
Use-Case
Model
Supplementary
Specification
Glossary
Requirements
Specifier
Use Case
Use-Case
Package
User-Interface
Designer
Actor
(human)
Use-Case
Storyboard
User-Interface
Prototype
Boundary
Class
Software
Requirements
Specification
Requirements
Attributes
Requirements
Management
Plan
Example:

Disciplines
-
> Requirements
-
> Artifact Overview

Producer/ddmmyy
-

Title
-

author /
31

RUP Terminology : Role


A role defines the
behavior

and
responsibilities

of an individual, or
a set of individuals, working together as a team


Behavior: a set of cohesive activities


Responsibilities: usually defined relative to certain artifacts


A role is a “hat” worn

by an individual

RUP role set

•
Analysts

•
Developers

•
Testers

•
Managers

•
Other roles

Producer/ddmmyy
-

Title
-

author /
32

Example: Role Responsibility Diagram

Example:

Systems
Analyst

Example:

Implementor

Producer/ddmmyy
-

Title
-

author /
33

Guidelines


Rules, recommendations, heuristics that support artifacts and
activities


Add the benefit of experience to activities


Describe well
-
formed artifacts, focus on qualities


Describe specific techniques


Transformations from one artifact to another


Use of UML


Used also to assess the quality of artifacts


Can be tailored by the organization


Work guidelines:


Provide work and documentation techniques, often complements to the
formal artifacts defined in the RUP


Can be used as an aid in more than one of the activities


Focus on techniques that help team communication

Producer/ddmmyy
-

Title
-

author /
34

Tool Mentors


Similar to guidelines


Explain how to use a specific tool to perform an activity or steps in
an activity


Linked by default to Rational tools:


Rational RequisitePro: requirements management


Rational Rose: visual modeling, using UML


Rational SoDA: documentation generation


Rational ClearQuest: change management, defect tracking


…. and more

Producer/ddmmyy
-

Title
-

author /
35

4 + 1 View Model

Process
View

Deployment
View

Logical

View

Implementation
View

Programmers

Software management


System Integrators

Performance

Scalability

Throughput


System Engineering

System topology


Delivery, installation

communication

Use
-
Case
View

End
-
user

Functionality

Analysts/Testers

Behavior

Producer/ddmmyy
-

Title
-

author /
36

Summary



What about RUP


Background and why use it,


RUP


Best practices


Model Visually


Requirements management


Importance of traceability


Importance of configuration management


RUP language


Terminology and symbols


Deliverables


SE role level 1



Producer/ddmmyy
-

Title
-

author /
37

More to know….


Sources used when developing the RUP product


Explore the RUP knowledge base.


RUP Glossary


RUP Resource Center online


Visit
www.therationaledge.com

and
Rational developers network



Books:

•
The Rational Unified Process an Introduction

Philippe Kruchten

•
Building J2ee Applications with the Rational Unified Process
Peter Eeles

•
Building Web Applications with UML
J
im Conallen


Examples white papers


Reaching CMM Levels 2 and 3


Applying Requirements Management with Use Cases


Developing Large
-
Scale Systems with the Rational Unified Process


The Ten Essentials of RUP
—

The Essence of an Effective Development
Process


Using the Rational Unified Process for Small Projects: Expanding Upon
eXtreme Programming

Producer/ddmmyy
-

Title
-

author /
38

Exercise 1/1

1.
What’s the relationship between a Role, Artifact and Activity?

2.
What are the roles the CGEY Software Engineer can realize?

3.
How do Workflows, Workflow Details and Activities fit together?

4.
What is the importance of the iteration plan for a SE?


5.
Right or Wrong? (explain your vote !)

1.
In the discipline Analyse And Design the analyst performs use case analysis.

2.
The System Architect is responsible for the analysis model

3.
The Designer is responsible for the activity Find Business actors and use cases

4.
The Use case template should always completely been used.

5.
The Designer is not responsible for the design Model.

6.
The Test Designer performs Unit Tests

7.
The Implementer plans and integrates subsystems

8.
The Integrator is responsible for the integration build plan

9.
The deployment unit is an artifact for which the deployment manager is responsible.

10.
Use case realizations are realized in requirements.

Producer/ddmmyy
-

Title
-

author /
39

Exercise 1/2

1.
What artifact the SE is responsible for contains other artifacts?

2.
Are there any changes for the developer in the new version of RUP
(2003)

3.
Take 5 artifacts a SE will be responsible for. Describe for each
artifact the RUP role responsible and in which view (of the 4 in 1
model view) this artifact is described.

4.
What Tools will be used by a CGEY SE in the different roles?

5.
Are all tools necessary for a development cycle? What is the
minimum set?

6.
How do Tool Mentors work in RUP?


Producer/ddmmyy
-

Title
-

author /
40

Questions