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

2
Introduction to the Eclipse Process Framework
3
The EPF Project
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

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

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

7
OpenUP Introduction
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

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

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.

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.

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.

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
• Dont re-invent the wheel.

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

15
Core principles mapping to Agile manifesto
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.

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.

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.

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.

20
OpenUP Lifecycle WBS
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.

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.

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.

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.

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

26
Architecture Discipline

• This discipline consists of 2 tasks and 17
  guidance elements.
• Primary Roles
• Architect
• Associated Work Products
• Architecture Notebook

27
Configuration and Change Management Discipline

• This discipline consists of 2 tasks and 9
  guidance elements.
• Primary Roles
• Any Role
• Developer
• Associated Work Products
• None

28
Development Discipline

• This discipline consists of 4 tasks and 18
  guidance elements.
• Primary Roles
• Developer
• Associated Work Products
• Build
• Design
• Developer Test
• Implementation

29
Project Management Discipline

• 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

30
Requirements Discipline

• 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

31
Test Discipline

• This discipline consists of 3 tasks and 7
  guidance elements.
• Primary Roles
• Tester
• Associated Work Products
• Test Case
• Test Log
• Test Script

32
OpenUP Roles

• Roles define a set of related skills,
  competencies and responsibilities.
• OpenUP defines the following Roles

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

34
Any Role Role

• Anyone on a team can fill this role of performing
  general tasks.

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.

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.

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.

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.

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.

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.

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.

42
Some Key Practices from OpenUP
43
3 Levels of Planning
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
45
Divide One Big Problem into a Series of Smaller
Problems (Iterations)
Iterations
Planned Completion
3
5
6
2
4
1
Planned Path
Stakeholder Satisfaction Space
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)
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
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.

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

51
Assessments

• OpenUP promotes daily stand-up meetings to track
  day-day progress.
• An Iteration Assessment is conducted at the end
  of each iteration to determine if objectives have
  been achieved.
• Main input to iteration assessment is a working
  prototype (Artifact Build)
• Project Burndown and Iteration Burndown charts
  based on Work Item List used to monitor progress
• Retrospective conducted at the end of each
  iteration to assess the process

52
Use Iteration Assessments to Change Direction
Planned Completion
3
5
6
2
4
1
Planned Path
Actual Path
Stakeholder Satisfaction Space
53
Forms of Requirements

• Vision defines stakeholders view of product
• Use Cases define user scenarios
• Any scenario-based requirements would do
• Defines consistent set of requirements for an
  increment of the system
• Supporting Requirements cover technical and other
  non-usage issues
• Work Items reference requirement work products
  for more detail

54
Iterative Requirements Development

• Vision defines product
• Use-case identification scopes release
• Use-case detail drives work in an iteration
• Supporting requirements are managed across the
  lifecycle
• OpenUP promotes a breadth-before-depth, approach
  to requirements development
• Identify use cases (name and brief desc only).
• Prioritize use cases
• Detail main scenario of high priority use case
• Implement and verify
• Detail alternate scenarios of same use case or
  main scenario of another use case
• This is accomplished by iterative application of
  tasks Find and Outline Requirements and Detail
  Requirements for each increment.

55
Test Cases

• Test Case
• Aligned with requirements
• Specifies the conditions to be validated
• Outlines necessary data
• Contrasted with Test Script
• 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)

56
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

57
Test-first Design

• Developer testing straddles the implementation of
  the solution
• Unit Test
• Integration Test
• Continuous integration built into the process.

58
Continuous Integration

• Team members integrate their work with
  completed Change Sets from other developers, and
  test the application, before making their work
  available to others.
• This results in early detection of errors, while
  the work is still fresh in the minds of
  developers.
• OpenUP incorporates Continuous integration into
  the process and provides guidance that describe
  CI, outline the benefits, and provide tips for
  effective CI.
• For more information see
• Concept Continuous Integration
• Guideline Continuous Integration
• A very good description of CI may be found at
• http//www.martinfowler.com/articles/continuousInt
  egration.html

59
SPEM 2.0

• ...by relieving the brain of all unnecessary
  work, a good notation sets it free to concentrate
  on more advanced problems, and in effect,
  increases the mental power of the race.

Alfred North WhiteheadBritish mathematician,
logician and philosopher
60
EPF uses SPEM 2.0

• SPEM Software Process Engineering Meta-model
• Although the title implies Software Processes,
  any process can be represented using SPEM.

61
Basic Concepts Method Library

• Method Library
• All Method Elements are stored in a Method
  Library
• Method Plug-in
• A Method Plug-in represents a physical container
  for Method Packages and Process Packages. It
  defines a largest granularity level for the
  modularization and organization of method content
  and processes.
• Method Configuration
• a logical subset of a Method Library
• Delivery Process
• a complete and integrated approach for performing
  a specific type of project.

OpenUP Library
DSDM Plug-in for OpenUP
extends
OpenUP Plug-in
depends on
Base Concepts Plug-in
62
Basic Concepts - Method Library

• Libraries contain
• Method plug-ins
• Configurations
• The OpenUP library has
• Three method plug-ins
• base_concepts
• dsdm_openup
• openup
• Two delivery processes
• Openup_DSDM
• openup_lifecycle
• Two configurations
• OpenUP
• OpenUPDSDM

63
Basic Concepts Method Content, Process

• Method Content (Who, What, Why, How)
• Highly re-useable information
• Definition of Roles, Tasks, Work Products and
  associated relationships
• Includes Guidance and Categories
• No timing information

• Process (When)
• End-End sequence of Phases, Iterations,
  Activities and Milestones that define the
  development lifecycle.
• Defines When tasks are performed via Activity
  Diagrams and/or Work Breakdown Structures

64
SPEM 2.0

• Method Content

65
Basic Concepts - Role

• Roles define a set of related skills,
  competencies and responsibilities.
• Roles are not individuals
• Individuals on the development team may play
  multiple roles.
• Roles Perform Tasks
• Roles are Responsible for Work Products.

66
Basic Concepts Work Product

• Work Products (in most cases) represent the
  tangible things used, modified or produced by a
  Task.
• Roles use Work Products to perform tasks and
  produce Work Products in the course of performing
  tasks.
• Work Products are the responsibility of a Role.
• There are three types of work products
• Artifact typically a configuration managed item
• Deliverable required customer/stakeholder
  deliverable
• Outcome intangible result of a task such as an
  installed server or tool.

67
Basic Concepts - Task

• A Task defines an assignable unit of work
  (usually a few hours to a few days in length).
• Tasks are performed by Roles (one primary, and
  optionally additional supporting roles).
• Tasks have a clear purpose, and provide
  step-by-step descriptions of the work that needs
  to be done to achieve the goal.
• Tasks modify or produce Work Products.
• Tasks do not define when they are performed in
  the lifecycle.

68
Basic Concepts - Guidance
Types of Guidance Checklist Concept
Example Guideline Estimate Considerations
Practice Report Reusable Asset Roadmap
Supporting Material Template Term
Definition Tool Mentor Whitepaper

• Guidance may be associate with Roles, Tasks, and
  Work Products.
• Different types of Guidance depending upon
  purpose.
• Use Guidance for detailed methodology and
  supporting information. This will simplify
  tailoring.
• For example, Tasks should tell you what needs
  to be done, Guidelines provide detailed how to.

69
Basic Concepts Guidance ExamplesHmmmso I need
to plan the project?
Whats Agile Estimation?
What should be in the Project Plan?
Walk me through planning?
Show me an example.
Did I forget anything?
70
Basic Concepts - Categories

• Categories
• Used to group related method elements.
• There are 5 Standard Categories
• Discipline grouping of related tasks
• Domain grouping of related WP
• Work Product Kind similar to Domain
• Role Set Grouping of related Roles
• Tool Grouping of Tools
• Categories may be nested
• You can define your own Custom Categories
• Elements can be categorized via their property
  editor, or via Category properties.
• Used to build views in published website (we will
  see this later).

71
SPEM 2.0

• Process Content

72
Basic Concepts Capability Patterns

• Capability Patterns define the sequence of
  related Tasks, performed to achieve a greater
  purpose.
• Task can be specialized for the given context
  (ex. suppress steps, work products)

Task Descriptor (instance of Task)
Role Descriptor (instance of a Role)
Work Product Descriptor (instance of a WP)
73
Basic Concepts Capability Patterns

• Capability Patterns may be nested and viewed
  graphically
• An Activity is an instance of a Capability
  Pattern.

Activity (instance of a capability pattern)
74
Basic Concepts Delivery Process

• Defined using Work Breakdown Structures and/or
  Activity Diagrams.
• Defines end-end full-lifecycle process
• May include Iterations, Phases, Milestones (types
  of Activities)
• This is just one example, any other lifecycle can
  be defined.

75
Advanced Concepts Method Variability

• Mechanism that allows you to customize method
  content without directly modifying the original
  content.
• Similar to inheritance in OO programming.
• Permits re-use with specialization.
• For example, if plug-in B that extends elements
  in plug-in A
• Original elements in plug-in A are intact - all
  the changes are defined in your plug-in B
• Content variability is useful, for example
• To change the description of an existing role
• To add steps to an existing task
• To add guidance to an existing task, and so on.

76
Advanced Concepts Method Variability

• There are four types of method variability
• Contribute The contributing element adds content
  to the base element. Resulting published element
  is the base element contributing element.
• Extends The contributing element inherits the
  content of the base element and specialized some
  or all of it. Both the base element and the
  extending element are published.
• Replace The replacing element replaces the base
  element. The resulting published element is the
  replacing element.
• Extends-Replace Similar to extends, however the
  base element is not published.

Examples taken from Integrating Personal
Practices into a Development Process by Brian
Lyons, NumberSix Software
77
Advanced ConceptsProcess Variability

• Similar re-use mechanism are available for
  Process content as well.
• In addition, Activities may also be created from
  CPs in the following ways
• Extends The activity inherits the properties of
  the capability pattern. Updates to the
  capability pattern are automatically reflected in
  the activity (Green colour in WBS in EPF
  Composer).
• Copy An activity is created based on the
  capability pattern. It is not synchronized with
  the capability pattern (Black colour in WBS).
• Deep Copy Similar to copy, but applied
  recursively to activities.
• Local Variability When a capability pattern is
  defined (either by Extends or Copy) local
  variability may be done (ex. Suppress steps in a
  task descriptor, change performing role, etc.).

78
EPF Composer Introduction
79
EPF Composer

• EPF Composer is built upon the Eclipse platform
• Supports many of the Eclipse plug-ins
• For example, Mylar
• Different Views present specific information
• For example, Library view shows plug-ins and
  their content
• Perspectives group related views to support a
  workflow
• Standard Perspectives are
• Authoring for editing method content
• Browsing for previewing published elements

80
EPF ComposerAuthoring Perspective
Authoring Perspective
Library View
Task Editor (form based)
Configuration View
81
EPF ComposerAuthoring Perspective
Form based plain text or
Rich Text editors
82
EPF ComposerBrowsing Perspective
Browsing Perspective
Configuration View
Preview View
83
Basic ConceptsConfiguration Plug-in and Package
Selection

• Select sub-set of method library for publishing
  to HTML or exporting to MS Project or XML

Configurations
Select Content
Select Content
Select Content
84
Basic ConceptsConfiguration View Definition

• Categories group related elements
• Views defined by selecting Categories

Standard Categories
Custom Categories
Define Views
85
Customization Scenario A

• In this scenario, you are going to leverage the
  existing content without major customizations.
• You have reviewed the OpenUP content and feel
  that it would meet your needs with a minor change
  to remove the visual modeling aspects of the
  process.
• You are going to create a new configuration
  based on an existing one - then pick and choose
  content packages that make sense for your team.
• Lets try it

Note These are examples of customization
scenarios. Not all possibilities have been
explored due to lack of time for this tutorial.
86
Creating a Plug-in (1/2)

• Right-click on any existing element in the
  library
• Select New Method Plug-in
• In the Create a new method plug-in dialogue
  enter
• Name (lower case, no spaces)
• Description (optional)
• Author (optional)
• Referenced Plug-ins
• Referenced Plug-ins set the visibility to other
  plug-ins

87
Creating a Plug-in (2/2)

• New plug-in created with default (empty)
  structure
• Editor opens to permit you to change/update the
  plug-in description.

New Plugin
88
Creating a Method Content Package (1/2)

• Right-click on the Content Packages Node
• Select New Content Package
• The new package is created
• The editor will open

89
Creating a Method Content Package (2/2)

• New package created with default (empty)
  structure
• Only appropriate type of element can be created
  under each node.
• Enter name (lower case, no spaces) and brief
  description.

New Content Package
90
Creating a Task (1/2)

• Right-click on the Tasks node in the desired
  content package
• Select New Task
• The new task is created
• The editor will open

91
Creating a Task (2/2)

• Each method element has two names
• Name the internal name, maps to filename (lower
  case, no spaces)
• Presentation Name appears in published website

New Task
92
Editing a Task

• The task editor has a number of tabs along the
  bottom edge
• Description to capture general attributes of
  task and variability
• Steps to define the steps of the task
• Roles to define responsible roles for the task
• Work Products to define input/output work
  products for the task
• Guidance to associate guidance elements with the
  task
• Categories to categorize the task
• Preview to preview the task (NOTE variability
  not resolved).
• Each tab has a form to capture attributes
• Some fields have Rich Text Editing Capability
• Click the icon to open the RTE.
• The Rich Text Editor also has a tab to view/edit
  HTML

93
Customization Scenario B

• In this scenario, you are going to add guidance
  for your team that is not part of the OOTB
  content.
• Your team wants to apply the CRC cards technique
  for representing design.
• You are going to create a new plug-in, create a
  contributing task (using the content variability
  concept introduced above) and add guidance on
  Class Responsibility Collaboration (CRC) cards
  technique.
• Lets try it

Note These are examples of customization
scenarios. Not all possibilities have been
explored due to lack of time for this tutorial.
94
Creating a Delivery Process (1/5)

• Right-click on the Delivery Process node
• Select New Delivery Process
• The New Process Component dialogue will open.
  Enter
• Name (lower case, no spaces)
• Default configuration

95
Creating a Delivery Process (2/5)

• New Delivery Process is created
• Editor opens to permit you to change/update
  content

New Delivery Process
96
Creating a Delivery Process (3/5)

• The Delivery Process editor has a number of tabs
  along the bottom edge
• Description to capture general attributes of
  process
• WBS to define activities of the process and
  their relationship
• Team Allocation to view and edit roles
• Work Products Usage to view and edit work
  products
• Consolidated View to view and edit roles,
  activities, work product roll-up
• Usually we dont need to edit the last three,
  they are populated automatically when activities
  are added to the WBS. They can be edited if one
  wishes to specialize the activities.

97
Creating a Delivery Process (4/5)

• Drag/Drop capability patterns from the
  configuration view onto the WBS
• Select Extend, Copy, or Deep Copy (see next slide)

Drag/Drop CP
98
Creating a Delivery Process (5/5)

• When adding a capability pattern to a delivery
  process you can
• Extend This will maintain a link to the CP so
  that any updates to the CP will be reflected in
  your delivery process.
• Copy this will make a local copy of the CP. It
  will not be linked to the original CP.
• Deep Copy This is similar to copy, but applied
  recursively to sub-capability patterns.
• The most common is Extend. Copy and Deep Copy
  will increase maintenance overhead as updates
  must be made manually.

99
EPF Composer Publishing

• Configuration Publish to start the Publish
  Method Wizard
• Various publishing options

100
Resulting Website
101
Customization Scenario C

• In this scenario, you will create a new delivery
  process for your software development lifecycle.
• You have reviewed the OpenUP delivery process and
  would rather follow a process that is more like
  the Scrum lifecycle.
• You realize that you can reuse existing method
  and process content from OpenUP plug-in and
  simply re-define the lifecycle.
• Lets try it

Note These are examples of customization
scenarios. Not all possibilities have been
explored due to lack of time for this tutorial.
102
EPF Composer Import

• File Import to start the Import Wizard
• Can import a Configuration, a plug-in, or raw
  XML.

103
EPF Composer Export

• File Export to start the Export Wizard
• Can export a Configuration, a plug-in, raw XML or
  MS Project Template