1

OpenUP Distilled

Per KrollMgr. of Methods

IBMpkroll@us.ibm.com

Brian LyonsCTO

Number Six Softwareblyons@numbersix.com

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

Brian Lyons - Background• Content Lead, OpenUP/Basic Process; Committer,

Eclipse Process Framework

• Chief Technology Officer – Number Six Software

• Co-Founder – Number Six Software

• (Co-) Author of – UML 2 Toolkit

4

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

5

Eclipse Process Framework (EPF) Project

Provide an open and collaborative ecosystem for evolving software development processes

Provide sample practices, process tooling and a metamodel, 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

OpenUP/Basic

Scrum

Value-BasedSoftware Eng.Value-Based

Software Eng.Model-DrivenArchitecture

Model-DrivenArchitecture

Open Unified Process (OpenUP)

Consolidated Agile Framework

• XP

• Scrum

Other agile processes

• DSDM

• AMDD

7

What Is OpenUP/Basic?

An iterative software development process that is minimal, complete, and extensible.

• 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

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

9

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

10

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

11

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

12

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

13

penUP

Analyst

Stakeholder

Project Manager

Architect

Developer

Tester

14

OpenUP is on a set of core principles:• Collaborate to align interests and share

understanding• Evolve to continuously obtain feedback and

improve • Balance competing priorities to maximize

stakeholder value• Focus on articulating the architecture

Principles

15

Demo

16

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

17

Collaboration: Some key practices• Maintain a common understanding

– Key artifacts: Vision, requirements, architecture, iteration plan

• Foster a high-trust environment– Manage by intent, tear down walls, understand the perspectives

of others

• Share responsibility– Everybody owns the product, help each other

• Learn continuously– Develop technical and interpersonal skills, be a student and a

teacher

• Organize around the architecture– As teams grow in size, have teams of small component teams

18

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

19

Forms of Requirements

• Vision defines stakeholder’s view of product• Use Cases define user scenarios

– Any scenario-based requirements would do

• Supporting Requirements cover technical and other non-usage issues

• Work Items reference requirement work products for more detail

20

Iterative Requirements Definition

• Vision defines product• Use-case identification scopes release• Use-case detail drives work in an iteration• Supporting requirements are managed across

the lifecycle

21

Test Cases as Intent

• Test Case– Aligned with requirements and bugs– Specifies the conditions to be validated– Outlines necessary data

• Contrasted with Test Script (from Solution sub-process)– Aligned with Test Cases– Explicit step-by-step instructions– Supplemented by test data– Best if automated

• Test Cases are a form of Test First Design (TFD)

22

Roles Relevant to Intent

• Analyst– Captures, organizes, and prioritizes requirements

• Stakeholder– Drives Intent; needs must be satisfied by the project

• Tester– Defines criteria for acceptance of solution

• The Project Manager will update the Work Items List with prioritized, grouped items

• The Architect and Developer will produce a solution that meets the intent

23

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

24

Stakeholder Satisfaction Space

Project Starting Point

Identify End Goal

Your goal is to find a Path fromHere to There

25

Stakeholder Satisfaction Space

Divide One Big Problem into a Series of Smaller Problems

1 2 3 4 5 6

Initial

Project Plan

Planned Planned CompletionCompletion

Planned Planned CompletionCompletion

Planned Path

26

Stakeholder Satisfaction Space

Define When Key Management Can Be Achieved

1 2 3 4 5 6

Do we understand

the problem?

Do we understand

the solution?Feature

complete?

Release ready?

Planned Planned CompletionCompletion

Planned Planned CompletionCompletion

Planned Path

Inception Elaboration ConstructionTransition

27

Prioritize and Manage Work: Work Items List

Work Item List

High Priority

Low Priority

New work items can be added at any time

Work items can be removed at any time

Work items can be reprioritized at any time

High-priority work itemsshould be well-defined

Low-priority work itemscan be vague

Each iteration implements thehighest-priority work items

28

Key Concepts: Agile Estimation

• Size (points): – For each work item, we estimate how big it is. We

focus on relative size, so key is to be consistent within your work items list.

• Velocity– A measurement of how many points are delivered in

each iteration

• Effort (days or hours):– Estimate of actual effort.

29

Plan Your Iteration

• Specify target velocity and outline iteration objectives in iteration plan

• Analyze top priority Work Item – Estimate effort in hours– If too big to fit within iteration, break down into smaller work items– Add to Iteration Plan– Analyze next work item in priority order until Iteration Plan is “full”

• Specify test and other assessment criteria

Work Item List

•Iteration objectives•Iteration Work Item List•Measure / test results

Estimate and add to iteration plan

Iteration Plan

30

Planned Path

Use Iteration Assessments to Change Direction

Actual Path

1 2 3 4 5 6

1 2 34

5 67Updated

Project Plan

Planned Planned CompletionCompletion

Planned Planned CompletionCompletion

Stakeholder Satisfaction Space

31

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

32

The Role of Architecture

• Provides context to design and implementation• Provides risk mitigation• Improves predictability of plan• Setup early, improve and evolve

33

Architecture and the Principles

• Collaborate– Maintain a common technical understanding with architecture

• Balance– The decisions of architecture are part of balancing to achieve

maximum stakeholder benefits within constraints

• Focus– Emphasize essential technical decisions via architecture

• Evolve– Early evolutions ensure product feasibility and attack risk

34

• We are going to use the Chain of Responsibility Pattern to blah

• We have selected Oracle because it will meet the performance requirements and the customer already has licenses and trained DBAs

• We are going to apply a network architecture like this.• We are applying these J2EE Blueprints• We are going to distribute the components across the

layers this way.

Representing Architecture

• No thick document required• Much of the architecture can be

– Selected instead of designed– Referenced instead of described

35

Designing

• Steps– Understand requirements, identify a scenario– Identify elements– Determine how elements collaborate– Refine decisions, design internals– Communicate

• Do an analysis pass? If appropriate.• Visually design? If appropriate.• Use a design tool? If appropriate.• Long-lived design? If appropriate.

36

Creating a Solution for a Work Item

• Select a work item assigned to the current iteration

• Collaborate with team if it needs breakdown• Identify requirements closure

– Attachments: use case, supporting requirement, bug information, test case

– Gather additional information

• Repeat until complete– Build a small solution verified with developer tests

• Verify completion with system tests

37

Test-first Design

• Design solution– Defines interface to be tested

• Create test for solution– Completed test should run and fail

• Implement solution– Test should run and pass

• In as small of increments as possible

38

Inserting Test-first Design

• Developer testing straddles the implementation of the solution

• The tight back-looping is not shown here

Refinethe ArchitectureRefinethe Architecture

Designthe SolutionDesignthe Solution

ImplementDeveloper TestsImplementDeveloper Tests

Implementthe SolutionImplementthe Solution

RunDeveloper TestsRunDeveloper Tests

39

Roles Relevant to Solution

• Developer– Designs and implements solution

• Architect– Makes key technical decisions and structures the

solution

• Tester– Implements and conducts tests to verify solution

• The Project Manager monitors the development

• The Stakeholder participates in verification of solution

• The Analyst provides additional information

40

Agenda

• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary

41

Adopting the Process

• To browse– Download published process from eclipse

• To configure and customize– Download source library and EPF Composer tool

• Use EPF Composer tool to author extensions– Replace existing templates– Add guidelines on specific techniques– Add tool mentors for usage of your tools– Extend or add roles, tasks, work products, examples, etc.

• Publish your custom configuration

http://www.eclipse.org/epf/downloads/downloads.php

42

Questions?

??

?

?

?

?

?

?

43

44

Example: Iterations in Practice

• Let’s assume ~6 week iteration length:– 1 wk planning, analysis & design– 3-4 wks design and coding– 1-2 weeks testing/shutdown

• Many team members may do design and coding also the first week• Weekly Integration builds used to prove progress; nightly builds used to

inject discipline and repeatability• High level themes and target artifacts for each iterations decided by Dev

Leads based on business and use case scenarios• Detailed iteration plans provided by component teams (linking line items to

use cases and scenarios)• Iteration builds get assessed against use cases and are published for

broader visibility• Content matters - inject cool stuff into each planned iteration to ensure

adoption of, and progression through each iteration build• Dates matter – revisit following each iteration delivery. • Iterations are timeboxed. (Phases are not.)

This, and next two slides borrows content from development leads for IBM Rational Software Architect / Julian Jones

45

Practical Lessons

• It is easy, even tempting to slip function from iteration to iteration; this inevitably results in a crunch as one nears release

• Taking shortcuts on the 1-2 week shutdown period will lead to poor stability• Adoption rate is significantly affected by the stability of the iteration and by

ease of download• There’s a tendency not to properly document new functions going into each

iteration; this makes it difficult to establish what is new and exciting• To grow a community of adopters it’s essential to have good iterations early

on which are exciting so that people jump on them and provide active feedback; only with attractive iterations can one get more than one feedback cycle per release

• In order to foster direct interactions with early adopters one needs open source style communication channels. Tech support firewalls are a bane

• The iteration assessment planning needs to be done carefully to allow proper scaffolding of code to prevent gridlock

• As function falls out of the release (not that this every happens), product teams need to be re-engaged so that schedule slippage is dealt with realistically