[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] SEMAT OMG RFP, EPF response?
|
Bruce,
Having worked with EssUp/IJI, the driving force behind this
proposal, I would be very interested in being involved in the
discussion.
Kind regards,
John
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)
Please consider the environment before printing this email.
This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Limited group of companies.
Detica Limited is registered in England under No: 1337451.
Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
