pm symposium rup uc realization

1

RUP-Based Projects – Understanding and Managing Through a Use Cases Realization Process

Terry Startzel, M.S., PMPVisa Project Management SymposiumM1 5HRD/ Meeting Place 06 December, 2007


2

Agenda

• Rational Unified Process

• Requirements Management

• Use Cases

• Use Case Patterns

• Use Case Realization

• Use Case Realization and Project Management

• Software Architecture - RUP

• 4+1 View of Software Architecture

• Software Architecture Document and Architectural Governance for Projects

• From Use Cases to Test Cases

• Integration with PMM, DMM, and TMM


3

Rational Unified Process (RUP)

• Software Engineering Process / Customizable Process Framework

• Use Case Driven

• Architecture-Centric

• Iterative and Incremental

• Core Best Practices– Develop Iteratively– Manage Requirements– Use Component Architectures– Model Visually– Verify Quality– Manage Change

Rational Unified Process

The Rational Unified Process: An Introduction by Philippe Kruchten


4

Requirements Management

Key Concepts

• Problem Domain

• Stakeholder Needs

• Solution Domain

• Software Features

• Software Requirements– Functional– Non-Functional– Design Constraints

• Traceability

“A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between customer and the project team on the changing requirement of the system.”

Managing Software Requirements: A Use Case Approach (2nd Edition) by Dean Leffingwell and Don Widrig


5


Needs

Features

Software Requirements

Analysis & DesignImplementation

Verification & ValidationUser Documentation

Problem Domain

Solution Domain

Trac

eabi

lity

Software Solution

Problem / Opportunity



6


Software Requirements

Functional Requirements

Design Constraints

Non-Functional Requirements

• Usability

• Reliability

• Performance

• Supportability

• Security

Restrictions on the design of a system, or the process by which a system is developed, that do not affect external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.

• Expresses required system behavior

• Inputs, behavior, outputs

• Action oriented

• Simple declarative statements

• Use Cases



7

Use Cases

Key Concepts

• Ideal for functionally oriented systems

• Requirements in context

• Communicates required system behavior

• Identifies who or what interacts with the system

• Achieve specific goals

• Graphically depicted using Unified Modeling Language

“A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all flows of events related to producing the "observable result of value", including alternate and exception flows. More formally, a use case defines a set of use-case instances or scenarios.”



8

Use Cases

• Defines a sequence of actionsFlows of events related to producing the "observable result of value", including alternate, warning, and exception flows

• Performed by the systemThe actions performed by the system; its functional requirements

• That yields an observable result of value

Primary flow produces the “observable result of value”; a useful heuristic for scoping use cases

• For the actor who initiated the use case

Use Case Diagram in Rational Rose VTSC Application Re-Architecture Project

Use Case Modeling by Kurt Bittner and Ian Spence


9

Use Case Patterns

• Business Process WorkflowSupports the execution of a business process or operation to achieve a business objective; business rules; state transitions

• Analytical Process Supports analytical processes and persists any decisions made as a result of analysis

• MaintainSupports the maintenance of system information

• ViewSupports searching and viewing of information

• GenerateSupports the generation of data files

• ReportingSupports the defining and formatting of reports

“Design patterns form a cohesive language that can be used to describe classic solutions to common object oriented design problems… By using design patterns to solve programming problems, the proper perspective on the design process can be maintained.”

Design Patterns by Gamma, Helm, Johnson and Vlissides


10

Use Case Realization

Key Concepts

• A technique or process

• For designing, implementing, and validating the proposed software system

• Based upon the use cases that comprise the use case model

“A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.”


Through this approach, the seemingly orthogonal relationship between the functional requirements of the system and its design, implementation, and validation is eliminated thus increasing the opportunities for project success.


11


System Must/Will/Shall Requirements Statement 1 UC-1

Requirement Statements with Use Case Traceability


System Must/Will/Shall Requirements Statement 3 UC-2, UC-3


Requirement Statements Use Case ID

UC-1

Use Case Traceability


· Customer Defined Data Elements (MS Excel)

· Webpage GUI Wireframe (MS Visio)

· UI Functional Design Documents (MS Word)

· UML Design Model – Logical View, etc. (Rose)

· Relational Data Modeling (ERWin)

· Process Workflow Definition (jBPM) Process

Class

Table

ClassDefinitionName

Use Case Implementation

Use Case Realization Process

· Relational Database Objects

· HTML Webpages

· Software Components

Logical ViewUse Case

Flow of Events

RDBMS and IDE

Actor


12

Use Case Realization and Project Management

Facilitates project management by providing a basis for:

• Planning Rolling wave project planning by phase and iteration

• EstimatingEstimates provided for each use case realization artifact

• Resource assignmentResources assigned to produce each use case realization artifact

• Execution (mini-milestones)Status reported for the implementation of each use case realization

• Controlling

VTSC Application Re-Architecture ProjectExtract from the VTSC-R Project Work Plan


13

Software Architecture - RUP

Software architecture encompasses: – Significant decisions about the

organization of a software system, – Selection of the structural

elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, and

– Composition of the structural and behavioral elements into progressively larger subsystems

– Architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.

“Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and tradeoffs, and aesthetic concerns.”



14

4+1 View of Software Architecture

Architectural Blueprints—The 4+1” View Model of Software Architecture by Philippe Kruchten Paper published in IEEE Software 12 (6) November 1995, pp. 42-50.

The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP by Per Kroll and Philippe Kruchten

Logical View

Implementation View

Process View

DeploymentView

Use Case View

End UsersFunctionality

Analysts/TestersBehavior

Performance EngineersPerformance

ScalabilityThroughput

System EngineersSystem Topology

Delivery, InstallationCommunication

DevelopersSoftware Management


15

4+1 View of Software Architecture

• Use Case View Architecturally significant use cases

• Logical ViewSoftware elements and structure: classes, packages, interfaces, etc.

• Process ViewDistributed & concurrent systems: parallelism, communication, and synchronization

• Implementation ViewOrganization of implementation elements (source code, etc.) in IDE

• Deployment ViewPhysical runtime deployment and communication

Rational Rose – RUP Template


16

Software Architecture Document and Architectural Governance for Projects

• Major RUP artifact

• Describes software architecture of the proposed software system

• Driven by architecturally significant use cases

• Includes appropriate views from the 4+1 View of Software Architecture

• Elaboration Phase deliverable

• Input LAM Review Gate

• Subject to the Technology Office’s Architectural Governance for Projects

VTSC-R Project’s SAD Cover Page

http://insiteusa/Dept/cto/EA/ProjectArchitectureGovernance.aspx

http://insiteusa/Dept/cto/EA/ProjectArchitectureGovernance.aspx


17

From Use Case to Test Cases

Use Case Flow of Events - Scenarios

Key Concepts

• Use Case Scenarios– An instance of a use case just as an

object is an instance of a class– A complete path through a use case’s

flow of events possibly including nested alternate flows

• Test Case Matrix– At least one test case for each scenario– May need both positive and negative

test cases

• Test Case Matrix with Values

• Test Cases and ProceduresGenerating Test Cases from Use Cases by Jim Heumann


18

Integration with PMM, DMM, and TMM

• PMM– Initiate Phase (e.g., SOW)– Plan Phase (e.g., Project Plan, Schedule, PPR Gate)– Execute Phase (e.g., Iteration Plans, SAD, LAM Gate, IOCM Gate)– Launch Phase (e.g., PIR Gate)– RUP PMM Compliance Controls

• DMM– Plan Development Activities – Inovant RUP Development Project– Key Deliverables (e.g., System Requirements, Architecture, User

Interface Design, Design Specification)

• TMM– Test Activities - Plan Test Activities – Key Deliverables (e.g., Test Design)

http://insiteusa/deptusa/dmm/devactivity/pda.cfm

http://insiteusa/dept/TMM/test/pta.cfm