Incremental Adoption of RUP and OpenUP Per Kroll, IBM

1. Incremental Adoption of RUP and OpenUPPer Kroll, IBM

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. 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 Agile “Box” Basic Unified Basic Unified OPEN Process Framework Process Process • DSDM • XP Adapted from RUP Adapted from RUP 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? 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 Ecosystem Co-developers Supporters

9. New! What’s In IBM Rational Method Composer vs. EPF? CONTENT TOOLS Method authoring Plug-ins / content exchangePublishing Web-based viewing Authoring Work Breakdown Str. Auth. Organizational Breakdown Str. Auth. Product Breakdown Str. Capability Patterns Iterative and agile development Low-ceremony process guidance Process followed by Eclipse team Process similar to XP EPFOpenSource

10. New! New! What’s In IBM Rational Method Composer vs. EPF? CONTENT IBM RationalMethod ComposerCommercial (includes all EPF content and tooling) Business modeling and simulation Program & portfolio mgmt SOA Governance SOA for the enterprise ISO and CMMI compliance Large scale and distributed dev Systems Engineering Rational tool-specific guidance Business modeling Asset production and reuse TOOLS RPM Integration Advanced authoring Import of existing RUP contentImproved page layout MyRUPProcess Advisor Method authoring Plug-ins / content exchangePublishing Web-based viewing Authoring Work Breakdown Str. Auth. Organizational Breakdown Str. Auth. Product Breakdown Str. Capability Patterns Iterative and agile development Low-ceremony process guidance Process followed by Eclipse team Process similar to XP EPFOpenSource

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.

12. 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)

13. The process landscape – variation in process needs Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony Iterative Risk drivenContinuous integration and testing From: Rational Unified Process Made Easy, by Kroll/Kruchten. Addison-Wesley

14. Definitions “The ability to rapidly respond to risks, changing requirements or stakeholders needs, or other changes impacting the application we are building” Larman 2004 Agility Work that comes between stakeholder needs and building the application. This includes formal documentation, reviews, presentations, gathering metrics, traceability, investing in reuse, and so on. Discipline Iteration length, which is a primary driver of how fast you get feedback on what project activities produced expected results. Iterative Choose the right level of ceremony and iteration length to achieve agility

15. Where Do You Want to Be? Waterfall Few risk, sequential Late integration and testing • 6 distributed people,poor CM environment Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony • 20 people,safety-criticalsystem • 3 co-located people,known technology Iterative Risk drivenContinuous integration and testing From: Rational Unified Process Made Easy, by Kroll/Kruchten

16. Sweet spot Where Do You Want to Be? Waterfall Few risk, sequential Late integration and testing • 6 distributed people,poor CM environment Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony • 20 people,safety-criticalsystem • 3 co-located people,known technology Iterative Risk drivenContinuous integration and testing From: Rational Unified Process Made Easy, by Kroll/Kruchten

17. Some Agile Processes Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony SCRUM Adaptive Development XP Iterative Risk drivenContinuous integration and testing

18. Adopting RUP is primarily about adherence to a set of key principles, not following a set of activities or producing a set of artifacts Too Common RUP “Misusage” Waterfall Few risk, sequential Late integration and testing X Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony ? ? 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. Iterative Risk drivenContinuous integration and testing

19. Rational Unified Process Framework Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony RUP Process Framework Large, more formal RUP Config. Average RUP Config. Light RUP Config. Iterative Risk drivenContinuous integration and testing

20. Agenda • What is OpenUP and EPF? • The process landscape – variation in process needs • Principles and practices – what are they? • RUP’s principles and practices • Getting started • Latest news on RUP / RMC (if time permits)

21. 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 Principles and Practices Practice 1.1 Practice 1.2 Practice 1.3 Practice … Principle 1 Principle 2 Principle 3 Principle … Practice 2.1 Practice 2.2 Practice 2.3 Practice … Practice 3.1 Practice 3.2 Practice 3.3 Practice …

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

23. Agenda • What is OpenUP and EPF? • The process landscape – variation in process needs • Principles and practices – what are they? • RUP’s principles and practices • Getting started • Latest news on RUP / RMC (if time permits)

24. Universal principles – the basis of RUP These principles are the basis for RUP practices.

25. What happened to the 6 “best practices”? RUP is expanding to cover a broader space – portfolio management, enterprise architecture …. The new principles provide more coverage.

26. More complete list of practices …

27. List of practices…

28. List of practices.

29. Principle D: Demonstrate value iteratively Supporting practices: • Manage risk • Execute your project in iterations • Embrace and manage change • Measure progress objectively

30. 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. Practice: Execute your project in iterations

31. Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony Iterative Risk drivenContinuous integration and testing 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.

32. Principle B: Balance stakeholder priorities Supporting practices: • Understand the domain • Describe requirements from the user perspective • Prioritize requirements for implementation • Leverage legacy systems

33. Traditional Thinking 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 Professor Information Registrar Maintain Student Information • You shall jks jadkjhasdkj • You shall jksjjadkjhasdk • You shall jksjjadkjhasdk • You shall jksjjadkjhasdk • You shall jksjjadkjhasdk Practice: Describe requirements from the user perspective

34. Practice: Describe requirements from a user perspective Relating use cases, scenarios, and work items

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

36. Principle E: Elevate the level of abstraction Supporting practices: • Leverage patterns • Architect with components and services • Actively promote reuse • Model key perspectives

37. Traditional Thinking 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. Practice: Leverage patterns

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

39. Principle C: Collaborate across teams Supporting practices: • Build high performance teams • Organize around the architecture • Manage versions

40. Principle F: Focus continuously on quality Supporting practices: • Test your own code • Leverage test automation appropriately • Everyone owns the product Iteration 1Test Suite 1 Iteration 2Test Suite 2 Iteration 3Test Suite 3 Iterations 4Test Suite 4

41. Traditional Thinking 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” Practice: Everyone Owns the Product

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

43. Activities Activity Activity Activity Artifacts Principle A: Adapt the process Supporting practices: • Rightsize your process • Continuously reevaluate what you do

44. Agenda • What is OpenUP and EPF? • The process landscape – variation in process needs • Principles and practices – what are they? • RUP’s principles and practices • Getting started • Latest news on RUP / RMC (if time permits)

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

46. Example of Practice Adoption Plan

47. Levels of Adoption Practice x - advanced Practice x - intermediate Practice x - basic • 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 y - advanced Practice y - intermediate Practice y - basic

48. Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony Iterative Risk drivenContinuous integration and testing Summary: Using this framework • Decide where your needs are on the process landscape • 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

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

50. Portions of this presentation have been taken from: