A software development methodology describes who does what, how, and when to produce a software product. In this regard, the Eclipse Process Framework (EPF) provides a general formalism to:
- Capture the essence of the who, the what, the when, and the how, as method elements.
- Define the different relationships between these elements.
EPF also provides a clean separation between the definition of the methodology elements and their presentation to the methodology users.
EPF encapsulates meaningful and related method and process contents in method plug-ins. The contents of plug-ins can then be extended or modified by other plug-ins. EPF provides a set of exemplary processes, the main one being OpenUP.
Figure 1 is a simplified view of the key EPF method elements and their relationships. The framework provides many more artifacts and relationships flavors and nuances:
- A set of different tasks compose a discipline.
- A certain combination of roles perform a task, using a set of guidelines to assist in the execution.
- A task relies on input work-products to be performed and outputs other work-products and deliverables.
- A work-product or deliverable can be based on a template.
- The design of a work-product or deliverable can use examples, white-papers, reports, reusable assets, and the like.
The design of a methodology in EPF starts by creating the above elements and their relationships (a.k.a. "associations") within a method library using the EPF Composer, an integrated development environment (IDE) built on top of the Eclipse platform.
A set of attributes, taking the form of pure textual information or Rich Text, describe each element:
- General information. Includes name, presentation name and brief description
- Detail information. Includes purpose, main description, key considerations,
- Version information. Includes version number, change date, change description, authors
The above elements come together in an organized way through the definition of Processes (Capability Patterns or Delivery Processes), which provide the concepts of Work Breakdown Structure, Team Allocation, and Work Product Usage.
EPF then allows grouping the different elements by categories: Standard and custom categories. Standard categories are split into the pre-defined software methodology concepts of Disciplines, Domains, Work Product Kinds, Role Sets, and Tools. For example, you can create a "Project Data" category under the Work Product Kinds standard category and use it to qualify work products such as test results, problem reports, weekly status reports, and the like.
In contrast, custom categories are unconstrained hierarchical, ordered collections of method elements. Their main use is to compose configurations that are published as final methodology content. A standard use of a custom category is to present the different methodology elements according to different chosen points of view. Figure 2 shows an example of a custom category which presents the components of a process by grouping an introduction, a set of concepts, the set of disciplines, roles, delivery processes and work product kinds.
Plug-in entities bring together EPF method elements packages and processes. A plug-in can reference another plug-in so that its element definitions can reuse and extend the content of the referenced plug-in. This mechanism allows customizing the standard OpenUP content and tailoring it to the specific needs of an organization.
Method elements have a Content Variability section where the user can define how an element relates to another one, either from the same plug-in or, more often, from one of the referenced plug-ins. The variability definition can have different semantics, that can be roughly described as follows:
- Extends. The extending element contents brings some additional information on top of the element it extends, implementing some kind of inheritance. When published, the extended element remains untouched, and the extending element shows the content of the extended element augmented (for associations) or overwritten (for attributes) with the contents of the extending element.
- Contributes. The element contents represent some additional information on top of the element it contributes to. When published, it is now the contributed-to element that shows its own contents augmented by the contributing element's contents (associations and attributes).
- Replaces. The element contents represent a new definition for the replaced element. When published, the replaced element shows the contents of the replacing element.
- Extends and Replaces. This semantics acts as a combination of the above Extends and Replaces semantics. When published, it is now the base element that shows its own contents augmented with the contents of the extending element. The extending element remains untouched.
The concept of variability with its various semantics has been key in allowing the ISIS (ILOG Solution Implementation Standard) methodology to:
- Layer the method contents from generic to product-specific.
- Carve and distribute parts of the methodology for different recipients.
Configurations define which previously created elements should be published to the methodology users. A simple way to think about a configuration is as a set of views, each being materialized as a tab in the methodology web portal and presenting the contents of a custom category.
Configurations allow for some filtering on what to publish by selecting in each plug-in, which categories (standard or custom) should participate or should be removed from the published material. The concept of configuration allows the flexibility of building different, targeted instances of a methodology, based on the same compendium of material, with minimal investment.