Skip to main content

The Process Framework (EPF) Project <Beacon>


The PROCESS FRAMEWORK PROJECT is a proposed open source project under the Eclipse Technology Project.

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


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.

The sources for all of these great ideas and knowledge include organizations doing software development, open source communities, the agile community, Software Process Improvement Networks (SPIN groups), product and technology companies, academia and software research groups, such as SEI Carnegie Mellon, University of British Columbia, and USC Center for Software Engineering, a variety of methodologists and companies capturing industry best practices into various knowledge bases, literature, and processes. The problems with these process assets are:

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


Project Goals

There are two goals of the Process Framework Project:

  • To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process.
  • 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
  • Other project members, including Object Mentor, Bedarra Research Lab, Rally Software Development and Ambysoft will collaborate to contribute a Basic Agile process which covers other key ideas and processes from the Agile Development community, including Agile Modeling, Extreme Programming and Scrum

More exemplary and extensible processes will be created as committers express interest and contributions are proposed. See demo of process authoring capabilities in the EPF prototype (Authoring.avi).

Target Users of the Process Framework

For a perspective of how different types of organizations may leverage the Process Framework, see whitepaper titled Who will benefit from Process Framework


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:
  1. The project is moved to a permanent state as a Tools Platform project.
  2. 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.

Proposed project lead and initial committers

Interested parties

The following projects have expressed interest in this project. Key contacts listed.

The following process community leaders are supporting the initiative, on top of the ones that are already defined as committers: Grady Booch and Ivar Jacobson

Code Contributions

To jumpstart the project, the following contributions are proposed.

Proposed IBM Contributions

  • Process engineering framework
    • Core process tooling framework – IBM proposes to donate the core process tooling framework, but this does not yet have exposed API extension points.
    • 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
  • Exemplary and Extensible Content - IBM proposes to contribute a light-weight derivative of the IBM Rational Unified Process, incorporating some practices derived from Scrum.

Proposed 2-Pro Mentor Contributions

  • Contributions on process architecture and process enactment / automation.

Proposed Adaptive Contributions

  • 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 around Aspect Oriented Software Development.

Proposed Object Mentor Contributions

  • Content for Agile/XP exemplary process whereof subset is co-owned with IBM.

Proposed SOFTEAM Contributions

  • Application of software process to projects, by providing extensions to the core process tooling framework, in particular by providing bridges to external tools such as MS Project.

Proposed Rally Contributions

  • Content for Agile/XP exemplary process.
  • Content for key concepts and relationships including User Story, Story card, Usc Case scenario and Use Case.

Tentative Plan

The following outlines a high-level development plan, including developer outreach, with major milestones and what is expected to be achieved.

  • Project acceptance and provisioning. December 1, 2005.
    • IBM donation. Project environment established. Committers start to work.
  • Release of Process Framework 1.0. July 2006.
    • Objectives:
      • Process tools matured and usable to produce a broad set of processes.
      • Basic set of interfaces / APIs defined, stabilized, and delivered.
      • Support multi-user content development
      • Support process-centric configuration and publishing
      • 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
      • Expand upon APIs with integration for Eclipse-based tools.
      • Provide custom attributes and process elements for meta-model extensibility
      • Provide process compare and merge
      • Provide query facilities
      • Provide exemplary integration between EPF and Eclipse-based tools
      • Expand content into one or two high-priority areas, such as content for IT project management, or product lifecycle management.
      • Refactor content to increase commonality, and to facilitate content extensions and customizations by consumers and plug-in providers.
      • Have EPF included in many University curriculums. Establish course material that can assist in including EPF in curriculums.
      • Have researches to do research around EPF. Seek to have members offer University grants to researchers.

Additional Information and Proposal Artifacts

The following artifacts are referenced in this proposal:

Note: If you are unable to see the video portion of the demos above, you may need this codec file.

Back to the top