OpenUP Distilled
Per Kroll
Mgr. of Methods
IBM
pkroll@us.ibm.com
Brian Lyons
CTO
Number Six Software
blyons@numbersix.com
1
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
2
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
3
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
4
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
5
EPF Ecosystem
Inhouse
Content
Plug-ins
EXTENSIONS
• Project Mgmt.
Free Process
Content
Plug-ins
• Oper. Mgmt.
• Systems Mgmt.
Open Unified Process (OpenUP)
Value-Based
Software Eng.
Commercial
Process
Model-Driven
Architecture
OpenUP/Basic
Basic
Unified
Process
Content
Plug-ins
Consolidated Agile
Framework
Adapted
Adapted from
from RUP
RUP
Scrum
Other agile processes
• XP
• DSDM
• Scrum
• AMDD
Extensible, Customizable, Flexible
TOOLING (Authoring, Publishing)
Common Language & Vocabulary
META MODEL (Unified Method Architecture)
Tool
Extensions
6
Open Source Development
ECLIPSE
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
7
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
8
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
9
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
10
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
11
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
12
Analyst
Stakeholder
Tester
Developer
Project
Manager
penUP
Architect
13
Principles
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
14
Demo
15
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
16
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
17
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
18
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
19
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
20
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)
21
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
22
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
23
Identify End Goal
Your goal is to find a Path from
Here to There
Project Starting Point
Stakeholder
Satisfaction Space
24
Divide One Big Problem into a
Series of Smaller Problems
Planned
Completion
1
2
3
4
5
6
Planned Path
Initial
Stakeholder
Satisfaction Space
Project Plan
25
Define When Key
Management Can Be
Achieved
Planned
Completion
1
3
2
4
5
6
Planned Path
Inception
Do we
understand
the problem?
Elaboration
Do we
understand
the solution?
Construction
Transition
Release
Feature
complete? ready?
Stakeholder
Satisfaction Space
26
Prioritize and Manage Work:
Work Items List
High Priority
Each iteration implements the
highest-priority work items
High-priority work items
should be well-defined
New work items can be
added at any time
Work items can be
reprioritized at any time
Low-priority work items
can be vague
Work items can be
removed at any time
Low Priority
Work Item List
27
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.
28
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
Estimate and add
to iteration plan
•Iteration objectives
•Iteration Work Item List
•Measure / test results
Iteration Plan
29
Work Item List
Use Iteration Assessments to Change
Direction
Planned
Completion
2
1
3
4
5
6
Planned Path
1
Updated
2
3
Actual Path
4
5
6
7 Stakeholder
Satisfaction Space
Project Plan
30
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
31
The Role of Architecture
•
•
•
•
Provides context to design and implementation
Provides risk mitigation
Improves predictability of plan
Setup early, improve and evolve
32
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
33
Representing Architecture
• No thick document required
• Much of the architecture can be
– Selected instead of designed
– Referenced instead of described
• 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.
34
Designing
• Steps
–
–
–
–
–
•
•
•
•
Understand requirements, identify a scenario
Identify elements
Determine how elements collaborate
Refine decisions, design internals
Communicate
Do an analysis pass?
Visually design?
Use a design tool?
Long-lived design?
If appropriate.
If appropriate.
If appropriate.
If appropriate.
35
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
36
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
37
Inserting Test-first Design
• Developer testing
straddles the
implementation of the
solution
• The tight back-looping
is not shown here
Refine
the Architecture
Design
the Solution
Implement
Developer Tests
Implement
the Solution
Run
Developer Tests
38
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
39
Agenda
•
•
•
•
•
•
What is OpenUP?
Collaboration
Intent
Management
Solutions Development
Summary
40
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
41
http://www.eclipse.org/epf/downloads/downloads.php
Questions?
?
?
?
?
?
?
?
?
42
43
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
44
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
45