the rap on rup : an introduction to the rational unified ... presents/raponrupspinforweb.pdf ·...

The Rap on RUP™ : An Introduction to the Rational Unified Process™

Jeff JacobsJeffrey Jacobs & Associates

Belmont, CAphone: 650.571.7092

email: [email protected]://www.jeffreyjacobs.com

December 3, 2003Jeffrey Jacobs & Associates, Silicon

Valley SPIN 2

Survey

Does your organization have a well defined methodology/process?Does your organization use OOA/OOD?Does your organization use UML?


Valley SPIN 3

Agenda

What is RUP?RUP FundamentalsPhasesProduct “features”CaveatsSummaryQuestions


Valley SPIN 4

Process/Methodology Product Presentation

Minimal UML bashingNo rhymingNo comparison with other methodologiesRUP appears to be in flux since Rational’sacquisition by IBM


Valley SPIN 5

Why RUP™ at SPIN?

The (RUP™ ) Knowledge base allows development teams to gain the full benefits of the industry standard UMLRUP™ covers all UML modelsRUP™ is hothot; the latest silver bullet…


Valley SPIN 6

What is RUP™?

A “software engineering process” (methodology)A knowledge base “process product”

CD to create web site

UML model focused, not “paper documents” (but…)


Valley SPIN 7

What is RUP™?

Configurable process/productRecognizes and supports variety of different project typesSupport for tailoring and configuring project web sites

Project oriented


Valley SPIN 8

3 Flavors of RUP

Generic - not dependant on specific technologyMicrosoft Web Solution Technology

Additional templates, guidelines etc

IBM Websphere™ Technology


Valley SPIN 9

History

Methodology by Merger & AcquisitionObjectory Process created in ‘80sRational Approach created in ‘80sAcquisition of RequisiteProIBM acquires Rational


Valley SPIN 10

Why Should You Care About RUP™?

Your organization is at SEI/CMM Level 1“Ad Hoc”

Provides an excellent path to CMM Levels 2 and 3

You need to add OOA/OOD to your current process/methodologyManagement wants to know when you’re going to use the latest silver bullet


Valley SPIN 11

RUP™ Fundamentals

RUP is object and process orientedData takes a back seat

Architecture is “key to success”Emphasizes need for prototyping of core functionality, not just UI

Iterative developmentUse Cases are (were?) primary requirements specification technique


Valley SPIN 12

4 Phases

InceptionElaborationConstructionTransition


Valley SPIN 13

Inception

Establish business case and business modelsEstablishes initial “vision”, high level requirements via “business” use casesCreate stakeholder “buy in”Evaluate risks and return


Valley SPIN 14

Elaboration

Detailed requirementsArchitecture and prototypeDesign


Valley SPIN 15

Construction

Coding and testing


Valley SPIN 16

Transition

Putting the product in the user’s handsHighly variable, depending on product

Data migrationTrainingParallel OperationsBeta testingEtc.


Valley SPIN 17

Overview of RUP™ (Organization)


Valley SPIN 18

Best Practices

Develop software iterativelyManage requirementsUse component-based architecturesModel visuallyContinuously verify qualityControl changes


Valley SPIN 19

Key Concepts of RUP™

Organized by disciplineWorkflow - model of process for a disciplineWorkflow Details - 2nd level detail of workflow, detailing activities, roles and artifactsRole - who performs an activityActivity - defined piece of work that results in an artifact


Valley SPIN 20

More Key Concepts

Artifact - a deliverable, may be document, model, code, etc

Templates and examples for many artifacts

Tool Mentor - guide on using Rational Tools for RUP™


Valley SPIN 21

Analyst Roles

Business-Model Reviewer Business Designer Business-Process Analyst System Analyst Requirements SpecifierTest Analyst User-Interface Designer


Valley SPIN 22

Developer Roles

Capsule Designer Code Reviewer Database Designer Implementer Integrator


Valley SPIN 23

More Roles

TestersManagersProcess Engineer Project Manager Change Control Manager Configuration Manager Deployment Manager Project Reviewer Test Manager


Valley SPIN 24

Disciplines

A collection of related activities that are related to a major 'area of concern' within the overall projectDisciplines span phases


Valley SPIN 25

RUP™’s Disciplines

Business ModelingRequirementsAnalysis and Design (Analysis <> Requirements, not performed by “analyst” role)ImplementationTest

DeploymentConfiguration and Change ManagementProject ManagementEnvironment


Valley SPIN 26

Each Discipline is Composed of:

Overview

Introduction

Concepts

Workflow - the high level activity diagram (process flow)

Workflow detail -second level process

Activities - actions performed by roles

Artifacts - deliverables

Guidelines - tutorials, checklists, etc


Valley SPIN 27

Discipline Overview


Valley SPIN 28

Introduction


Valley SPIN 29

Concepts

Fundamentals of discipline/role


Valley SPIN 30

Concept Example


Valley SPIN 31

Everything is Use-Case Driven


Valley SPIN 32

Workflow


Valley SPIN 33

Workflow Detail


Valley SPIN 34

Activity


Valley SPIN 35

Activity Step


Valley SPIN 36

Artifacts May Be Documents, Models, Code, Etc.


Valley SPIN 37

Document Templates

Templates for document artifacts available in a variety of formats

Microsoft WordHTMLFramemakerRational SODA

Business Glossary Template


Valley SPIN 38

Guidelines


Valley SPIN 39

Guideline Example


Valley SPIN 40

Checkpoints for Quality Reviews


Valley SPIN 41

More Stuff

Sample ProjectsProject Management TemplatesTool Mentors


Valley SPIN 42

Sample ProjectsExamples of many artifacts for two projects

Course Registration SystemCollegiate Sports Paging Systems


Valley SPIN 43

Glossary Example


Valley SPIN 44

Project Management Templates

Summary MS Project ExampleDetail MS Project Example


Valley SPIN 45

Tool Mentors - How to Use Rational Tools in RUP™


Valley SPIN 46

CaveatsRUP™ is far from complete

Focused on software developmentSeries of books on Unified Process … Phase by Scott Ambler and Larry Constantine provide “missing” coverage

Project orientedLack of comprehensive “book” makes learning difficult


Valley SPIN 47

More Caveats

IBM influence is creating some confusion and inconsistenciesUse Cases are insufficient for good requirements, IMHOFails to adequately address “data intensive” applications

Only addresses database design, no place for “data requirements”

Viewed as “silver bullet” by many


Valley SPIN 48

Summary

Forms solid basis for improving software development process, particularly for ad-hoc, Level 1 organizationsProvides basis for incorporating OOA/OOD/UML into current software development processProvides basis for development using IBM, Rational and Microsoft technologies30 day on-line evaluation available, http://www.rational.com


Valley SPIN 49

Questions