® IBM Software Group © 2004 IBM Corporation Incremental Adoption of RUP and OpenUP Per Kroll, IBM.

®

IBM Software Group

© 2004 IBM Corporation

Incremental Adoption of RUP and OpenUPPer Kroll, IBM

IBM Software Group | Rational software

2

Per Kroll - Background

Project lead – Eclipse Process Framework

Development Manager – RUP / Rational Method Composer

Process Technology Strategist – IBM Rational

(Co-) Author of The Rational Unified Process Made Easy –

A Practitioner’s Guide to RUP Agility and Discipline Made Easy –

Practices from OpenUP and RUP


3

Why you are here

Unified Process is a framework - it is too big to adopt all at once

Hard to identify and prioritize incremental improvements

Hard to know where to start

Hard to decide when to stop


4

Agenda

What is OpenUP and EPF?

The process landscape – variation in process needs

Principles and practices – what are they?

Unified Process principles and practices

Getting started

Latest news on RUP / RMC (if time permits)


5

Eclipse Process Framework (EPF) Project

Serves as a foundation for an evolving open source software development process ecosystem

Provides tooling, a unified metamodel, and content that can be used as the foundation for a large variety of processes to address IT needs

Uses the Eclipse community to gain wide acceptance of the framework


6

EPF Ecosystem

TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing)

Free Process

Content

Plug-ins

Free Process

Content

Plug-ins

META MODEL (Unified Method Architecture)META MODEL (Unified Method Architecture)

ECLIPSEECLIPSE

Commercial

Process

Content

Plug-ins

Commercial

Process

Content

Plug-ins

Tool Extensions

Tool Extensions

Extensible, Customizable, FlexibleExtensible, Customizable, Flexible

Common Language & VocabularyCommon Language & Vocabulary

Open Source DevelopmentOpen Source Development

Inhouse

Content

Plug-ins

Inhouse

Content

Plug-ins

Basic Unified Process

Adapted from RUP

Basic Unified Process

Adapted from RUP ScrumScrum

TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing)

Free Process

Content

Plug-ins

Free Process

Content

Plug-ins

META MODEL (Unified Method Architecture)META MODEL (Unified Method Architecture)

ECLIPSEECLIPSE

Commercial

Process

Content

Plug-ins

Commercial

Process

Content

Plug-ins

Tool Extensions

Tool Extensions

Extensible, Customizable, FlexibleExtensible, Customizable, Flexible

Common Language & VocabularyCommon Language & Vocabulary

Open Source DevelopmentOpen Source Development

EXTENSIONS

• Project Mgmt.

• Oper. Mgmt.

• Systems Mgmt.

EXTENSIONS

• Project Mgmt.

• Oper. Mgmt.

• Systems Mgmt.

EXTENSIONS

• Project Mgmt.

• Oper. Mgmt.

• Systems Mgmt.

EXTENSIONS

• Project Mgmt.

• Oper. Mgmt.

• Systems Mgmt.

Inhouse

Content

Plug-ins

Inhouse

Content

Plug-ins

Adapted from RUP

OpenUP/Basic

Adapted from RUP Scrum

Value-BasedSoftware Eng.Value-Based

Software Eng.Model-DrivenArchitecture

Model-DrivenArchitecture

• XP• Scrum

Agile “Box”OPEN Process OPEN Process

FrameworkFramework

Open Unified Process (OpenUP)

• DSDM• AMDD


7

What Is OpenUP?

An open-source software development process,

including a base (OpenUP/Basic) and extensions (like OpenUP/MDA),

developed as part the Eclipse Process Framework (EPF) project.

OpenUP/Basic is an iterative software development process that is:

Minimal Only fundamental content is included

Complete Can be manifested as an entire process to build a system

Extensible Can be used as a foundation on which process content can be added or tailored as needed


8

EPF: Growing EcosystemCo-developers

Supporters


9

What’s In IBM Rational Method Composer vs. EPF?

EPFOpen

Source

EPFOpen

Source

Iterative and agile developmentLow-ceremony process guidance

Process followed by Eclipse teamProcess similar to XP

Method authoringPlug-ins / content exchangePublishingWeb-based viewing

Authoring Work Breakdown Str.Auth. Organizational Breakdown Str.Auth. Product Breakdown Str.Capability Patterns

New!

CONTENT TOOLS


10

What’s In IBM Rational Method Composer vs. EPF?CONTENT

TOOLSBusiness modeling and simulationProgram & portfolio mgmtSOA GovernanceSOA for the enterprise

ISO and CMMI complianceLarge scale and distributed devSystems EngineeringRational tool-specific guidanceBusiness modelingAsset production and reuse

Iterative and agile developmentLow-ceremony process guidance

Process followed by Eclipse teamProcess similar to XP

RPM IntegrationAdvanced authoringImport of existing RUP contentImproved page layout

MyRUPProcess Advisor

Method authoringPlug-ins / content exchangePublishingWeb-based viewing

Authoring Work Breakdown Str.Auth. Organizational Breakdown Str.Auth. Product Breakdown Str.Capability Patterns

EPFOpen

Source

IBM RationalMethod

ComposerCommercial

(includes all EPF content and

tooling)

New!

New!


11

EPF Value to RUP Customers

Powerful incremental adoption concept Start with the foundation and quickly establish a starting point.

Add process extensions as required to overcome additional challenges

Leverage proven model of commercial products on top of open source kernel RUP benefits from innovation within its open source kernel

RUP team focuses on customer’s high-value method compositions such as compliance, SOA, etc.

Broad adoption Broader partner ecosystem

More consultants and university graduates with RMC and RUP knowledge.


13

Agenda





Getting started



14


Disciplined Well-documented

TraceabilityCCB

High ceremony

Relaxed Little documentation

Light processLow ceremony

WaterfallFew risk, sequential

Late integration and testing

IterativeRisk driven

Continuous integration and testing

From: Rational Unified Process Made Easy, by Kroll/Kruchten. Addison-Wesley


15

Definitions

DisciplineWork that comes between stakeholder needs and building the application. This includes formal documentation, reviews, presentations, gathering metrics, traceability, investing in reuse, and so on.

Choose the right level of ceremony and iteration length to achieve agility

IterativeIteration length, which is a primary driver of how fast you get feedback on what project activities produced expected results.

“The ability to rapidly respond to risks, changing requirements or stakeholders needs, or other changes impacting the application we are building” Larman 2004

Agility


16

Where Do You Want to Be?


TraceabilityCCB

High ceremony







From: Rational Unified Process Made Easy, by Kroll/Kruchten

3 co-located people,known technology

6 distributed people,poor CM environment

20 people,

safety-criticalsystem


17

Where Do You Want to Be?


TraceabilityCCB

High ceremony







From: Rational Unified Process Made Easy, by Kroll/Kruchten

3 co-located people,known technology

6 distributed people,poor CM environment

20 people,

safety-criticalsystem


18

Some Agile ProcessesWaterfall

Few risk, sequential Late integration and testing



Adaptive Development

XP

SCRUM


TraceabilityCCB

High ceremony




19

Too Common RUP “Misusage”Waterfall





TraceabilityCCB

High ceremony



X

??

Understand where your project should be on the process map so you know how to adopt RUP.

Understand where your project should be on the process map so you know how to adopt RUP.

Adopting RUP is primarily about

adherence to a set of key principles, not following a set of

activities or producing a set of artifacts

Bruce MacIsaac

Add arrows


20

Rational Unified Process FrameworkWaterfall




RUP Process Framework

Light RUP

Config.

Large, more formal RUP

Config.Average

RUP Config.


TraceabilityCCB

High ceremony




21

Agenda




RUP’s principles and practices

Getting started



22

Principles and Practices Principles

General guidance on how to develop systems

Applies to a broad set of contexts

Time resistant

Practices Specific guidance on practical

application of principles

Specific for a limited set of contexts

Typically evolves more rapidly than principles

Principle 1Principle 2Principle 3Principle …

Practice 1.1Practice 1.2Practice 1.3Practice …




23

Each Practice Is Defined as a Process Pattern

Problem addressed Allows you to understand the root cause problem the practice addresses

Applying the Practice Step-by-step guidance for how to apply the practice

Levels of adoption Guides you in how to incrementally adopt the practice, and the impact of

reaching each level


24

Agenda





Getting started



25

Universal principles – the basis of RUP

These principles are the basis for RUP practices.


26

What happened to the 6 “best practices”?

The new principles provide more coverage.

RUP is expanding to cover a broader space – portfolio management, enterprise architecture ….

6 Best Practices Is PART of Principle

Adapt the process

Manage requirements Balance stakeholder priorities

Collaborate across teams

Develop iteratively, Manage change Demonstrate value iteratively

Model visually, Use component architectures

Elevate the level of abstraction

Continuously verify quality Focus continuously on quality


27

More complete list of practices …

# Practice Name Basic Intermediate Advanced

1 Manage risk.Decide what risk to address in each iteration. Update risk list and make visible.

Use risk management tool and traceability.

2Execute your project in iterations.

Deliver incrementally. Replan based on feedback. Plan iterations based on risk. Use mini- and super-iterations.

3Embrace and manage change.

Do partial implementation. Keep documentation simple.

Use Unified Process lifecycle. Refactor. Manage change.

Automate change management and use CCB.

4Measure progress objectively.

Measure and re-estimate each iteration. Chart progress.

Automate measurements and record in a database.

5 Test your own code.Use coding guidelines and standard.

Developers actively test their own code.

Formally inspect code. Use static, structural, runtime analysis, and performance test tools.

6Leverage test automation appropriately. Provision each test machine. Create automated test suites.

Automate stress and performance testing.


28

List of practices… # Practice Name Basic Intermediate Advanced

7Everyone owns the product!

Openly share info. Evaluate 10% complete work.

Cross-functional collaboration. Assess progress through working code.

Use scalable collaboration platform and enterprise architecture.

8 Understand the domain.Use customer in project, and a glossary. Visualize a domain object model.

Leverage business rules and business process modeling.

9Describe requirements from the user perspective. Identify scenarios.

Capture use cases, and link scenarios to use cases.

Chunk use cases into separately managed requirements.

10Prioritize requirements for implementation.

Prioritize most essential requirements for each iteration.

Balance priorities of architecture, business, and customer.

Systematically manage requirements categories and attributes.

11 Leverage legacy systems.Ensure continuous improvement of systems in maintenance. Plan incremental improvement.

Establish long-term enterprise vision and plans.

12Build high-performance teams.

Clearly communicate project vision and responsibilities.

Establish trust, encourage constructive feedback, and communicate openly.

Couple performance evaluations to established values.

13Organize around the architecture.

Organize around features. Architect oversees architecture.

Organize vertically and horizontally. Approve architectural changes.

Formalize changes through an Architecture Control Board.


29

List of practices. # Practice Name Basic Intermediate Advanced

14 Manage versions.Manage version-controlled files. Manually manage change sets.

Set up isolated workspaces, with activity-based delivery.

Share version-controlled components across products.

15 Leverage patterns.Learn patterns and provide examples.

Use reference architectures and document patterns with UML.

Use pattern automation and enterprise-wide patterns.

16Architect with components and services.

Apply component and service design principles.

Model components, services, and interfaces.

Create detailed component and service specifications.

17 Actively promote reuse.

Common templates/representations, form communities. Educate on available assets. Fund creation of assets.

18 Model key perspectives. Use informal sketching. Document UML architectures. Use model-driven development.

19 Rightsize your processDecide on process to use as you go. Document the process you use.

Improve the process after each iteration.

20Continuously reevaluate what you do.

Each person assesses his or her own working procedure.

Do iteration reviews and retrospectives.

Centrally coordinate process improvement.


30

Principle D: Demonstrate value iteratively

Supporting practices:

Manage risk

Execute your project in iterations

Embrace and manage change

Measure progress objectively


31

Practice: Execute your project in iterations

Traditional Thinking

Requirements detailed up front reduces risk of building wrong product.

Design fully detailed up front avoids building the wrong code.

Fully detailed plans to the end of the project keep the project on track.

Modern Thinking

Early use of critical functionality identifies missing and misunderstood requirements – enables change.

Building and integrating code early validates design ideas, allows design to evolve, and ensures pieces fit.

Change is good – plans should assume change will occur. Avoid detail in downstream iteration plans.


32

Practice: Execute your project in iterations

The practice can be adopted at different levels:

Basic: Deliver incrementally. Replan based on feedback.

Intermediate: Plan iterations based on risk.

Advanced: Use mini- and super-iterations.


TraceabilityCCB

High ceremony








33

Principle B: Balance stakeholder priorities


Understand the domain

Describe requirements from the user perspective

Prioritize requirements for implementation

Leverage legacy systems


34

Practice: Describe requirements from the user perspective


Requirements are defined in terms of features and functions which are decomposed to increasing levels of detail.

List all low level requirements to as much detail as possible

Modern Thinking

Define scenarios or use cases that describe functionality in terms of user goals and steps to reach those goals.

Focus on user needs – details as necessary

Maintain Student Information

Maintain Professor Information

Registrar

You shall jks jadkjhasdkj You shall jksjjadkjhasdk You shall jksjjadkjhasdk You shall jksjjadkjhasdk You shall jksjjadkjhasdk


35

Practice: Describe requirements from a user perspective

Relating use cases, scenarios, and work items

Bruce MacIsaac

Add figure 4.9 from the user requirements practice.


36

Practice: Describe requirements from a user perspective (cont.)

Levels of adoption: Basic: Important scenarios are captured.

Intermediate: Use cases are described and captured in text documents. Key scenarios are identified, but in the context of use cases.

Advanced: Use cases are described and captured in a Requirements Management tool. Each scenario or relevant part of a scenario is captured as a separate requirement. Projects may also have a requirements management plan specifying which types of requirements to use, and for each type, what attributes to use to indicate status, work effort, traceability links to other requirements, test cases, etc.


37

Principle E: Elevate the level of abstraction


Leverage patterns

Architect with components and services

Actively promote reuse

Model key perspectives


38

Practice: Leverage patterns


Each problem is unique, and needs a unique solution.

Reuse is limited to code.

Design is about interfaces and modules.

Modern Thinking

Most problems have been encountered before - solutions can be reused.

Reuse of conceptual solutions.

Capturing key patterns is an important part of design.


39

Practice: Leverage patterns

The practice can be adopted at different levels: Basic: Learn patterns - It is important for developers to be familiar with key

patterns relevant to their field, as basic tools for solving problems and communicating solutions.

Intermediate: Use reference architectures (such as IBM e-business patterns) – these partial solutions can add a lot of value relative to the effort required to use them.

Use UML to document design patterns.

Advanced: Use pattern automation to speed repetitive work and improve consistency.

Apply patterns across the enterprise as part of an enterprise architecture. Create repositories of reusable patterns as part of a reuse program.


40

Principle C: Collaborate across teams


Build high performance teams

Organize around the architecture

Manage versions


41

Principle F: Focus continuously on quality


Test your own code

Leverage test automation appropriately

Everyone owns the product

Iteration 1Iteration 1Test Suite 1Test Suite 1


Iterations 4Iterations 4Test Suite 4Test Suite 4



42

Practice: Everyone Owns the Product


Functional teams of either all analysts, all developers, or …

OK with low-bandwidth communication

Communicate primarily through documents (requirements, design, ...)

Narrow specialists

“That’s not my job”

Modern Thinking

Cross-functional teams consisting of analysts, developers, testers, …

Must have high-bandwidth communication

Communicate through evolving models, tools and face-to-face

Generalists and specialists with bird-eye perspective

“We are all responsible for the application”


43

Practice: Everyone Owns the Product

Level of adoptions:

Basic: Openly share information. Evaluate 10% complete work.

Intermediate: Cross-functional collaboration. Assess progress through working code.

Advanced: Use a scalable collaboration platform.

Create an enterprise architecture and develop organizational expertise.


44

Principle A: Adapt the process


Rightsize your process

Continuously reevaluate what you do

ArtifactsArtifacts

ActivitiesActivitiesActivityActivity

ActivityActivityActivityActivity


45

Agenda





Getting started



46

Choosing which practices to adopt first

Assess your existing process.

Identify problems and root causes.

Identify practices that can help.

Start with basic adoption of a few practices.

Use principles to guide in choosing practices to implement.


47

Example of Practice Adoption Plan

# Practice Name Currently Goal Short-Term Plan

1 Manage risk. Basic Intermediate Key focus. Couple with practice 10.

2 Execute your project in iterations. Intermediate Intermediate N/A

3 Embrace and manage change. Basic AdvancedKey focus. Manage change request more effectively.

4 Measure progress objectively. None Intermediate Not a focus now.

5 Test your own code. Basic Advanced Key focus. Apply test-first design.

6Leverage test automation appropriately. Intermediate Advanced

Good if we can improve. Send Karen on training course.

7 Everyone owns the product! Intermediate Advanced Not a focus now.

8 Understand the domain. Basic IntermediateStart by using a basic domain object model.


48

Levels of Adoption

Most practices can be adopted in a basic way, with low ceremony and low investment and still get much of the value

More advanced versions may require tools, training, and/or greater ceremony suited to larger projects.

Advanced is not the right end goal for all organizations Some advanced levels forces you to be more disciplined, and you may

prefer to stay more agile

Practice x - advancedPractice x - intermediatePractice x - basic

Practice y - advancedPractice y - intermediatePractice y - basic


49

Summary: Using this framework

Decide where your needs are on the process landscape


TraceabilityCCB

High ceremony







Consider which principles and practices you want to focus on

Adopt incrementally

start with the basics

add advanced practices over time if they add value


50

Practices today

IBM Rational Method Composer supports capturing principles and practices

Principles are already defined in current RUP

Practices are a work in progress

Basic level of many practices are being incorporated into OpenUP/Basic

Future vision: call out a broad set of independently adoptable practices in the RUP

align practices to RMC-configurable units


51

Portions of this presentation have been taken from:


52

Agenda





Getting started



53

Features and improvements over RUP 2003 / RPW

Ease of Use

Improved customization

Ability to express Work Breakdown Structures End-to-end processes (delivery

processes)

Process patterns (capability patterns)

Integration with Rational Portfolio Manager Import project plan templates

Link to process guidance from RPM

Export process to MS Project

New look and feel for RUP pages and tree browser

Unified Method Architecture (patents pending) Enables integration and interaction

among methods contents across diverse IT and business domains

Single consolidated terminology across multiple IBM methods

Support for Linux

Translated to nine languages: German, French, Italian, Spanish,

Brazilian Portuguese, Japanese, Simplified Chinese, Traditional Chinese, Korean


54

Rational Method Composer - content

All content provided as ‘Plug-ins’

Plug-ins included in packaged product: RUP

SOA

RSA and RAD

COTS

Systems Engineering

Additional plug-ins made available on an on-demand basis Portfolio Management Method (new)

Websphere Business Modeler (beta)

Additional methods contents, and methods plug-ins are “in-progress” Systems Delivery Method (sourced from SUMMIT Ascendant)

Program Management Method (sourced from SUMMIT Ascendant)

SOA Governance (new)

RUP for Maintenance (new)

Compliance (new)

Business Modeling

J2EE

Legacy Evolution

User Experience Modeling

Asset Based Development

Microsoft .NET

PSM Plug-in for RUP, jointly developed with PSM


55

Content - Out-of-the-Box Processes

Delivery Processes RUP for Small Projects (Small co-located teams) RUP for Medium-sized Projects (Distributed teams) RUP for Large Projects (Large distributed teams) RUP for COTS / Packaged Application Development RUP for Systems Engineering RUP for Maintenance

Capability Patterns RUP for Service-Oriented Architecture (SOA) RUP for Asset-based Development


56

Content for the Enterprise

Program Management Mobilize and plan large to very large program efforts

Portfolio Management Assess portfolios and projects, manage business cases, take continue /

discontinue decisions Business Engineering

Model business goals, existing and future business processes and organizational structure.

Simulation of business process and link to existing or future software assets. Systems Engineering

Develop systems that consists of a combination of software, hardware, and people

Asset-Based Development Asset production, asset consumption and asset portfolio management


57

Questions


58

Per Kroll

Thank You

® IBM Software Group © 2004 IBM Corporation Incremental Adoption of RUP and OpenUP Per Kroll, IBM.

Documents

Transcript of ® IBM Software Group © 2004 IBM Corporation Incremental Adoption of RUP and OpenUP Per Kroll, IBM.