Introduction to EPF Agenda - PowerPoint PPT Presentation

1 / 102
About This Presentation
Title:

Introduction to EPF Agenda

Description:

... of micro-increments is monitored daily via 'Scrums' and the iteration burndown ... Develop Solution Increment for UC 1 Main Flow is a micro-increment (a task with ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 103
Provided by: ChrisS133
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com