OpenUP Distilled

1. OpenUP Distilled Per Kroll Mgr. of Methods IBM pkroll@us.ibm.com Brian Lyons CTO Number Six Software blyons@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. EXTENSIONS EXTENSIONS EXTENSIONS EXTENSIONS Project Mgmt. Project Mgmt. • • Project Mgmt. Project Mgmt. • • Oper. Mgmt. Oper. Mgmt. • • Oper. Mgmt. Oper. Mgmt. • • Systems Mgmt. Systems Mgmt. • • Systems Mgmt. Systems Mgmt. • • EPF Ecosystem Inhouse Inhouse Inhouse Inhouse Free Process Free Process Free Process Free Process Content Content Content Content Content Content Content Content Plug Plug - - ins ins Plug Plug - - ins ins Plug Plug - - ins ins Plug Plug - - ins ins Open Unified Process (OpenUP) Commercial Commercial Commercial Commercial Process Process Process Process Value-BasedSoftware Eng. Model-DrivenArchitecture Content Content Content Content Plug Plug - - ins ins Plug Plug - - ins ins OpenUP/Basic Consolidated Agile Framework Other agile processes Basic Unified Basic Unified Process Process • DSDM • XP Adapted from RUP Adapted from RUP Scrum Scrum Scrum • AMDD • Scrum Tool Tool Tool Tool Extensions Extensions Extensions Extensions Extensible, Customizable, Flexible Extensible, Customizable, Flexible TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing) Extensible, Customizable, Flexible Extensible, Customizable, Flexible TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing) Common Language & Vocabulary Common Language & Vocabulary META MODEL (Unified Method Architecture) META MODEL (Unified Method Architecture) Common Language & Vocabulary Common Language & Vocabulary META MODEL (Unified Method Architecture) META MODEL (Unified Method Architecture) ECLIPSE ECLIPSE Open Source Development Open Source Development ECLIPSE ECLIPSE Open Source Development Open Source Development

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. Analyst Stakeholder Tester Developer Project Manager Architect penUP

9. Analyst Stakeholder Tester Developer penUP Project Manager Architect

10. Analyst Stakeholder Tester Developer penUP Project Manager Architect

11. Analyst Stakeholder Tester Developer penUP Project Manager Architect

12. Analyst Stakeholder Tester Developer penUP Project Manager Architect

13. Analyst Stakeholder Tester Developer penUP Project Manager Architect

14. 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

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. Identify End Goal Your goal is to find a Path fromHere to There Project Starting Point Stakeholder Satisfaction Space

25. Initial Project Plan Divide One Big Problem into a Series of Smaller Problems Planned Completion 3 5 6 2 4 1 Planned Path Stakeholder Satisfaction Space

26. Elaboration Inception Construction Transition Define When Key Management Can Be Achieved Planned Completion 3 5 6 2 4 1 Planned Path Do we understand the problem? Do we understand the solution? Release ready? Feature complete? Stakeholder Satisfaction Space

27. Prioritize and Manage Work: Work Items List Each iteration implements the highest-priority work items High Priority 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

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. Iteration Plan 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 Work Item List

30. 1 2 3 4 7 Updated 5 6 Project Plan Use Iteration Assessments to Change Direction Planned Completion 3 5 6 2 4 1 Planned Path Actual Path 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. Refine the Architecture Design the Solution Implement Developer Tests Implement the Solution Run Developer Tests Inserting Test-first Design • Developer testing straddles the implementation of the solution • The tight back-looping is not shown here

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? ? ? ? ? ? ? ? ?

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