Bruce, as a major contributor to SPEM2 at the OMG, I'm definitely interested in participating in the discussion. I heard that the SEMAT proposal was not approved by the ADTF at the latest OMG meeting. From what I understand about SEMAT (which may not be very much), there is no reason that SPEM2 could not be augmented to address new requirements (as well as those implemented by EPF).
FWIW, in response to enactment, that was a topic we intentionally put out of scope in SPEM2. It was something that we all considered, but seeing that we had already been working on SPEM2 for almost three years, we needed to curtail scope to finish it. While "composable practices" may not be explicitly a part of the SPEM2 metamodel, I believe the Process Component element in SPEM2 could be used to implement practices (as it exposes Work Product Ports, which seem to be very similar to Work Product Slots in EPF). With respect to UML profiles and all that, at APG we have built several very large process models using the SPEM2 UML profile and it seemed to work pretty well. As you duly noted, Bruce, SPEM2 has a MOF metamodel, so people could use MOF-based tools, if they found UML profiles constraining or not "user friendly". Seems to be this point is speculative and not based on actual evidence. I'm not really sure what is meant by SPEM2 not having a kernel of essential elements. I guess that depends on what you mean by a "kernel" and "essential elements". SPEM2 has seven packages in its metamodel, including "Core", so there was effort invested to factor the model to allow for different types of usage scenarios. All in all, I don't know of any reason why, whatever SEMAT and EPF need, that we would not be able to address that in a new version of SPEM. Creating a new DSL for SEMAT seems pretty short-sighted, when we already have a pretty decent DSL available in SPEM. APG would certainly participate in such an effort at the OMG and EPF, so count us in! Thanks, Chris ~:| Chris Armstrong ~:| President Armstrong Process Group, Inc. 651.491.5575 c 651.204.9297 f [email protected] cell message www.aprocessgroup.com "proven practical process" Access APG's Introduction to Enterprise Architecture <http://apg.coursehost.com/course/c23sq8> web-based training (WBT) for no charge. Absolutely free! Come see APG at: --------------- The Open Group Conference <http://www.opengroup.org/london2011/> May 9-13, 2011, London, UK --------------- OMG Technical Meeting <http://www.omg.org/news/meetings/tc/va/info.htm> March 21-25, 2011, Arlington, VA --------------- From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Macisaac Sent: Thursday, April 07, 2011 6:24 PM To: [email protected] Subject: [epf-dev] SEMAT OMG RFP, EPF response? 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/> 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 [email protected] 408-250-3037 (cell)
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
