Introduction to EPF Agenda

1. Introduction to EPF Agenda • The EPF Project • OpenUP Overview • SPEM 2.0 – Basic Concepts • Basic Concepts • Advanced Concepts • EPF Composer Introduction Made available under EPL v1.0

2. Introduction to the Eclipse Process Framework Made available under EPL v1.0

3. The EPF Project Made available under EPL v1.0

4. The EPF is a Sub-Project Under the “Technology” Project Test & Performance Tools Platform Business Intelligence and Reporting Tools Tools Non-Java Programming tools Eclipse Modeling Project Web Tools Platform Eclipse Project J2EE Programming tools Technology Data Tools Platform SOA Tools Device Software Development Platform There are a total of Total of 71 projects. 5 proposed projects.http://www.eclipse.org/projects Made available under EPL v1.0

5. The EPF Project: Overview • EPF is an Open Source project within the Eclipse Foundation • The goals of EPF are to provide: • An extensible framework and tooling for authoring, configuring and publishing processes • Exemplary processes - first delivered is OpenUP • EPF Project initiated in January 2006. • EPF is NOT: • Only applicable for Eclipse Java development. • Intended to create the “perfect process” Made available under EPL v1.0

6. The EPF Project: Two Audiences • Process Authors and Coaches (Process Management Team) • Tooling for creating and publishing processes • Foundational process for starting point • Libraries of additional content that can be plugged-in • Process Consumers (Project Team) • Published website of process content for simple browsing • Guidance in the form of checklists, concepts, guidelines • Browse the content adapted to your experience level Made available under EPL v1.0

7. OpenUP Introduction Made available under EPL v1.0

8. What is OpenUP • “An Agile Inspired process with its roots in the UP” • An iterative software development process that is minimal, complete, and extensible • Minimal - Contains vital roles, tasks and guidance • Complete - Complete for small co-located teams • Extensible - Serves as a foundation that can be extended and tailored Made available under EPL v1.0

9. Core Principles OpenUP is based on a set of mutually supporting 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 Made available under EPL v1.0

10. Collaboration: Some key practices • Maintain a common understanding • Key artifacts: Vision, requirements, architecture notebook, 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 • The architecture provides a shared understanding of the solution and forms the basis for partitioning work. Made available under EPL v1.0

11. Evolve: Some key practices • Develop your project in iterations • Use time-boxed iterations that deliver incremental value and provide frequent feedback. • Focus iterations on meeting the next management milestone • Divide the project into phases with clear goals and focus iterations on meeting those goals. • Manage risks • Identify and eliminate risk early. • Embrace and manage change • Adapt to changes. • Measure progress objectively • Deliver working software, get daily status, and use metrics. • Continuously re-evaluate what you do • Assess each iteration and perform process retrospectives. Made available under EPL v1.0

12. Balance: Some key practices • Know your audience & create a shared understanding of the domain. • Identify stakeholders early and establish a common language • Separate the problem from the solution • Understand the problem before rushing into a solution. • Use scenarios and use cases to capture requirements • Capture requirements in a form that stakeholders understand • Establish and maintain agreement on priorities • Prioritize work to maximize value and minimize risk early • Make trade-offs to maximize value • Investigate alternative designs and re-factor to maximize value • Manage scope • Assess the impact of changes and set expectations accordingly. Made available under EPL v1.0

13. Focus: Some key practices • Create the architecture for what you know today • Keep it as simple as possible and anticipate change • Leverage the architecture as a collaborative tool • A good architecture facilitates collaboration by communicating the “big-picture” and enabling parallelism in development. • Cope with complexity by raising the level of abstraction • Use models to raise the level of abstraction to focus on important high-level decisions. • Organize the architecture into loosely coupled, highly cohesive components • Design the system to maximize cohesion and minimize coupling to improve comprehension and increase flexibility. • Reuse existing assets • Don’t re-invent the wheel. Made available under EPL v1.0

14. OpenUP is Agile and Unified • OpenUP incorporates a number of agile practices… • Test-First Design • Continuous Integration • Agile Estimation • Daily Standup, Iteration Assessment, Iteration Retrospective • Self-organizing teams • …within the context of an iterative, incremental lifecycle (UP). Made available under EPL v1.0

15. Core principles mapping to Agile manifesto Made available under EPL v1.0

16. Governance Model – Balancing Agility and Discipline • OpenUP incorporates a three-tiered governance model to plan, execute, and monitor progress. • These tiers correspond to personal, team and stakeholder concerns and each operates at a different time scale and level of detail. Made available under EPL v1.0

17. OpenUP Project Lifecycle • OpenUP uses an iterative, incremental lifecycle. • Proper application of this lifecycle directly addresses the first core principle (Evolve). • The lifecycle is divided into 4 phases, each with a particular purpose and milestone criteria to exit the phase: • Inception: To understand the problem. • Elaboration: To validate the solution architecture. • Construction: To build and verify the solution in increments. • Transition: To transition the solution to the operational environment and validate the solution. Made available under EPL v1.0

18. OpenUP Iteration Lifecycle • Phases are further decomposed into a number of iterations. • At the end of each iteration a verified build of the system increment is available. • Each iteration has its own lifecycle, beginning with planning and ending in a stable system increment, Iteration Review (did we achieve the iteration objectives) and a Retrospective (is there a better process). • Progress on completion of micro-increments is monitored daily via “Scrums” and the iteration burndown chart to provide timely feedback. Made available under EPL v1.0

19. Micro-Increments • Micro-increments are small steps towards the goals of the iteration. • Should be small enough to be completed in a day or two • Identify Stakeholders is a micro-increment (one step of a task). • Determine Technical Approach for Persistency is a micro-increment (a task with a specific focus) • Develop Solution Increment for UC 1 Main Flow is a micro-increment (a task with a specific focus) • Micro-increments are defined and tracked via the work items list. • Work items reference requirements and process tasks as needed to provide required inputs to complete the micro-increment. Made available under EPL v1.0

20. OpenUP Lifecycle WBS Made available under EPL v1.0

21. OpenUP Lifecycle – Inception Phase • The primary purpose of the Inception Phase is to understand the scope of the problem and feasibility of a solution. • More specifically, the objectives and associated process activities are: • At the Lifecycle Objectives Milestone, progress towards meeting these objectives are assessed and a decision to proceed with the same scope, change the scope, or terminate the project is made. Made available under EPL v1.0

22. OpenUP Lifecycle – Elaboration Phase • The primary purpose of the Elaboration Phase is to validate the solution architecture (feasibility and trade-offs). • More specifically, the objectives and associated process activities are: • At the Lifecycle Architecture Milestone, progress towards meeting these objectives are assessed and a decision to proceed with the same scope, change the scope, or terminate the project is made. Made available under EPL v1.0

23. OpenUP Lifecycle – Construction Phase • The primary purpose of the Construction Phase is to develop and verify the solution incrementally. • More specifically, the objectives and associated process activities are: • At the Initial Operational Capability Milestone, progress towards meeting these objectives is assessed and a decision to deploy the solution to the operation environment is made. Made available under EPL v1.0

24. OpenUP Lifecycle – Transition Phase • The primary purpose of the Transition Phase is to deploy the solution to the operational environment and validate it. • More specifically, the objectives and associated process activities are: • At the Product Release Milestone, progress towards meeting these objectives are assessed and a decision to make the product generally available is made. Made available under EPL v1.0

25. OpenUP Disciplines • A discipline is a collection of tasks that are related to a major "area of concern" within the overall project. • Within the lifecycle, tasks are performed concurrently across several disciplines. • Separating tasks into distinct disciplines is simply an effective way to organize content that makes comprehension easier. • OpenUP defines the following Disciplines: Made available under EPL v1.0

26. This discipline consists of 2 tasks and 17 guidance elements. Primary Roles: Architect Associated Work Products: Architecture Notebook Architecture Discipline Made available under EPL v1.0

27. This discipline consists of 2 tasks and 9 guidance elements. Primary Roles: Any Role Developer Associated Work Products: None Configuration and Change Management Discipline Made available under EPL v1.0

28. This discipline consists of 4 tasks and 18 guidance elements. Primary Roles: Developer Associated Work Products: Build Design Developer Test Implementation Development Discipline Made available under EPL v1.0

29. This discipline consists of 4 tasks and 17 guidance elements. Primary Roles: Project Manager Associated Work Products: Iteration Plan Project Plan Risk List Work Items List Project Management Discipline Made available under EPL v1.0

30. This discipline consists of 3 tasks and 21 guidance elements. Primary Roles: Analyst Associated Work Products: Glossary Supporting Requirements Specification Use Case Use-Case Model Vision Requirements Discipline Made available under EPL v1.0

31. This discipline consists of 3 tasks and 7 guidance elements. Primary Roles: Tester Associated Work Products: Test Case Test Log Test Script Test Discipline Made available under EPL v1.0

32. OpenUP Roles • Roles define a set of related skills, competencies and responsibilities. • OpenUP defines the following Roles: Made available under EPL v1.0

33. Analyst Role • The person in this role represents customer and end-user concerns by gathering input from stakeholders to understand the problem to be solved and by capturing and setting priorities for requirements Made available under EPL v1.0

34. Any Role Role • Anyone on a team can fill this role of performing general tasks. Made available under EPL v1.0

35. Architect Role • This role is responsible for defining the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project. Made available under EPL v1.0

36. Developer Role • This role is responsible for developing a part of the system, including designing it to fit into the architecture, possibly prototyping the user-interface, and then implementing, unit-testing, and integrating the components that are part of the solution. Made available under EPL v1.0

37. Project Manager Role • Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives. Made available under EPL v1.0

38. Stakeholder Role • This role represents interest groups whose needs must be satisfied by the project. It is a role that may be played by anyone who is (or potentially will be) materially affected by the outcome of the project. Made available under EPL v1.0

39. Tester Role • This role is responsible for the core activities of the test effort. Those activities include identifying, defining, implementing, and conducting the necessary tests, as well as logging the outcomes of the testing and analyzing the results. Made available under EPL v1.0

40. A Typical Task Description • Tasks typically have an associated concept, guideline and checklist. • If one needs to perform a task • one reads the concept to understand the context, • reads the steps to determine what needs to be done, • reads the guideline to determine how to do it, • then reads the checklist to validate completion. Made available under EPL v1.0

41. A Typical Artifact Description • Typically artifacts have associated templates and checklists. • The template provides additional guidance on completing the artifact and • The checklist helps check the quality of the resulting artifact. Made available under EPL v1.0

42. Some Key Practices from OpenUP Made available under EPL v1.0

43. 3 Levels of Planning Made available under EPL v1.0

44. Level 1 – Project Plan • The Project Plan provides a course grain plan to complete. • Time-scale of months. • Defines number of iterations (initial estimate) and major milestones • Main artifacts: Project Plan Your goal is to find a Path fromHere to There Project Starting Point Stakeholder Satisfaction Space Made available under EPL v1.0

45. Divide One Big Problem into a Series of Smaller Problems (Iterations) Initial Project Plan Iterations Planned Completion 3 5 6 2 4 1 Planned Path Stakeholder Satisfaction Space Made available under EPL v1.0

46. Define When Key Milestones Can Be Achieved Planned Completion 3 5 6 2 4 1 Planned Path Elaboration Construction Inception Do we understand the problem? (LCO) Transition Stakeholder Satisfaction Space Do we understand the solution? (LCA) Release ready? (PR) Feature complete? (IOC) Made available under EPL v1.0

47. Level 2 – Iteration Plan • The Iteration Plan provides a fine grain plan for an iteration. • Time-scale of weeks. • Defines number of work items to complete in this iteration. • Main artifacts: Iteration Plan, Work Item 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 Made available under EPL v1.0

48. 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. Made available under EPL v1.0

49. Plan Your Iteration Iteration Plan • 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 Made available under EPL v1.0

50. Level 3 - Creating a Solution for a Work Item • Select a work item assigned to the current iteration • Collaborate with team if it needs breakdown • Time-scale of days • 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 Made available under EPL v1.0