The Process Framework (EPF) Project <Beacon>

Introduction

This proposal is in the Project Proposal Phase (as defined in the Eclipse
Development Process document) and is written to declare its intent and scope.
This proposal is written to solicit additional participation and input from
the Eclipse community. You are invited to comment on and/or join the project.
Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology
newsgroup.

Background

Throughout the software industry, there are a lot of great ideas and knowledge
about how to effectively develop software. This knowledge may be centered around
1) technologies, such as J2EE, .NET, and various tool environments; 2) various
specialty domains, such as how to do iterative and agile development, how to build
secure software, how to best leverage service-oriented architectures, or how to
do distributed development; and 3) various vertical industry knowledge, such as
how to deal with straight-through processing in the financial world, or how to
build embedded systems for the auto industry.

Integration: When different media, notations, language,
and terminology are used to express process assets, integration of the process
assets becomes difficult to achieve. Furthermore, lack of standard interfaces
makes it hard to integrate these assets with; project & portfolio management
tools, such as IBM
Rational Portfolio Manager, Rally's
Agile Management Application or Microsoft
Project; process management and support tools, such as WayPointer
or IRIS;
or development environments such as the Eclipse platform.

Redundant and Isolated Work: When process assets are developed
with limited collaboration between different groups, some groups may take
part in redundant work, reinventing the wheel rather than adding value to
preexisting work or failing to leverage ideas towards accelerating innovation.

Flexibility and Communication: When process assets are
developed without a framework that allows for integration and customization,
they may not be effectively communicated for a specific project or organization.

To provide exemplary and extensible process content for
a range of software development and management processes supporting iterative,
agile, and incremental development, and applicable to a broad set of development
platforms and applications

Extensible software process engineering framework

The framework consists of the following two components:

Meta-model: Method content and processes will be structured
based on a formal meta-model. This meta-model will be documented with a comprehensive
meta-model specification using MOF, UML diagrams, as well as an associated
XML schema. The initial version of this meta-model has been derived from IBM's
Unified Method Architecture (UMA, reference to UMA specification download
to be added soon). UMA is an evolution of the current OMG industry standard
Software Process Engineering
Meta-model (SPEM) v1.1 integrating concepts from IBM Rational Unified
Process, IBM Global Services, and IBM Rational Summit Ascendant. IBM and other
OMG partners are working on making UMA, with improvements suggested by partners,
to become SPEM 2.0.
Two versions of draft specifications have already been submitted to the OMG
as of November 2005. The initial exemplary tool implementation for EPF will
be based on the first
draft submission. As SPEM 2.0 stabilizes, it is expected to update the
EPF to the final specification. The meta-model will be extensible through
the usage of custom attributes and custom process elements as well as normal
EMF extensibility mechanisms.

Core extensible process tooling framework - Basic functionality
and extension point APIs will be provided to allow 1) method authoring, 2)
process authoring, 3) library management, and 4) configuring and publishing.
Each of these domains is described in more details below, under exemplary
tools.

An initial implementation of the process engineering framework is offered for
contribution by IBM. It will require some modification to be made extensible,
following the SPEM 2.0 extensibility mechanisms.

Exemplary tools

The following exemplary tools provide the following capabilities:

Method Authoring - Best practices can be captured
as a set of reusable method building blocks as defined in the meta-model;
roles, work products, tasks, and guidance, such as templates, guidelines,
examples, and check lists. Relationships between method elements can be
defined through forms. A rich-text editor allows you to document method
elements, and graphical views present diagrams showing relevant
relationships. Reuse is facilitated by allowing you to create a method
element as a derivative of another method element through various
inheritance-type of relationships. This allows you to e.g. specify that
a Systems Architect has similar responsibilities to a Software Architect
by expressing the differences, reusing everything that is common.

Process Authoring - Reusable process building blocks
can be organized into processes along a lifecycle dimension by defining
e.g. Work Breakdown Structures (WBSs), and when in the lifecycle to
produce what work products in which state. The tool allows you to construct
reusable chunks of processes through so called capability patterns.
A capability pattern may for example define how to define, design,
implement and test a scenario or a user story, and this pattern can now
be reused in a variety of processes. The tool also allows you to define
delivery processes, which are end-to-end processes. Structural information
can often be edited with graphical as well as non-graphical editors.

Library Management and Content Extensibility - An
XMI-based library enables persistency and flexible configuration management
as well as content interchange for distributed client-server implementations.
Method and process content can be packaged into content plug-ins and content
packages allowing simple distribution, management and extensibility of content.
A plug-in can be produced describing how content in other plug-ins should
be extended. As content plug-ins are added to your content library, the tool
will resolve dependencies between process elements.

Configuring and Publishing - A process configuration
can be created by selecting a set of content plug-ins and content packages.
Optionally, an exemplary process configuration can be used as a starting
point,
and content plug-ins and content packages added or removed from this exemplary
configuration. As an example, you may start with a generic exemplary process
suitable for small collocated teams, and add content plug-ins containing
specific
guidance for each of Eclipse, JUnit, J2EE, and IBM Rational RequisitePro.
The delivery processes associated with a configuration can be further customized.
As the configuration is published, the tool resolves the many relationships
that
may exist between process elements in the selected plug-ins and packages,
and generates a set of html pages with links representing relationships between
process elements to make the resulting Web site easy to navigate.
The resulting Web site is viewable via a web browser, without
the need for a Web server. This will allow users on all platforms to view
the published process.

An initial implementation of these features is offered for contribution by
IBM. See proposal artifacts at the end of this proposal. This initial contribution
needs to be matured, and refactored to address the added extensibility of the
process engineering framework.

Exemplary and extensible process content

Our intention is to enable the ecosystem to build software best practices.
Some of these best practices may be contributed to Eclipse as exemplary uses
of EPF, while others may be commercial process offerings. A key value proposition
with the Process Framework is the ability and intent to support a wide spectrum
of development styles to accommodate both established practices as well as new
ones as they are introduced. The scope of the open source content will be kept
small initially, to enable us to build a stable set of high-quality base content,
focusing on core development activities; requirements, analysis & design, implementation,
testing, change management, and project management. It is however crucial, that
the framework and the base content can be extended to scale to support content
covering the entire IT Lifecycle Management domain, including software, systems
and product development, business engineering, operations and systems management,
governance and portfolio management.

IBM is offering for contribution the Basic Unified Process (BUP, a very
light weight adaptation of RUP with influences from Scrum. This content exists
in draft format, but needs to be completed and evolved based on contributions
from other project members. The content may also need to be refactored to
enable a broad set of processes to be created from it through content extensions.
See BUP whitepaper and demo
of the BUP prototype (BUP.avi). Also see a demo of a variant of Basic Unified Process with Scrum influences (BUP+Scrum.avi). Several other companies such as
Ambysoft, BearingPoint,
Capgemini, Covansys,
Ivar Jacobson International, Number
Six, and University of British Columbia
will also create other content extensions

Organization

We propose this project should be undertaken as a Technology project
rather than as part of the Eclipse Platform. Being a Technology project gives
it room to experiment without disruption to other Eclipse Platform development
work.

Since Technology sub-projects are not meant to be ongoing, we foresee two possible
evolutionary paths for the subproject:

The project is moved to a permanent state as a Tools Platform project.

The technology proves to be insufficient for Eclipse and the work is set
aside.

These paths are not mutually exclusive. Some combination of some or all of these
paths may be the result of the work done in this project.

Meta-model - IBM also proposes to contribute a content
meta-model, referred to as Unified Method Architecture;see meta-model
section above for more details.

Exemplary Tooling Donation - IBM proposes to contribute
a new set of tools built from scratch, and of alpha quality. The tools already
have the capabilities described in the Exemplary Tooling section above, and
will need to be modified to support added process engineering framework extensibility

Contribution on enhancements to, and integration of, the meta-model and
continuous participation on OMG SPEM initiative.

Proposed Ambysoft Contributions

Content around Agile Modeling and Agile Database Techniques.

Proposed Catalyst Contributions

Content around Agile Project Management.

Proposed Covansys Contributions

Meta-model improvements to allow increased content extensibility through
the concept of Work Components, as well as exemplary content for Basic Unified
Process providing a Work Component based management framework.

Proposed Ivar Jacobson International contributions

Content around the best practices of use-case driven development, component-based
development, model-based development, architecture-centric development, and
iterative and incremental development.

Content matured. At least two exemplary processes delivered; Basic
Unified Process and Agile/XP. Some level of commonality across the
two processes established, with reusable components extracted.

Agree on key concepts and their relationship, such as user story,
scenario and use case where it is seems feasible.

Iteration 1: 12/1 – 1/15

Train all committers.

Add text to all Basic Unified Process (BUP) elements

Outline Agile/XP process

Understand required changes to donated code, meta-model and content

Suggest basic set of APIs

Iteration 2: 1/15 – 3/1

Add text to all Agile/XP elements

Freeze APIs

Iteration 3: 3/1 – 4/15

Identify an initial set of key promoters presenting at conferences, writing blogs and articles, etc

Validate extensibility of BUP

Freeze structure of BUP and Agile/XP

Iteration 4: 4/15 – 6/1

Refactor and Polish BUP and Agile XP to increase commonality

Code freeze

Iteration 5: 6/1 – 7/15

End game

Enlist content owners and champions. Sep 2006.

Objectives:

Identify a broader set of process champions with an interest
to evolve EPF within a very specific domain. This could be to address
MDA or project management, or a specific vertical. These people do not
need to be well-known gurus, but rather specialists with a deep domain
knowledge, with an interest in evolving best practices within a certain
domain over an extended period of time.

Arrange a number of workshops in conjunction with major conferences,
allowing those with interest in process to learn more about EPF. Use
these venues to recruit candidate champions. Nurture them and help
them build a business case for why their company should invest in their
participation.

Release of Process Framework 1.5. 2007, Q2.

Objectives:

Ensure that EPF is valuable in a variety of contexts, such as within
a specific vertical, or can be integrated with various other process
tools