Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epf-dev] SEMAT OMG RFP, EPF response?

Bruce,
 
It is interesting to read the arguments. Thanks for sharing this.
 
While 1. "lack of enactment support" is in the SPEM context, we also found enactment to be something that EPF users were looking for - my company included. Teams tend to leave EPF sites back once they get into the thick of their daily project issues. Our solution was to at least automate EPF sites by embedding PoP Project. Teams can now instantiate EPF OpenUP or Scrum as a live, collaborative project. It is working well for us.
 
I plan to demo such EPF based project automation in my EPF webinar (Apr 14, 2011 - 8:00AM PST). It may not relate directly to process standard definitions but is certainly showing traction from a process consumer angle.
 
Diwant Vaidya
 
Founder and CEO
Paradigm PoP
 
 
On Thu, Apr 7, 2011 at 6:23 PM, Bruce Macisaac <bmacisaa@xxxxxxxxxx> wrote:

Dear EPF community,

There was a recent submission to OMG to propose a new process standard.
It is not based on SPEM or any of the work we have done in EPF, but rather is based on the SEMAT kernel work.
(For those who don't know this, EPF was originally based on SPEM http://www.omg.org/spec/SPEM/2.0/ )

Some  reasons given for why the proposal ignores SPEM is:

1. "lack of enactment support"
If this is a significant concern, then a set of requirements for what would be appropriate enactment support should be described in the RFP.
A goal to what people actually do vs. what they are supposed to do isn't a sufficient set of requirements.
There are some hints in the RFP, but they aren't clear:
"Methods can be queried to get guidance based on where you are and where you want to go"
- this seems to be about describing how the processes evolve during enactment - this could be a natural extension to SPEM

2."The notion of composable practices is not explicitly defined as a core concept in the SPEM metamodel"
This seems to be a gap which could be addressed by a SPEM update.  Note that both SEMAT and EPF have gone beyond SPEM and
added support for practices to their method offerings.  They both use similar concepts and provide similar capabilities, but not identical.
This kind of divergence is exactly the kind of problem that standards organizations like OMG strive to avoid, so the time
is ripe to add practices support to SPEM.

3. "UML profile ... might be more complex and not as user-friendly as a more domain-specific language"
There is also a MOF representation of SPEM, but in any case, any approach for simplifying is welcome, but doing something completely unconnected
doesn't make a lot of sense.

4. SPEM does not specify a kernel of "essential elements"
Both SEMAT and EPF define such a kernel, but use different terminology and have made different choices regarding those essential elements.
Again, this is where standards are valuable - they align the best of divergent ideas so that the entire community can benefit.
The EPF kernel has been defined and publicly available for some time.   It is well supported by both the EPF Composer and Rational Method Composer tools.
It is based on an extension to SPEM.
A natural path forward would be to take the EPF kernel and formalize it in an extension to SPEM, reconciling differences with the SEMAT kernel to the benefit of the entire community.  I propose an extension, because I think SPEM should remain capable of modeling processes that don't use a kernel, or
that use alternative kernels.

If this is a topic that interests you, and you would like to be involved in this discussion, please drop me a note.

Bruce MacIsaac
Manager RMC Method Content
bmacisaa@xxxxxxxxxx
408-250-3037 (cell)

_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev



Back to the top