A look at SPEM and the Eclipse Process Framework

As you might have seen, there are a few pages on this site about operations manuals and process modeling, i.e. about describing the way of working in an organization in a semi-formal way. I have implemented a custom meta-model for process modeling [5] in Rational Rose and used it to describe the whole operations manual for a medical device company. The manual itself was generated in HTML format from the UML model in Rose. Since Rose is much too expensive for private use, I have also played around with StarUML, an open source UML editor, and made a translator that generates contents for a WordPress (blog) site from a process model in StarUML. StarUML is a very powerful and well documented tool with a good API. Unfortunately it’s a dead project so continuing that line of development doesn’t seem too attractive.

EPF
The EPF editor and the resulting web site. With tweaked styles.

In the mean time, a standard meta-model for process modeling, the SPEM (Software Process Engineering Meta-Model) [1], has been adopted by the Object Management Group. A variant of the SPEM meta-model has been implemented in the Eclipse Process Framework (EPF) Composer, an open source tool based on Eclipse [2]. I write “variant” because I haven’t had the time look at the exact mapping between SPEM and the implementation but it is not 1:1. In contrast to the StarUML project, the Eclipse project is one of the most active open source projects on the net. The basic platform seems very stable and a large number of other adaptations are also available, e.g. for UML2.

The purpose of the EPF is “To provide an extensible framework and exemplary tools for software process engineering – method and process authoring, library management, configuring and publishing a process.”.

SPEM is based on the more or less formal meta-model used for describing the original Rational Unified Process in its early web version (the Rational heritage is also hinted by the meta-model documentation that is generated from Rose and some of the code in the web site generated from the EPF model).

I have been using SPEM and EPF for a few days now and have compared them to my earlier experiences from tools and meta-models for process modeling. These are some of my tentative conclusions:

  • The documentation of both SPEM and EPF is excellent including a good tutorial. Very few open source projects can claim such good user guidance.
  • The Eclipse tool itself seems stable and runs equally well on Windows XP and Ubuntu 8.04 (the Ubuntu platform requires some tweaks at installation though, see [4]). I particularly appreciate the Linux compatibility.
  • The tool has an attractive user interface.
  • I’m happy that the modeling element Outcome is added to the meta-model. It took me a while to realize that such a modeling element was needed to represent those intangible results like a “informed customer”. (It corresponds roughly to the Objective modeling element in my meta-model.)
  • The Category concept is very useful, particularly for defining various structures for publishing the model.
  • Importing and exporting process models work fine.
  • There are provisions to manage the models in ClearCase and CVS. To what extent Subclipse can be used with EPF I haven’t investigated.

There are in general too many modeling elements in SPEM. I prefer my meta-models simple and conceptually lean. That was one of my goals with my own meta-model [5]. More specifically:

  • There are numerous different modeling elements for an activity (Step, Task, Process, Capability Pattern, Discipline, Activity, Task Descriptor, Phase) where I have only two (Activity and Workflow) that can be hierarchically structured. It is hard to remember the relationship between for instance a Task and a Task Descriptor (~inheritance) or to understand the conceptual difference between an Activity and a Task Descriptor (hierarchy).
  • There is a multitude of classes for various types of guidance. The only advantage that I really see with this is that one doesn’t have to write a title for the guidance since the title is given by the modeling element type.

Some other observations in the negative territory have to do with the fact that the implementation of SPEM in EPF is rather hard-wired:

  • There is no modeling element for Event which I have used quite heavily to describe the events that for instance trigger a change request or a customer support ticket. And I don’t see any way to add it either.
  • I would have preferred free format class diagrams through which to define the relationships between modeling elements. At least as a complement to the form based entry mode. It is nice that diagrams are created automatically from the data but still.
  • There is no way to add custom attributes to modeling elements. I have often needed this in my models to describe attributes that are there in the real implementation of the artifact (in a document header or in a field in a database object). Some examples are Approved by (the formal approver of the document), Valid from (the date from which a document is valid), ID (the unique identifier of the artifact) and so on.
  • There is no true inheritance mechanisms through which new modeling elements (“classes”) can be added to the language. I have often found it useful to design inheritance hierarchies when for instance specifying all artifact types used in an organization when these artifacts have several different levels of formality (for an example, see [5]). Instead there is this, in my mind somewhat ad-hoc-ish, mechanism for specializing Roles, Tasks and Artifacts from the Method library into the Process descriptions.

Last but not least, a couple of comments on visual appearance:

  • Some of the generated views are very cluttered, for instance some that belong to the Phase modeling element.
  • Tweaking the style of the published web site is very difficult as the style definitions are spread on at least 5 different files. Being able to modify the style is important for industrial users. They will invariably want to use their own graphical profile.

Despite the above critique I will try out EPF in an industrial setting in the near future. It seems easy enough to grasp and use and gives a much better framework for structuring the processes than e.g. unstructured Word documents. Maybe I later get the inspiration to implement my own meta-model in the Eclipse Domain Specific Language Toolkit.

Links

[1] Software Process Engineering Meta-Model, version 2.0. OMG.

[2] Eclipse Process Framework Project (EPF).

[3] Open Unified Process.

[4] Editors do not work [message #55830] (EPF Forum)

[5] My process modeling meta-model

2 thoughts on “A look at SPEM and the Eclipse Process Framework

  1. I hope you had the opportunity to try EPF in a commercial setting. I did … in a mid-size bank.

    I pitched the idea to executive management. They were skeptical because of previous experience elsewhere. The tooling was partly at fault, a lot of issues stemmed from knowing how to gain adoption at the enterprise level. I recommended the plan, explained how the process will be built, who owns what (very important in orgs where ownership matters), and how. We ran a pilot and *simulated* the use of EPF-based processes. Gathered the feedback, created video-based training and held IT-wide lunch-n-learn sessions. We even demonstrated how the lifecycle works by “creating” ice-cream product and getting people involved relating phases of the lifecycle to the ice cream process – they all gained weight too! Anyway, after 2 years, management still does not mention the lifecycle in any corporate communication, BUT everyone not only knows of the lifecycle, but they hold each other accountable for achieving phase deliverables. EPF has worked for us and we continue to add domains to the methodology bringing in more content with each release.

    There is a lot of scope creep in something as simple and as important as EPF – stick with basics, make sure the users adopt. I advocate Open Source in my organization anywhere it makes sense.

  2. Thanks for your input! I’m actually using it right now in the small medical device company I work for. I was hesitant to bring it up at all in an environment where a “process description” usually was a couple of pages of prose without any particular structure and not everybody in the management team was an engineer. But I decided to give it a try. First I spent about a week on tweaking the graphical layout, changing colors, adding a nice banner, simplifying the layout by removing tabs and sections, making sure that the index and glossary were populated, that the feedback link led to our change management system, that we had a clear version history etc. I didn’t focus much on the actual content. That sales pitch worked! It helps that everybody was tired of the old system that really was neither pretty nor easy to use. We keep the model source code in Subversion and there are several people working on various plugins. I haven’t yet introduced the word “meta-model” though :)

Leave a Reply

Your email address will not be published. Required fields are marked *