1 OpenUP Distilled Per Kroll Mgr. of Methods IBM Brian Lyons CTO Number Six 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 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) Free Process Content Plug-ins Free Process Content Plug-ins META MODEL (Unified Method Architecture) ECLIPSE Commercial Process Content Plug-ins Commercial Process Content Plug-ins Tool Extensions Tool Extensions Extensible, Customizable, Flexible Common Language & Vocabulary Open Source Development Inhouse Content Plug-ins Inhouse Content Plug-ins Basic Unified Process Adapted from RUP Basic Unified Process Adapted from RUP Scrum TOOLING (Authoring, Publishing) Free Process Content Plug-ins Free Process Content Plug-ins META MODEL (Unified Method Architecture) ECLIPSE Commercial Process Content Plug-ins Commercial Process Content Plug-ins Tool Extensions Tool Extensions Extensible, Customizable, Flexible Common Language & Vocabulary Open 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-Based Software Eng. Model-Driven Architecture 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 from Here to There

25 Stakeholder Satisfaction Space Divide One Big Problem into a Series of Smaller Problems Initial Project Plan Planned Completion Planned Path

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

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 items should be well-defined Low-priority work items can be vague Each iteration implements the highest-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 Updated Project Plan Planned Completion 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 Refine the Architecture Design the Solution Implement Developer Tests Implement the Solution Run Developer 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

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