Home » Eclipse Projects » Technology Project and PMC » EPF Metamodel
| EPF Metamodel [message #69987] |
Mon, 21 November 2005 17:43  |
Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
As an early Software Process Engineering Meta-model (SPEM) adopter and
co-submitter of SPEM 2.0 submission, we at Osellus are very excited to see
this focus on software process modeling and the potential of EPF to further
this cause. SPEM 1.1 is a widely adopted standard from OMG and we have come
across many teams utilizing this standard in modeling software processes
across different methodologies. We would propose that EPF follow this widely
adopted industry standard as the meta-model to create process modeling
content. This will serve two key benefits. Firstly, it will ensure that the
models conform to an existing non-proprietary industry standard which is
more useable with minimum training. Secondly, it will serve as an excellent
and very timely feedback mechanism to contribute to the evolving SPEM 2.0
submission channeled through many SPEM 2.0 co-submitters who are already
contributors in EPF. Note that as part of SPEM 2.0 RFP one of the tasks we
are required to do is the migration of all content from SPEM1.1 to SPEM 2.0.
This will automatically ensure that none of the contributed process modeling
content is wasted. As part of this project we should not interfere in the
standard setting process which a standards body like OMG's excels in doing,
rather we should adopt industry standards and build content and tool-ware
around these standards.
Thanks,
Kamal Ahluwalia
Osellus Inc.
|
|
|
| Re: EPF Metamodel [message #70067 is a reply to message #69987] |
Tue, 22 November 2005 22:55  |
 Per Kroll
Messages: 60
Registered: July 2009 |
Member |
|
|
Hi Kamal,
I agree with you that we should follow standards, and that is a part of the
plan. SPEM 2.0, as you know, is still evolving. The tooling and content IBM
is suggesting to contribute is based on a meta-model that is an evolution of
SPEM 1.1, and pretty close to current SPEM 2.0 proposal. I hope that SPEM
2.0 will be stable enough soon enough so we can support SPEM 2.0 in the
first release of EPF v1.0. But to really committ to that, we need to better
understand the impact, understand who is willing to work on it, and then
plan accordingly.
Any volunteers?
Cheers
/Per
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dlt0vu$sa4$1@news.eclipse.org...
> As an early Software Process Engineering Meta-model (SPEM) adopter and
> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to see
> this focus on software process modeling and the potential of EPF to
> further this cause. SPEM 1.1 is a widely adopted standard from OMG and we
> have come across many teams utilizing this standard in modeling software
> processes across different methodologies. We would propose that EPF follow
> this widely adopted industry standard as the meta-model to create process
> modeling content. This will serve two key benefits. Firstly, it will
> ensure that the models conform to an existing non-proprietary industry
> standard which is more useable with minimum training. Secondly, it will
> serve as an excellent and very timely feedback mechanism to contribute to
> the evolving SPEM 2.0 submission channeled through many SPEM 2.0
> co-submitters who are already contributors in EPF. Note that as part of
> SPEM 2.0 RFP one of the tasks we are required to do is the migration of
> all content from SPEM1.1 to SPEM 2.0. This will automatically ensure that
> none of the contributed process modeling content is wasted. As part of
> this project we should not interfere in the standard setting process which
> a standards body like OMG's excels in doing, rather we should adopt
> industry standards and build content and tool-ware around these standards.
>
>
>
> Thanks,
>
>
>
> Kamal Ahluwalia
>
> Osellus Inc.
>
>
|
|
|
| Re: EPF Metamodel [message #70126 is a reply to message #70067] |
Wed, 23 November 2005 19:16 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Hi Per
SPEM 2.0 is in early stages of a long standardization process and it could
be over a year before a final SPEM 2.0 specification is available. Moreover
this final specification would most likely be different from this current
joint-submission which is a work-in-progress. Based on this I feel its best
if we put our efforts in creating content based on the current SPEM 1.1
specification. Osellus volunteers to convert any existing content, including
what you may have, into the SPEM 1.1 format.
Thanks,
Kamal.
"Per Kroll" <pkroll@us.ibm.com> wrote in message
news:dm07lb$bcg$1@news.eclipse.org...
> Hi Kamal,
>
> I agree with you that we should follow standards, and that is a part of
> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
> content IBM is suggesting to contribute is based on a meta-model that is
> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal. I
> hope that SPEM 2.0 will be stable enough soon enough so we can support
> SPEM 2.0 in the first release of EPF v1.0. But to really committ to that,
> we need to better understand the impact, understand who is willing to work
> on it, and then plan accordingly.
>
> Any volunteers?
>
> Cheers
>
> /Per
>
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dlt0vu$sa4$1@news.eclipse.org...
>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>> see this focus on software process modeling and the potential of EPF to
>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and we
>> have come across many teams utilizing this standard in modeling software
>> processes across different methodologies. We would propose that EPF
>> follow this widely adopted industry standard as the meta-model to create
>> process modeling content. This will serve two key benefits. Firstly, it
>> will ensure that the models conform to an existing non-proprietary
>> industry standard which is more useable with minimum training. Secondly,
>> it will serve as an excellent and very timely feedback mechanism to
>> contribute to the evolving SPEM 2.0 submission channeled through many
>> SPEM 2.0 co-submitters who are already contributors in EPF. Note that as
>> part of SPEM 2.0 RFP one of the tasks we are required to do is the
>> migration of all content from SPEM1.1 to SPEM 2.0. This will
>> automatically ensure that none of the contributed process modeling
>> content is wasted. As part of this project we should not interfere in the
>> standard setting process which a standards body like OMG's excels in
>> doing, rather we should adopt industry standards and build content and
>> tool-ware around these standards.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kamal Ahluwalia
>>
>> Osellus Inc.
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #70462 is a reply to message #70126] |
Sat, 03 December 2005 00:09 |
Per Kroll
Messages: 60
Registered: July 2009 |
Member |
|
|
Hi Kamal,
you are making a good point that it is uncertain when SPEM 2.0 will become a
standard. The current timeline indicates a stable proposal by March 2006,
and then it typically takes 1-2 years for it to become a final standard. So,
based on how this evolves in the next few months, we need to determine
whether it makes sense to support SPEM 2.0 for the release of EPF v1.0.
If we find that it does not make sense to support SPEM 2.0 for EPF v1.0, we
should still look at whether there are certain aspects of the current spec
for SPEM 2.0 that we should support before it is a formal standard. As an
example, Borland (Karl Frank) made a good case for changes to the meta-model
that were required to provide good support for some of the agilistas views,
allowing you to e.g. produce a process without having tasks. Many agilistas
have a hot button around specifying tasks, and we should respect that. (My
personal view is that the tasks are still useful as descriptive background
material, and should not be interpreted as prescriptive guidance, but that
is not here or there).
I think this is an area where we need to listen to the community and hear
what capabilities people would like to see in the process engineering
framework, and then from that determine how to evolve the metamodel. So, I
hope that the EPF projetc will lead to more input and consensus around the
SPEM 2.0 effort.
Also, I do not think the key thing is when a standard is a final standard,
but to assess when it is stable enough to dare to do investments towards.
Regarding your proposal to move back to SPEM 1.1, I see mainly disadvantages
in that, and few advantages. SPEM 1.1 has a long list of already specified
deficiencies (see the OMG ADTF presentation from the SPEM team for a list),
which we want to avoid. SPEM v1.1 also has limited practical support
(Osellus and IBM are possibly the only 2 companies that have built tools
around it... :) ). So, moving back to SPEM 1.1, rather than something very
close to SPEM 2.0, would in my mind create a big cost in changing the tools
to support old stuff that we know is less good than what is close to SPEM
2.0, introducing a lot of deficiencies we have worked hard to remove, while
provide very few benefits. The cost of migrating the content is negligent
relative to the move back in capabilities and cost of code changes....
Cheers
/Per
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dm2f6o$jrs$1@news.eclipse.org...
> Hi Per
>
>
>
> SPEM 2.0 is in early stages of a long standardization process and it could
> be over a year before a final SPEM 2.0 specification is available.
> Moreover this final specification would most likely be different from this
> current joint-submission which is a work-in-progress. Based on this I
> feel its best if we put our efforts in creating content based on the
> current SPEM 1.1 specification. Osellus volunteers to convert any existing
> content, including what you may have, into the SPEM 1.1 format.
>
>
>
> Thanks,
>
> Kamal.
>
>
>
> "Per Kroll" <pkroll@us.ibm.com> wrote in message
> news:dm07lb$bcg$1@news.eclipse.org...
>> Hi Kamal,
>>
>> I agree with you that we should follow standards, and that is a part of
>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>> content IBM is suggesting to contribute is based on a meta-model that is
>> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal.
>> I hope that SPEM 2.0 will be stable enough soon enough so we can support
>> SPEM 2.0 in the first release of EPF v1.0. But to really committ to that,
>> we need to better understand the impact, understand who is willing to
>> work on it, and then plan accordingly.
>>
>> Any volunteers?
>>
>> Cheers
>>
>> /Per
>>
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dlt0vu$sa4$1@news.eclipse.org...
>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>> see this focus on software process modeling and the potential of EPF to
>>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and
>>> we have come across many teams utilizing this standard in modeling
>>> software processes across different methodologies. We would propose that
>>> EPF follow this widely adopted industry standard as the meta-model to
>>> create process modeling content. This will serve two key benefits.
>>> Firstly, it will ensure that the models conform to an existing
>>> non-proprietary industry standard which is more useable with minimum
>>> training. Secondly, it will serve as an excellent and very timely
>>> feedback mechanism to contribute to the evolving SPEM 2.0 submission
>>> channeled through many SPEM 2.0 co-submitters who are already
>>> contributors in EPF. Note that as part of SPEM 2.0 RFP one of the tasks
>>> we are required to do is the migration of all content from SPEM1.1 to
>>> SPEM 2.0. This will automatically ensure that none of the contributed
>>> process modeling content is wasted. As part of this project we should
>>> not interfere in the standard setting process which a standards body
>>> like OMG's excels in doing, rather we should adopt industry standards
>>> and build content and tool-ware around these standards.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Kamal Ahluwalia
>>>
>>> Osellus Inc.
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #70596 is a reply to message #70462] |
Wed, 07 December 2005 20:03 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Per
In our experience there is a large community of users having a good
understanding of SPEM 1.1 which is the current OMG standard released January
2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these users use
SPEM to model their processes applying the specification in varying degrees
as suited. Although this modeling may be done outside of a tool context, it
still enables them to use a methodology of their choice or even create their
own in-house methodology. One of the salient features of SPEM 1.1 being its
ability to model a process using any methodology, was very deliberately
introduced by the then working group which as you know included such
luminary orgs as Rational, IBM, Fujitsu, Adaptive and Softeam amongst
others. It is evident from reading SPEM 1.1 that the team was guided by the
considerations to keep the spec "inclusive" around methodologies and
software development environments yet keeping it relatively "lightweight".
An example of this is the fact that SPEM 1.1 does not have the concept of
"tasks" at all.
Without getting into too much detail about the on-going work in SPEM 2.0, I
would like to point out that we are in the stage wherein we are requesting,
gathering and applying modeling scenarios from the process modeling
community of users, including Borland. This also means defining fundamental
concepts without favoring any specific approach. This exercise is going very
well and we reiterate our call to modeling users (who may or may not have
used SPEM 1.1) to get in touch with me or any other members of the SPEM 2.0
working group to contribute their scenarios. Note that one does not have to
be an OMG member to raise issues with specifications and can do so by going
to http://www.omg.org/technology/issuesform.htm .
As far as your comments about SPEM 1.1, I would just have these
clarifications:
1. SPEM 1.1 is the current standard from OMG released January 2005. It is
not correct to characterize it as an old standard.
2. Most organizations adopting SPEM 1.1 move forward from a "no-standards"
approach to modeling to a methodology agnostic and industry standard
approach to modeling.
3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
SPEM 2.0 specification are related to re-using process elements and process
workflow, support for process enactment, support for process metrics,
provision of greater guidance for terms used, which came to light with
adoption by SEPG process teams/enterprise.
4. Though it is true that there are limited tools built on SPEM 1.1 I don't
know of any tools built for SPEM 2.0 (its not possible since the standard is
still in-progress !)
Per, our position still remains that instead of using seemingly heavyweight
and untested concepts requiring a steep learning curve which make up UMA or
waiting for SPEM 2.0 which is a while away, we start process content
creation and best practices definition using SPEM 1.1. Moreover, as Ricardo
mentioned in his presentation on the 6th of December the entry of BUP
content is still not complete. We have already volunteered our help in
moving all donated content, including BUP to SPEM 1.1. We see a huge risk in
building tools/content based on a meta-model that is not an industry
standard. Furthermore instead of defining alternate meta-models we should
let OMG with its proven standards creation process, create industry standard
meta-models which we can then use as part of EPF.
Kamal.
"Per Kroll" <pkroll@us.ibm.com> wrote in message
news:dmqnnb$a25$1@news.eclipse.org...
> Hi Kamal,
>
> you are making a good point that it is uncertain when SPEM 2.0 will become
> a standard. The current timeline indicates a stable proposal by March
> 2006, and then it typically takes 1-2 years for it to become a final
> standard. So, based on how this evolves in the next few months, we need to
> determine whether it makes sense to support SPEM 2.0 for the release of
> EPF v1.0.
>
> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
> we should still look at whether there are certain aspects of the current
> spec for SPEM 2.0 that we should support before it is a formal standard.
> As an example, Borland (Karl Frank) made a good case for changes to the
> meta-model that were required to provide good support for some of the
> agilistas views, allowing you to e.g. produce a process without having
> tasks. Many agilistas have a hot button around specifying tasks, and we
> should respect that. (My personal view is that the tasks are still useful
> as descriptive background material, and should not be interpreted as
> prescriptive guidance, but that is not here or there).
>
> I think this is an area where we need to listen to the community and hear
> what capabilities people would like to see in the process engineering
> framework, and then from that determine how to evolve the metamodel. So, I
> hope that the EPF projetc will lead to more input and consensus around the
> SPEM 2.0 effort.
>
> Also, I do not think the key thing is when a standard is a final standard,
> but to assess when it is stable enough to dare to do investments towards.
>
> Regarding your proposal to move back to SPEM 1.1, I see mainly
> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
> already specified deficiencies (see the OMG ADTF presentation from the
> SPEM team for a list), which we want to avoid. SPEM v1.1 also has limited
> practical support (Osellus and IBM are possibly the only 2 companies that
> have built tools around it... :) ). So, moving back to SPEM 1.1, rather
> than something very close to SPEM 2.0, would in my mind create a big cost
> in changing the tools to support old stuff that we know is less good than
> what is close to SPEM 2.0, introducing a lot of deficiencies we have
> worked hard to remove, while provide very few benefits. The cost of
> migrating the content is negligent relative to the move back in
> capabilities and cost of code changes....
>
> Cheers
>
> /Per
>
>
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dm2f6o$jrs$1@news.eclipse.org...
>> Hi Per
>>
>>
>>
>> SPEM 2.0 is in early stages of a long standardization process and it
>> could be over a year before a final SPEM 2.0 specification is available.
>> Moreover this final specification would most likely be different from
>> this current joint-submission which is a work-in-progress. Based on this
>> I feel its best if we put our efforts in creating content based on the
>> current SPEM 1.1 specification. Osellus volunteers to convert any
>> existing content, including what you may have, into the SPEM 1.1 format.
>>
>>
>>
>> Thanks,
>>
>> Kamal.
>>
>>
>>
>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>> news:dm07lb$bcg$1@news.eclipse.org...
>>> Hi Kamal,
>>>
>>> I agree with you that we should follow standards, and that is a part of
>>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>> content IBM is suggesting to contribute is based on a meta-model that is
>>> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal.
>>> I hope that SPEM 2.0 will be stable enough soon enough so we can support
>>> SPEM 2.0 in the first release of EPF v1.0. But to really committ to
>>> that, we need to better understand the impact, understand who is willing
>>> to work on it, and then plan accordingly.
>>>
>>> Any volunteers?
>>>
>>> Cheers
>>>
>>> /Per
>>>
>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>>> see this focus on software process modeling and the potential of EPF to
>>>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and
>>>> we have come across many teams utilizing this standard in modeling
>>>> software processes across different methodologies. We would propose
>>>> that EPF follow this widely adopted industry standard as the meta-model
>>>> to create process modeling content. This will serve two key benefits.
>>>> Firstly, it will ensure that the models conform to an existing
>>>> non-proprietary industry standard which is more useable with minimum
>>>> training. Secondly, it will serve as an excellent and very timely
>>>> feedback mechanism to contribute to the evolving SPEM 2.0 submission
>>>> channeled through many SPEM 2.0 co-submitters who are already
>>>> contributors in EPF. Note that as part of SPEM 2.0 RFP one of the tasks
>>>> we are required to do is the migration of all content from SPEM1.1 to
>>>> SPEM 2.0. This will automatically ensure that none of the contributed
>>>> process modeling content is wasted. As part of this project we should
>>>> not interfere in the standard setting process which a standards body
>>>> like OMG's excels in doing, rather we should adopt industry standards
>>>> and build content and tool-ware around these standards.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Kamal Ahluwalia
>>>>
>>>> Osellus Inc.
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #70702 is a reply to message #70596] |
Fri, 16 December 2005 02:56 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello.
I do not see a problem. The current SPEM2 submissions and UMA/EPF are based
on SPEM1.
SPEM1 models can be represented in this new schema as we have proven by
migrating RUP (consisting of thousands of model elements based on SPEM1)
into this new format. So SPEM1 users get all of their familiar concepts.
Hence, it is not unproven at all, but fully implemented and working. The
specifications also address the SPEM requirements for supporting any kind of
development process as well as defining a minimal set of concepts. We are
just fixing the obvious and often criticized problems (and bugs) of SPEM1
and donating extensions such as method plug-ins and capability patterns that
were a big success with our clients. Such extensions however have been
packaged in the recent SPEM2 specification in a way that they are purely
optional for an implementer. The proposed EPF tool implements these, but
they are not mandatory for using the tool.
The EPF project is about creating new innovations in process engineering as
well as supporting best process engineering practices. We have been working
on SPEM2 for one and a half years now. I organized bi-weekly calls for SPEM
stakeholders and interested parties and have been to each and every OMG
meeting talking to stakeholders, presenting our proposals, gathering
feedback, and incorporating this into the specification as well as our
proposed EPF tool. Our initial submission was supported by all but one
organization that submitted a letter of intend for the SPEM2 RFP. The
revised specification was supported unanimously by all submitters. After
all this work I can say that the specification is on the right track of
realizing what people want in the SPEM as well as the general
development-process space. We therefore feel confident that this donation
reflects the trends of the next generation of SPEM. Of course, both EPF and
SPEM2 are work in progress, but we believe they should mutually improve each
other with feedback from both communities (the list of contributors already
seems to overlap significantly that this seems feasible and coordinatable).
Thus, the EPF architecture is flexible enough to allow changes and
incorporate updates. But, going back to SPEM1 and throwing away dozens of
man years of development work and hundred thousands of lines of code towards
this new direction and only concentrating on the old ways seems not to be a
logical course of action to me at this point.
As we have seen with the Eclipse EMF and UML2 projects, early
implementations of proposed standards help not only with the verification
and validation of the OMG specification, but it also facilitates early
uptake and success of a specification. I think doing this with EPF and
SPEM2 is just a logical conclusion of the lesson learned from these
projects.
Finally, I think you are bit inflating the success of SPEM1, the size of the
communities you mentioned, as well as SPEM1 fitness for use. There is no
implementation out there which completely or literally implements the
specification. Therefore, content exchange between different SPEM1 tools
using the SPEM1 XMI schema has never been implemented successfully by
anyone. I claim that one reason for this is because SPEM1 was specified
without the validation of an implementation. EPF has the chance to ensure
that a SPEM standard is realized that is fully proven with an implementation
(as actually requested in the SPEM2 RFP) as well as more importantly has the
agreement, acceptance, and support by major players in the development
process domain. Looking at the expertise of committers listed in the EPF
proposal, I think we have a huge opportunity here to development something
great for Eclipse as well as OMG (OMG being one of the EPF supporters as
well).
To confirm what I said here a quote from the official OMG SPEM 2 Request for
Proposal document:
"SPEM 1.1 saw low uptake. Since its issuance, few implementations have been
released and it has not been recognized by industry analysts who also failed
to recognize its relevance to the middleware market. There have been a
number of low profiled or casual adopters of the specification as well as
few commercial implementations. It is suspected that ease of adoption has
been an issue, and some of the SPEM 1.1 semantics were ambiguous and hard to
understand by adopters and hence not used in their practices. Submitters
should analyze the limited success of SPEM 1.1, and attempt to address these
issues in their solutions."
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino, CA
Tel/Fax: +1 408 863-8716
Email: <mailto:phaumer@us.ibm.com>
____________________________________________________________ __
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dn7f6l$aqa$1@news.eclipse.org...
> Per
>
> In our experience there is a large community of users having a good
> understanding of SPEM 1.1 which is the current OMG standard released
> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
> users use SPEM to model their processes applying the specification in
> varying degrees as suited. Although this modeling may be done outside of a
> tool context, it still enables them to use a methodology of their choice
> or even create their own in-house methodology. One of the salient features
> of SPEM 1.1 being its ability to model a process using any methodology,
> was very deliberately introduced by the then working group which as you
> know included such luminary orgs as Rational, IBM, Fujitsu, Adaptive and
> Softeam amongst others. It is evident from reading SPEM 1.1 that the team
> was guided by the considerations to keep the spec "inclusive" around
> methodologies and software development environments yet keeping it
> relatively "lightweight". An example of this is the fact that SPEM 1.1
> does not have the concept of "tasks" at all.
>
>
>
> Without getting into too much detail about the on-going work in SPEM 2.0,
> I would like to point out that we are in the stage wherein we are
> requesting, gathering and applying modeling scenarios from the process
> modeling community of users, including Borland. This also means defining
> fundamental concepts without favoring any specific approach. This exercise
> is going very well and we reiterate our call to modeling users (who may or
> may not have used SPEM 1.1) to get in touch with me or any other members
> of the SPEM 2.0 working group to contribute their scenarios. Note that one
> does not have to be an OMG member to raise issues with specifications and
> can do so by going to http://www.omg.org/technology/issuesform.htm .
>
>
>
> As far as your comments about SPEM 1.1, I would just have these
> clarifications:
>
> 1. SPEM 1.1 is the current standard from OMG released January 2005. It is
> not correct to characterize it as an old standard.
>
> 2. Most organizations adopting SPEM 1.1 move forward from a "no-standards"
> approach to modeling to a methodology agnostic and industry standard
> approach to modeling.
>
> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
> SPEM 2.0 specification are related to re-using process elements and
> process workflow, support for process enactment, support for process
> metrics, provision of greater guidance for terms used, which came to light
> with adoption by SEPG process teams/enterprise.
>
> 4. Though it is true that there are limited tools built on SPEM 1.1 I
> don't know of any tools built for SPEM 2.0 (its not possible since the
> standard is still in-progress !)
>
>
>
> Per, our position still remains that instead of using seemingly
> heavyweight and untested concepts requiring a steep learning curve which
> make up UMA or waiting for SPEM 2.0 which is a while away, we start
> process content creation and best practices definition using SPEM 1.1.
> Moreover, as Ricardo mentioned in his presentation on the 6th of December
> the entry of BUP content is still not complete. We have already
> volunteered our help in moving all donated content, including BUP to SPEM
> 1.1. We see a huge risk in building tools/content based on a meta-model
> that is not an industry standard. Furthermore instead of defining
> alternate meta-models we should let OMG with its proven standards creation
> process, create industry standard meta-models which we can then use as
> part of EPF.
>
>
>
> Kamal.
>
>
>
> "Per Kroll" <pkroll@us.ibm.com> wrote in message
> news:dmqnnb$a25$1@news.eclipse.org...
>> Hi Kamal,
>>
>> you are making a good point that it is uncertain when SPEM 2.0 will
>> become a standard. The current timeline indicates a stable proposal by
>> March 2006, and then it typically takes 1-2 years for it to become a
>> final standard. So, based on how this evolves in the next few months, we
>> need to determine whether it makes sense to support SPEM 2.0 for the
>> release of EPF v1.0.
>>
>> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
>> we should still look at whether there are certain aspects of the current
>> spec for SPEM 2.0 that we should support before it is a formal standard.
>> As an example, Borland (Karl Frank) made a good case for changes to the
>> meta-model that were required to provide good support for some of the
>> agilistas views, allowing you to e.g. produce a process without having
>> tasks. Many agilistas have a hot button around specifying tasks, and we
>> should respect that. (My personal view is that the tasks are still useful
>> as descriptive background material, and should not be interpreted as
>> prescriptive guidance, but that is not here or there).
>>
>> I think this is an area where we need to listen to the community and hear
>> what capabilities people would like to see in the process engineering
>> framework, and then from that determine how to evolve the metamodel. So,
>> I hope that the EPF projetc will lead to more input and consensus around
>> the SPEM 2.0 effort.
>>
>> Also, I do not think the key thing is when a standard is a final
>> standard, but to assess when it is stable enough to dare to do
>> investments towards.
>>
>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>> already specified deficiencies (see the OMG ADTF presentation from the
>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has limited
>> practical support (Osellus and IBM are possibly the only 2 companies that
>> have built tools around it... :) ). So, moving back to SPEM 1.1, rather
>> than something very close to SPEM 2.0, would in my mind create a big cost
>> in changing the tools to support old stuff that we know is less good than
>> what is close to SPEM 2.0, introducing a lot of deficiencies we have
>> worked hard to remove, while provide very few benefits. The cost of
>> migrating the content is negligent relative to the move back in
>> capabilities and cost of code changes....
>>
>> Cheers
>>
>> /Per
>>
>>
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dm2f6o$jrs$1@news.eclipse.org...
>>> Hi Per
>>>
>>>
>>>
>>> SPEM 2.0 is in early stages of a long standardization process and it
>>> could be over a year before a final SPEM 2.0 specification is available.
>>> Moreover this final specification would most likely be different from
>>> this current joint-submission which is a work-in-progress. Based on
>>> this I feel its best if we put our efforts in creating content based on
>>> the current SPEM 1.1 specification. Osellus volunteers to convert any
>>> existing content, including what you may have, into the SPEM 1.1 format.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Kamal.
>>>
>>>
>>>
>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>> Hi Kamal,
>>>>
>>>> I agree with you that we should follow standards, and that is a part of
>>>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>>> content IBM is suggesting to contribute is based on a meta-model that
>>>> is an evolution of SPEM 1.1, and pretty close to current SPEM 2.0
>>>> proposal. I hope that SPEM 2.0 will be stable enough soon enough so we
>>>> can support SPEM 2.0 in the first release of EPF v1.0. But to really
>>>> committ to that, we need to better understand the impact, understand
>>>> who is willing to work on it, and then plan accordingly.
>>>>
>>>> Any volunteers?
>>>>
>>>> Cheers
>>>>
>>>> /Per
>>>>
>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>>>> see this focus on software process modeling and the potential of EPF
>>>>> to further this cause. SPEM 1.1 is a widely adopted standard from OMG
>>>>> and we have come across many teams utilizing this standard in modeling
>>>>> software processes across different methodologies. We would propose
>>>>> that EPF follow this widely adopted industry standard as the
>>>>> meta-model to create process modeling content. This will serve two key
>>>>> benefits. Firstly, it will ensure that the models conform to an
>>>>> existing non-proprietary industry standard which is more useable with
>>>>> minimum training. Secondly, it will serve as an excellent and very
>>>>> timely feedback mechanism to contribute to the evolving SPEM 2.0
>>>>> submission channeled through many SPEM 2.0 co-submitters who are
>>>>> already contributors in EPF. Note that as part of SPEM 2.0 RFP one of
>>>>> the tasks we are required to do is the migration of all content from
>>>>> SPEM1.1 to SPEM 2.0. This will automatically ensure that none of the
>>>>> contributed process modeling content is wasted. As part of this
>>>>> project we should not interfere in the standard setting process which
>>>>> a standards body like OMG's excels in doing, rather we should adopt
>>>>> industry standards and build content and tool-ware around these
>>>>> standards.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Kamal Ahluwalia
>>>>>
>>>>> Osellus Inc.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
| |
| Re: EPF Metamodel [message #70723 is a reply to message #70715] |
Fri, 16 December 2005 20:17 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Yeah, we Germans just love our titles -- I promise, I will americanalize my
sig for this community :-)
Dr. rer. nat. = doctor rerum naturalium (Latin) = DSc, ScD, Doctor of
Science
____________________________________________________________ __
"Randy D. Smith" <randy.d.smith@intel.com> wrote in message
news:dnv1vr$if4$1@news.eclipse.org...
> Wow, this has been fun. But it's been a bit like (for me) watching a
> cricket match... I don't know a thing about the competing "teams" and the
> history behind them, I don't know the rules, I don't know "who's ahead",
> or any of that stuff. I just recognize the quality of play, even if it's
> outside my normal realm of experience.
>
> But one question I've got to ask... totally irrelevant to the discussion
> at hand...
>
> Peter Haumer wrote:
>
>> PETER HAUMER, Dr. rer. nat.
>
> What's a .. whatever that is? Looks fascinating. Haven't a clue what it
> means. The Dr. part looks familiar, but the rest might be Greek for all I
> know.
>
> Yes, completely irrelevant... feel free to ignore me. But I am curious.
> --
> RDS
|
|
|
| Re: EPF Metamodel [message #70744 is a reply to message #70702] |
Thu, 29 December 2005 18:58 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Peter, Per
As an early adopter of SPEM and a co-submitter of SPEM 2.0 we are excited
that we are now discussing which version of the SPEM standard to adopt as
the exemplary meta-model for EPF, as opposed to adopting a proprietary UMA
meta-model.
To reiterate, and for further clarification, I and my colleagues at Osellus
are in favor of pursuing improvements in SPEM, in the form of SPEM 2.0 and
subsequent versions of this specification. We are simply saying that SPEM
2.0 is not a standard yet, as is SPEM 1.1. It would make sense to base a
new contribution to the open source community on a standard specification as
opposed to something that is work in progress. The last thing we all need
is the scenario where UMA/EPF is approved in the Eclipse Foundation, only to
find out that it is based on a metamodel that is not a standard, since SPEM
2.0 has converged on a different metamodel. It is essential that we let the
SPEM 2.0 work follow its own natural course, without any extraneous pressure
that it has to meet such and such open source initiative.
I agree that we have a difference in opinion as to how far our work on SPEM
2.0 has progressed. IBM seems to be of the opinion that we are almost
there, whereas our view is that much work is ahead of us and it is uncertain
what final shape SPEM 2.0 will assume.
You and Per have coherently and rightly pointed out that the current
submission is based on UMA, primarily since this draft has been authored by
IBM to begin with. However, I would not go as far as assuming that the
submission in its current form is indeed going to become the adopted
standard. As you know, we are in the middle of an exhaustive analysis of the
latest submission to ensure the concepts contained therein can reasonably
model most methodologies and not just RUP. We would also like to map out a
clear migration path between SPEM 1.0 to this submission. We have not seen a
mapping from SPEM 1.1 to the current SPEM 2.0 submission. If you have done
so, we would greatly appreciate receiving the representation of RUP in SPEM
1.1, the migration and mapping document and the resultant representation in
the current SPEM 2.0 submission.
As an organization that focuses on process modeling without being aligned to
a specific methodology, we are getting rich feedback from across the SEPG
groups when we look for modeling examples to test the concepts in SPEM 2.0
submission. Perhaps we are meeting a different set of process modeling user
community. All of our experiences have pleasantly surprised us with the
knowledge of SPEM 1.1 out in the community. The process modeling space has
changed considerably over the past year or so. Recently, we have noticed a
lot of emphasis on software process modeling as vouched by IBM's renewed
interested in this area, Microsoft's initiatives through VSTS, Borland's
approach on process modeling and Ivar Jacobson's creation of EUP to name
just a few tool/methodology initiatives. On top of the user experiences and
scenarios we elicit, we will be keeping all this in mind as we analyze the
current SPEM 2.0 submission to ensure it meets the overall industry needs as
well as the SPEM 2.0 RFP (which we had helped author).
In our view, users would be overwhelmed with the complexity and steep
learning curve being introduced with many of the concepts (like task
descriptors) even in core concepts of the SPEM 2.0 submission. If there is
an impression that SPEM 1.1 is "ambiguous and hard to understand", I don't
see how we can justify the current SPEM 2.0 submission which significantly
compounds this complexity. Rather, we propose adopting the SPEM 1.1 which
has over the last year proven to be lightweight and inclusive, as the EPF
meta-model. We will keep updating the SPEM 2.0 submission as a progressive
elaboration of the SPEM 1.1, including the feedback from early adopters of
EPF. When SPEM 2.0 becomes the official standard the migration path
contained as part of the standard would ensure that the content is
seamlessly migrated to the newer standard. In our view going forward with
adopting an in-progress submission ignores the known risks at this time.
I sympathize with the fact that this course of action may create a dilemma
for IBM. We are not proposing that thousands of lines of code be thrown
out. What we are proposing is to either wait for SPEM 2.0 to be ratified
before the approval of EPF in the Eclipse Foundation, or alternatively, for
IBM to offer the commercial version of UMA/EPF (as it is currently doing
with RUP/RMC) to the market while developing a SPEM 1.1 version of EPF for
submission to the Eclipse Foundation.
Kamal.
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:dntacg$k7$1@news.eclipse.org...
> Hello.
>
>
>
> I do not see a problem. The current SPEM2 submissions and UMA/EPF are
> based on SPEM1.
>
>
>
> SPEM1 models can be represented in this new schema as we have proven by
> migrating RUP (consisting of thousands of model elements based on SPEM1)
> into this new format. So SPEM1 users get all of their familiar concepts.
> Hence, it is not unproven at all, but fully implemented and working. The
> specifications also address the SPEM requirements for supporting any kind
> of development process as well as defining a minimal set of concepts. We
> are just fixing the obvious and often criticized problems (and bugs) of
> SPEM1 and donating extensions such as method plug-ins and capability
> patterns that were a big success with our clients. Such extensions
> however have been packaged in the recent SPEM2 specification in a way that
> they are purely optional for an implementer. The proposed EPF tool
> implements these, but they are not mandatory for using the tool.
>
>
>
> The EPF project is about creating new innovations in process engineering
> as well as supporting best process engineering practices. We have been
> working on SPEM2 for one and a half years now. I organized bi-weekly
> calls for SPEM stakeholders and interested parties and have been to each
> and every OMG meeting talking to stakeholders, presenting our proposals,
> gathering feedback, and incorporating this into the specification as well
> as our proposed EPF tool. Our initial submission was supported by all but
> one organization that submitted a letter of intend for the SPEM2 RFP. The
> revised specification was supported unanimously by all submitters. After
> all this work I can say that the specification is on the right track of
> realizing what people want in the SPEM as well as the general
> development-process space. We therefore feel confident that this donation
> reflects the trends of the next generation of SPEM. Of course, both EPF
> and SPEM2 are work in progress, but we believe they should mutually
> improve each other with feedback from both communities (the list of
> contributors already seems to overlap significantly that this seems
> feasible and coordinatable). Thus, the EPF architecture is flexible enough
> to allow changes and incorporate updates. But, going back to SPEM1 and
> throwing away dozens of man years of development work and hundred
> thousands of lines of code towards this new direction and only
> concentrating on the old ways seems not to be a logical course of action
> to me at this point.
>
>
>
> As we have seen with the Eclipse EMF and UML2 projects, early
> implementations of proposed standards help not only with the verification
> and validation of the OMG specification, but it also facilitates early
> uptake and success of a specification. I think doing this with EPF and
> SPEM2 is just a logical conclusion of the lesson learned from these
> projects.
>
>
>
> Finally, I think you are bit inflating the success of SPEM1, the size of
> the communities you mentioned, as well as SPEM1 fitness for use. There is
> no implementation out there which completely or literally implements the
> specification. Therefore, content exchange between different SPEM1 tools
> using the SPEM1 XMI schema has never been implemented successfully by
> anyone. I claim that one reason for this is because SPEM1 was specified
> without the validation of an implementation. EPF has the chance to ensure
> that a SPEM standard is realized that is fully proven with an
> implementation (as actually requested in the SPEM2 RFP) as well as more
> importantly has the agreement, acceptance, and support by major players in
> the development process domain. Looking at the expertise of committers
> listed in the EPF proposal, I think we have a huge opportunity here to
> development something great for Eclipse as well as OMG (OMG being one of
> the EPF supporters as well).
>
>
>
> To confirm what I said here a quote from the official OMG SPEM 2 Request
> for Proposal document:
>
>
>
> "SPEM 1.1 saw low uptake. Since its issuance, few implementations have
> been released and it has not been recognized by industry analysts who also
> failed to recognize its relevance to the middleware market. There have
> been a number of low profiled or casual adopters of the specification as
> well as few commercial implementations. It is suspected that ease of
> adoption has been an issue, and some of the SPEM 1.1 semantics were
> ambiguous and hard to understand by adopters and hence not used in their
> practices. Submitters should analyze the limited success of SPEM 1.1, and
> attempt to address these issues in their solutions."
>
>
>
> Thanks and best regards,
> Peter Haumer.
>
>
> ____________________________________________________________ __
>
> Rational Software | IBM Software Group
> PETER HAUMER, Dr. rer. nat.
> RUP Development, Cupertino, CA
> Tel/Fax: +1 408 863-8716
> Email: <mailto:phaumer@us.ibm.com>
> ____________________________________________________________ __
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dn7f6l$aqa$1@news.eclipse.org...
>> Per
>>
>> In our experience there is a large community of users having a good
>> understanding of SPEM 1.1 which is the current OMG standard released
>> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
>> users use SPEM to model their processes applying the specification in
>> varying degrees as suited. Although this modeling may be done outside of
>> a tool context, it still enables them to use a methodology of their
>> choice or even create their own in-house methodology. One of the salient
>> features of SPEM 1.1 being its ability to model a process using any
>> methodology, was very deliberately introduced by the then working group
>> which as you know included such luminary orgs as Rational, IBM, Fujitsu,
>> Adaptive and Softeam amongst others. It is evident from reading SPEM 1.1
>> that the team was guided by the considerations to keep the spec
>> "inclusive" around methodologies and software development environments
>> yet keeping it relatively "lightweight". An example of this is the fact
>> that SPEM 1.1 does not have the concept of "tasks" at all.
>>
>>
>>
>> Without getting into too much detail about the on-going work in SPEM 2.0,
>> I would like to point out that we are in the stage wherein we are
>> requesting, gathering and applying modeling scenarios from the process
>> modeling community of users, including Borland. This also means defining
>> fundamental concepts without favoring any specific approach. This
>> exercise is going very well and we reiterate our call to modeling users
>> (who may or may not have used SPEM 1.1) to get in touch with me or any
>> other members of the SPEM 2.0 working group to contribute their
>> scenarios. Note that one does not have to be an OMG member to raise
>> issues with specifications and can do so by going to
>> http://www.omg.org/technology/issuesform.htm .
>>
>>
>>
>> As far as your comments about SPEM 1.1, I would just have these
>> clarifications:
>>
>> 1. SPEM 1.1 is the current standard from OMG released January 2005. It is
>> not correct to characterize it as an old standard.
>>
>> 2. Most organizations adopting SPEM 1.1 move forward from a
>> "no-standards" approach to modeling to a methodology agnostic and
>> industry standard approach to modeling.
>>
>> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
>> SPEM 2.0 specification are related to re-using process elements and
>> process workflow, support for process enactment, support for process
>> metrics, provision of greater guidance for terms used, which came to
>> light with adoption by SEPG process teams/enterprise.
>>
>> 4. Though it is true that there are limited tools built on SPEM 1.1 I
>> don't know of any tools built for SPEM 2.0 (its not possible since the
>> standard is still in-progress !)
>>
>>
>>
>> Per, our position still remains that instead of using seemingly
>> heavyweight and untested concepts requiring a steep learning curve which
>> make up UMA or waiting for SPEM 2.0 which is a while away, we start
>> process content creation and best practices definition using SPEM 1.1.
>> Moreover, as Ricardo mentioned in his presentation on the 6th of December
>> the entry of BUP content is still not complete. We have already
>> volunteered our help in moving all donated content, including BUP to SPEM
>> 1.1. We see a huge risk in building tools/content based on a meta-model
>> that is not an industry standard. Furthermore instead of defining
>> alternate meta-models we should let OMG with its proven standards
>> creation process, create industry standard meta-models which we can then
>> use as part of EPF.
>>
>>
>>
>> Kamal.
>>
>>
>>
>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>> news:dmqnnb$a25$1@news.eclipse.org...
>>> Hi Kamal,
>>>
>>> you are making a good point that it is uncertain when SPEM 2.0 will
>>> become a standard. The current timeline indicates a stable proposal by
>>> March 2006, and then it typically takes 1-2 years for it to become a
>>> final standard. So, based on how this evolves in the next few months, we
>>> need to determine whether it makes sense to support SPEM 2.0 for the
>>> release of EPF v1.0.
>>>
>>> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
>>> we should still look at whether there are certain aspects of the current
>>> spec for SPEM 2.0 that we should support before it is a formal standard.
>>> As an example, Borland (Karl Frank) made a good case for changes to the
>>> meta-model that were required to provide good support for some of the
>>> agilistas views, allowing you to e.g. produce a process without having
>>> tasks. Many agilistas have a hot button around specifying tasks, and we
>>> should respect that. (My personal view is that the tasks are still
>>> useful as descriptive background material, and should not be interpreted
>>> as prescriptive guidance, but that is not here or there).
>>>
>>> I think this is an area where we need to listen to the community and
>>> hear what capabilities people would like to see in the process
>>> engineering framework, and then from that determine how to evolve the
>>> metamodel. So, I hope that the EPF projetc will lead to more input and
>>> consensus around the SPEM 2.0 effort.
>>>
>>> Also, I do not think the key thing is when a standard is a final
>>> standard, but to assess when it is stable enough to dare to do
>>> investments towards.
>>>
>>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>>> already specified deficiencies (see the OMG ADTF presentation from the
>>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has
>>> limited practical support (Osellus and IBM are possibly the only 2
>>> companies that have built tools around it... :) ). So, moving back to
>>> SPEM 1.1, rather than something very close to SPEM 2.0, would in my mind
>>> create a big cost in changing the tools to support old stuff that we
>>> know is less good than what is close to SPEM 2.0, introducing a lot of
>>> deficiencies we have worked hard to remove, while provide very few
>>> benefits. The cost of migrating the content is negligent relative to the
>>> move back in capabilities and cost of code changes....
>>>
>>> Cheers
>>>
>>> /Per
>>>
>>>
>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>> news:dm2f6o$jrs$1@news.eclipse.org...
>>>> Hi Per
>>>>
>>>>
>>>>
>>>> SPEM 2.0 is in early stages of a long standardization process and it
>>>> could be over a year before a final SPEM 2.0 specification is
>>>> available. Moreover this final specification would most likely be
>>>> different from this current joint-submission which is a
>>>> work-in-progress. Based on this I feel its best if we put our efforts
>>>> in creating content based on the current SPEM 1.1 specification.
>>>> Osellus volunteers to convert any existing content, including what you
>>>> may have, into the SPEM 1.1 format.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Kamal.
>>>>
>>>>
>>>>
>>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>>> Hi Kamal,
>>>>>
>>>>> I agree with you that we should follow standards, and that is a part
>>>>> of the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>>>> content IBM is suggesting to contribute is based on a meta-model that
>>>>> is an evolution of SPEM 1.1, and pretty close to current SPEM 2.0
>>>>> proposal. I hope that SPEM 2.0 will be stable enough soon enough so we
>>>>> can support SPEM 2.0 in the first release of EPF v1.0. But to really
>>>>> committ to that, we need to better understand the impact, understand
>>>>> who is willing to work on it, and then plan accordingly.
>>>>>
>>>>> Any volunteers?
>>>>>
>>>>> Cheers
>>>>>
>>>>> /Per
>>>>>
>>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter
>>>>>> and co-submitter of SPEM 2.0 submission, we at Osellus are very
>>>>>> excited to see this focus on software process modeling and the
>>>>>> potential of EPF to further this cause. SPEM 1.1 is a widely adopted
>>>>>> standard from OMG and we have come across many teams utilizing this
>>>>>> standard in modeling software processes across different
>>>>>> methodologies. We would propose that EPF follow this widely adopted
>>>>>> industry standard as the meta-model to create process modeling
>>>>>> content. This will serve two key benefits. Firstly, it will ensure
>>>>>> that the models conform to an existing non-proprietary industry
>>>>>> standard which is more useable with minimum training. Secondly, it
>>>>>> will serve as an excellent and very timely feedback mechanism to
>>>>>> contribute to the evolving SPEM 2.0 submission channeled through many
>>>>>> SPEM 2.0 co-submitters who are already contributors in EPF. Note that
>>>>>> as part of SPEM 2.0 RFP one of the tasks we are required to do is the
>>>>>> migration of all content from SPEM1.1 to SPEM 2.0. This will
>>>>>> automatically ensure that none of the contributed process modeling
>>>>>> content is wasted. As part of this project we should not interfere in
>>>>>> the standard setting process which a standards body like OMG's excels
>>>>>> in doing, rather we should adopt industry standards and build content
>>>>>> and tool-ware around these standards.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kamal Ahluwalia
>>>>>>
>>>>>> Osellus Inc.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #70795 is a reply to message #70744] |
Thu, 05 January 2006 22:50 |
Sigurd Hopen
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Very interesting discussion. And I can easily see this from both sides :-)
since I once was part of the RUP team, and now working on defining other
processes / methodologies mainly based on the 2003 version of the RUP meta
model (both in-house for a large s/w development enterprise, and commercial
methods following the more traditional line of thinking).
Over the last year or two, I have defined a commercial (and significant)
project management method (following the more traditional lifecycle
definition) on the RUP2003 meta model, creating a plug-in to replace 2/3 of
RUPs PM discipline. As you know, the 2003 version of the RUP meta model is
fairly close to SPEM 1.1. (Yes, I said _fairly_ :-o).
I have made some observations on SPEM 1.1's appliciability to modelling
other methodologies through this work, that I'm happy to discuss with
anyone intersted, but I don't want to add to this already exciting e-mail
thread other than saying to Peter et al.: "I think the "old" standard is in
use in more places than you're aware of :-)". But org's frequently keep
quiet, they don't easily share their experience. Writing experience reports
or case studies don't generate revenue.... Usually !
I really look forward to see some of you in Atlanta in January, where we can
get a chance to discuss these things face-to-face.
/Sigurd Hopen
2-Pro Mentor, Norway
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dp1big$ohg$1@utils.eclipse.org...
> Peter, Per
>
> As an early adopter of SPEM and a co-submitter of SPEM 2.0 we are excited
> that we are now discussing which version of the SPEM standard to adopt as
> the exemplary meta-model for EPF, as opposed to adopting a proprietary UMA
> meta-model.
>
> To reiterate, and for further clarification, I and my colleagues at
> Osellus are in favor of pursuing improvements in SPEM, in the form of SPEM
> 2.0 and subsequent versions of this specification. We are simply saying
> that SPEM 2.0 is not a standard yet, as is SPEM 1.1. It would make sense
> to base a new contribution to the open source community on a standard
> specification as opposed to something that is work in progress. The last
> thing we all need is the scenario where UMA/EPF is approved in the Eclipse
> Foundation, only to find out that it is based on a metamodel that is not a
> standard, since SPEM 2.0 has converged on a different metamodel. It is
> essential that we let the SPEM 2.0 work follow its own natural course,
> without any extraneous pressure that it has to meet such and such open
> source initiative.
>
> I agree that we have a difference in opinion as to how far our work on
> SPEM 2.0 has progressed. IBM seems to be of the opinion that we are
> almost there, whereas our view is that much work is ahead of us and it is
> uncertain what final shape SPEM 2.0 will assume.
>
> You and Per have coherently and rightly pointed out that the current
> submission is based on UMA, primarily since this draft has been authored
> by IBM to begin with. However, I would not go as far as assuming that the
> submission in its current form is indeed going to become the adopted
> standard. As you know, we are in the middle of an exhaustive analysis of
> the latest submission to ensure the concepts contained therein can
> reasonably model most methodologies and not just RUP. We would also like
> to map out a clear migration path between SPEM 1.0 to this submission. We
> have not seen a mapping from SPEM 1.1 to the current SPEM 2.0 submission.
> If you have done so, we would greatly appreciate receiving the
> representation of RUP in SPEM 1.1, the migration and mapping document and
> the resultant representation in the current SPEM 2.0 submission.
>
> As an organization that focuses on process modeling without being aligned
> to a specific methodology, we are getting rich feedback from across the
> SEPG groups when we look for modeling examples to test the concepts in
> SPEM 2.0 submission. Perhaps we are meeting a different set of process
> modeling user community. All of our experiences have pleasantly surprised
> us with the knowledge of SPEM 1.1 out in the community. The process
> modeling space has changed considerably over the past year or so.
> Recently, we have noticed a lot of emphasis on software process modeling
> as vouched by IBM's renewed interested in this area, Microsoft's
> initiatives through VSTS, Borland's approach on process modeling and Ivar
> Jacobson's creation of EUP to name just a few tool/methodology
> initiatives. On top of the user experiences and scenarios we elicit, we
> will be keeping all this in mind as we analyze the current SPEM 2.0
> submission to ensure it meets the overall industry needs as well as the
> SPEM 2.0 RFP (which we had helped author).
>
> In our view, users would be overwhelmed with the complexity and steep
> learning curve being introduced with many of the concepts (like task
> descriptors) even in core concepts of the SPEM 2.0 submission. If there is
> an impression that SPEM 1.1 is "ambiguous and hard to understand", I don't
> see how we can justify the current SPEM 2.0 submission which significantly
> compounds this complexity. Rather, we propose adopting the SPEM 1.1 which
> has over the last year proven to be lightweight and inclusive, as the EPF
> meta-model. We will keep updating the SPEM 2.0 submission as a progressive
> elaboration of the SPEM 1.1, including the feedback from early adopters of
> EPF. When SPEM 2.0 becomes the official standard the migration path
> contained as part of the standard would ensure that the content is
> seamlessly migrated to the newer standard. In our view going forward with
> adopting an in-progress submission ignores the known risks at this time.
>
> I sympathize with the fact that this course of action may create a dilemma
> for IBM. We are not proposing that thousands of lines of code be thrown
> out. What we are proposing is to either wait for SPEM 2.0 to be ratified
> before the approval of EPF in the Eclipse Foundation, or alternatively,
> for IBM to offer the commercial version of UMA/EPF (as it is currently
> doing with RUP/RMC) to the market while developing a SPEM 1.1 version of
> EPF for submission to the Eclipse Foundation.
>
> Kamal.
>
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:dntacg$k7$1@news.eclipse.org...
>> Hello.
>>
>>
>>
>> I do not see a problem. The current SPEM2 submissions and UMA/EPF are
>> based on SPEM1.
>>
>>
>>
>> SPEM1 models can be represented in this new schema as we have proven by
>> migrating RUP (consisting of thousands of model elements based on SPEM1)
>> into this new format. So SPEM1 users get all of their familiar concepts.
>> Hence, it is not unproven at all, but fully implemented and working. The
>> specifications also address the SPEM requirements for supporting any kind
>> of development process as well as defining a minimal set of concepts. We
>> are just fixing the obvious and often criticized problems (and bugs) of
>> SPEM1 and donating extensions such as method plug-ins and capability
>> patterns that were a big success with our clients. Such extensions
>> however have been packaged in the recent SPEM2 specification in a way
>> that they are purely optional for an implementer. The proposed EPF tool
>> implements these, but they are not mandatory for using the tool.
>>
>>
>>
>> The EPF project is about creating new innovations in process engineering
>> as well as supporting best process engineering practices. We have been
>> working on SPEM2 for one and a half years now. I organized bi-weekly
>> calls for SPEM stakeholders and interested parties and have been to each
>> and every OMG meeting talking to stakeholders, presenting our proposals,
>> gathering feedback, and incorporating this into the specification as well
>> as our proposed EPF tool. Our initial submission was supported by all
>> but one organization that submitted a letter of intend for the SPEM2 RFP.
>> The revised specification was supported unanimously by all submitters.
>> After all this work I can say that the specification is on the right
>> track of realizing what people want in the SPEM as well as the general
>> development-process space. We therefore feel confident that this
>> donation reflects the trends of the next generation of SPEM. Of course,
>> both EPF and SPEM2 are work in progress, but we believe they should
>> mutually improve each other with feedback from both communities (the list
>> of contributors already seems to overlap significantly that this seems
>> feasible and coordinatable). Thus, the EPF architecture is flexible
>> enough to allow changes and incorporate updates. But, going back to
>> SPEM1 and throwing away dozens of man years of development work and
>> hundred thousands of lines of code towards this new direction and only
>> concentrating on the old ways seems not to be a logical course of action
>> to me at this point.
>>
>>
>>
>> As we have seen with the Eclipse EMF and UML2 projects, early
>> implementations of proposed standards help not only with the verification
>> and validation of the OMG specification, but it also facilitates early
>> uptake and success of a specification. I think doing this with EPF and
>> SPEM2 is just a logical conclusion of the lesson learned from these
>> projects.
>>
>>
>>
>> Finally, I think you are bit inflating the success of SPEM1, the size of
>> the communities you mentioned, as well as SPEM1 fitness for use. There
>> is no implementation out there which completely or literally implements
>> the specification. Therefore, content exchange between different SPEM1
>> tools using the SPEM1 XMI schema has never been implemented successfully
>> by anyone. I claim that one reason for this is because SPEM1 was
>> specified without the validation of an implementation. EPF has the
>> chance to ensure that a SPEM standard is realized that is fully proven
>> with an implementation (as actually requested in the SPEM2 RFP) as well
>> as more importantly has the agreement, acceptance, and support by major
>> players in the development process domain. Looking at the expertise of
>> committers listed in the EPF proposal, I think we have a huge opportunity
>> here to development something great for Eclipse as well as OMG (OMG being
>> one of the EPF supporters as well).
>>
>>
>>
>> To confirm what I said here a quote from the official OMG SPEM 2 Request
>> for Proposal document:
>>
>>
>>
>> "SPEM 1.1 saw low uptake. Since its issuance, few implementations have
>> been released and it has not been recognized by industry analysts who
>> also failed to recognize its relevance to the middleware market. There
>> have been a number of low profiled or casual adopters of the
>> specification as well as few commercial implementations. It is suspected
>> that ease of adoption has been an issue, and some of the SPEM 1.1
>> semantics were ambiguous and hard to understand by adopters and hence not
>> used in their practices. Submitters should analyze the limited success of
>> SPEM 1.1, and attempt to address these issues in their solutions."
>>
>>
>>
>> Thanks and best regards,
>> Peter Haumer.
>>
>>
>> ____________________________________________________________ __
>>
>> Rational Software | IBM Software Group
>> PETER HAUMER, Dr. rer. nat.
>> RUP Development, Cupertino, CA
>> Tel/Fax: +1 408 863-8716
>> Email: <mailto:phaumer@us.ibm.com>
>> ____________________________________________________________ __
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dn7f6l$aqa$1@news.eclipse.org...
>>> Per
>>>
>>> In our experience there is a large community of users having a good
>>> understanding of SPEM 1.1 which is the current OMG standard released
>>> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
>>> users use SPEM to model their processes applying the specification in
>>> varying degrees as suited. Although this modeling may be done outside of
>>> a tool context, it still enables them to use a methodology of their
>>> choice or even create their own in-house methodology. One of the salient
>>> features of SPEM 1.1 being its ability to model a process using any
>>> methodology, was very deliberately introduced by the then working group
>>> which as you know included such luminary orgs as Rational, IBM, Fujitsu,
>>> Adaptive and Softeam amongst others. It is evident from reading SPEM 1.1
>>> that the team was guided by the considerations to keep the spec
>>> "inclusive" around methodologies and software development environments
>>> yet keeping it relatively "lightweight". An example of this is the fact
>>> that SPEM 1.1 does not have the concept of "tasks" at all.
>>>
>>>
>>>
>>> Without getting into too much detail about the on-going work in SPEM
>>> 2.0, I would like to point out that we are in the stage wherein we are
>>> requesting, gathering and applying modeling scenarios from the process
>>> modeling community of users, including Borland. This also means defining
>>> fundamental concepts without favoring any specific approach. This
>>> exercise is going very well and we reiterate our call to modeling users
>>> (who may or may not have used SPEM 1.1) to get in touch with me or any
>>> other members of the SPEM 2.0 working group to contribute their
>>> scenarios. Note that one does not have to be an OMG member to raise
>>> issues with specifications and can do so by going to
>>> http://www.omg.org/technology/issuesform.htm .
>>>
>>>
>>>
>>> As far as your comments about SPEM 1.1, I would just have these
>>> clarifications:
>>>
>>> 1. SPEM 1.1 is the current standard from OMG released January 2005. It
>>> is not correct to characterize it as an old standard.
>>>
>>> 2. Most organizations adopting SPEM 1.1 move forward from a
>>> "no-standards" approach to modeling to a methodology agnostic and
>>> industry standard approach to modeling.
>>>
>>> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for
>>> the SPEM 2.0 specification are related to re-using process elements and
>>> process workflow, support for process enactment, support for process
>>> metrics, provision of greater guidance for terms used, which came to
>>> light with adoption by SEPG process teams/enterprise.
>>>
>>> 4. Though it is true that there are limited tools built on SPEM 1.1 I
>>> don't know of any tools built for SPEM 2.0 (its not possible since the
>>> standard is still in-progress !)
>>>
>>>
>>>
>>> Per, our position still remains that instead of using seemingly
>>> heavyweight and untested concepts requiring a steep learning curve which
>>> make up UMA or waiting for SPEM 2.0 which is a while away, we start
>>> process content creation and best practices definition using SPEM 1.1.
>>> Moreover, as Ricardo mentioned in his presentation on the 6th of
>>> December the entry of BUP content is still not complete. We have already
>>> volunteered our help in moving all donated content, including BUP to
>>> SPEM 1.1. We see a huge risk in building tools/content based on a
>>> meta-model that is not an industry standard. Furthermore instead of
>>> defining alternate meta-models we should let OMG with its proven
>>> standards creation process, create industry standard meta-models which
>>> we can then use as part of EPF.
>>>
>>>
>>>
>>> Kamal.
>>>
>>>
>>>
>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>> news:dmqnnb$a25$1@news.eclipse.org...
>>>> Hi Kamal,
>>>>
>>>> you are making a good point that it is uncertain when SPEM 2.0 will
>>>> become a standard. The current timeline indicates a stable proposal by
>>>> March 2006, and then it typically takes 1-2 years for it to become a
>>>> final standard. So, based on how this evolves in the next few months,
>>>> we need to determine whether it makes sense to support SPEM 2.0 for the
>>>> release of EPF v1.0.
>>>>
>>>> If we find that it does not make sense to support SPEM 2.0 for EPF
>>>> v1.0, we should still look at whether there are certain aspects of the
>>>> current spec for SPEM 2.0 that we should support before it is a formal
>>>> standard. As an example, Borland (Karl Frank) made a good case for
>>>> changes to the meta-model that were required to provide good support
>>>> for some of the agilistas views, allowing you to e.g. produce a process
>>>> without having tasks. Many agilistas have a hot button around
>>>> specifying tasks, and we should respect that. (My personal view is that
>>>> the tasks are still useful as descriptive background material, and
>>>> should not be interpreted as prescriptive guidance, but that is not
>>>> here or there).
>>>>
>>>> I think this is an area where we need to listen to the community and
>>>> hear what capabilities people would like to see in the process
>>>> engineering framework, and then from that determine how to evolve the
>>>> metamodel. So, I hope that the EPF projetc will lead to more input and
>>>> consensus around the SPEM 2.0 effort.
>>>>
>>>> Also, I do not think the key thing is when a standard is a final
>>>> standard, but to assess when it is stable enough to dare to do
>>>> investments towards.
>>>>
>>>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>>>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>>>> already specified deficiencies (see the OMG ADTF presentation from the
>>>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has
>>>> limited practical support (Osellus and IBM are possibly the only 2
>>>> companies that have built tools around it... :) ). So, moving back to
>>>> SPEM 1.1, rather than something very close to SPEM 2.0, would in my
>>>> mind create a big cost in changing the tools to support old stuff that
>>>> we know is less good than what is close to SPEM 2.0, introducing a lot
>>>> of deficiencies we have worked hard to remove, while provide very few
>>>> benefits. The cost of migrating the content is negligent relative to
>>>> the move back in capabilities and cost of code changes....
>>>>
>>>> Cheers
>>>>
>>>> /Per
>>>>
>>>>
>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>> news:dm2f6o$jrs$1@news.eclipse.org...
>>>>> Hi Per
>>>>>
>>>>>
>>>>>
>>>>> SPEM 2.0 is in early stages of a long standardization process and it
>>>>> could be over a year before a final SPEM 2.0 specification is
>>>>> available. Moreover this final specification would most likely be
>>>>> different from this current joint-submission which is a
>>>>> work-in-progress. Based on this I feel its best if we put our efforts
>>>>> in creating content based on the current SPEM 1.1 specification.
>>>>> Osellus volunteers to convert any existing content, including what you
>>>>> may have, into the SPEM 1.1 format.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kamal.
>>>>>
>>>>>
>>>>>
>>>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>>>> Hi Kamal,
>>>>>>
>>>>>> I agree with you that we should follow standards, and that is a part
>>>>>> of the plan. SPEM 2.0, as you know, is still evolving. The tooling
>>>>>> and content IBM is suggesting to contribute is based on a meta-model
>>>>>> that is an evolution of SPEM 1.1, and pretty close to current SPEM
>>>>>> 2.0 proposal. I hope that SPEM 2.0 will be stable enough soon enough
>>>>>> so we can support SPEM 2.0 in the first release of EPF v1.0. But to
>>>>>> really committ to that, we need to better understand the impact,
>>>>>> understand who is willing to work on it, and then plan accordingly.
>>>>>>
>>>>>> Any volunteers?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> /Per
>>>>>>
>>>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter
>>>>>>> and co-submitter of SPEM 2.0 submission, we at Osellus are very
>>>>>>> excited to see this focus on software process modeling and the
>>>>>>> potential of EPF to further this cause. SPEM 1.1 is a widely adopted
>>>>>>> standard from OMG and we have come across many teams utilizing this
>>>>>>> standard in modeling software processes across different
>>>>>>> methodologies. We would propose that EPF follow this widely adopted
>>>>>>> industry standard as the meta-model to create process modeling
>>>>>>> content. This will serve two key benefits. Firstly, it will ensure
>>>>>>> that the models conform to an existing non-proprietary industry
>>>>>>> standard which is more useable with minimum training. Secondly, it
>>>>>>> will serve as an excellent and very timely feedback mechanism to
>>>>>>> contribute to the evolving SPEM 2.0 submission channeled through
>>>>>>> many SPEM 2.0 co-submitters who are already contributors in EPF.
>>>>>>> Note that as part of SPEM 2.0 RFP one of the tasks we are required
>>>>>>> to do is the migration of all content from SPEM1.1 to SPEM 2.0. This
>>>>>>> will automatically ensure that none of the contributed process
>>>>>>> modeling content is wasted. As part of this project we should not
>>>>>>> interfere in the standard setting process which a standards body
>>>>>>> like OMG's excels in doing, rather we should adopt industry
>>>>>>> standards and build content and tool-ware around these standards.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kamal Ahluwalia
>>>>>>>
>>>>>>> Osellus Inc.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #599652 is a reply to message #69987] |
Tue, 22 November 2005 22:55 |
Per Kroll
Messages: 60
Registered: July 2009 |
Member |
|
|
Hi Kamal,
I agree with you that we should follow standards, and that is a part of the
plan. SPEM 2.0, as you know, is still evolving. The tooling and content IBM
is suggesting to contribute is based on a meta-model that is an evolution of
SPEM 1.1, and pretty close to current SPEM 2.0 proposal. I hope that SPEM
2.0 will be stable enough soon enough so we can support SPEM 2.0 in the
first release of EPF v1.0. But to really committ to that, we need to better
understand the impact, understand who is willing to work on it, and then
plan accordingly.
Any volunteers?
Cheers
/Per
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dlt0vu$sa4$1@news.eclipse.org...
> As an early Software Process Engineering Meta-model (SPEM) adopter and
> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to see
> this focus on software process modeling and the potential of EPF to
> further this cause. SPEM 1.1 is a widely adopted standard from OMG and we
> have come across many teams utilizing this standard in modeling software
> processes across different methodologies. We would propose that EPF follow
> this widely adopted industry standard as the meta-model to create process
> modeling content. This will serve two key benefits. Firstly, it will
> ensure that the models conform to an existing non-proprietary industry
> standard which is more useable with minimum training. Secondly, it will
> serve as an excellent and very timely feedback mechanism to contribute to
> the evolving SPEM 2.0 submission channeled through many SPEM 2.0
> co-submitters who are already contributors in EPF. Note that as part of
> SPEM 2.0 RFP one of the tasks we are required to do is the migration of
> all content from SPEM1.1 to SPEM 2.0. This will automatically ensure that
> none of the contributed process modeling content is wasted. As part of
> this project we should not interfere in the standard setting process which
> a standards body like OMG's excels in doing, rather we should adopt
> industry standards and build content and tool-ware around these standards.
>
>
>
> Thanks,
>
>
>
> Kamal Ahluwalia
>
> Osellus Inc.
>
>
|
|
|
| Re: EPF Metamodel [message #599679 is a reply to message #70067] |
Wed, 23 November 2005 19:16 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Hi Per
SPEM 2.0 is in early stages of a long standardization process and it could
be over a year before a final SPEM 2.0 specification is available. Moreover
this final specification would most likely be different from this current
joint-submission which is a work-in-progress. Based on this I feel its best
if we put our efforts in creating content based on the current SPEM 1.1
specification. Osellus volunteers to convert any existing content, including
what you may have, into the SPEM 1.1 format.
Thanks,
Kamal.
"Per Kroll" <pkroll@us.ibm.com> wrote in message
news:dm07lb$bcg$1@news.eclipse.org...
> Hi Kamal,
>
> I agree with you that we should follow standards, and that is a part of
> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
> content IBM is suggesting to contribute is based on a meta-model that is
> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal. I
> hope that SPEM 2.0 will be stable enough soon enough so we can support
> SPEM 2.0 in the first release of EPF v1.0. But to really committ to that,
> we need to better understand the impact, understand who is willing to work
> on it, and then plan accordingly.
>
> Any volunteers?
>
> Cheers
>
> /Per
>
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dlt0vu$sa4$1@news.eclipse.org...
>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>> see this focus on software process modeling and the potential of EPF to
>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and we
>> have come across many teams utilizing this standard in modeling software
>> processes across different methodologies. We would propose that EPF
>> follow this widely adopted industry standard as the meta-model to create
>> process modeling content. This will serve two key benefits. Firstly, it
>> will ensure that the models conform to an existing non-proprietary
>> industry standard which is more useable with minimum training. Secondly,
>> it will serve as an excellent and very timely feedback mechanism to
>> contribute to the evolving SPEM 2.0 submission channeled through many
>> SPEM 2.0 co-submitters who are already contributors in EPF. Note that as
>> part of SPEM 2.0 RFP one of the tasks we are required to do is the
>> migration of all content from SPEM1.1 to SPEM 2.0. This will
>> automatically ensure that none of the contributed process modeling
>> content is wasted. As part of this project we should not interfere in the
>> standard setting process which a standards body like OMG's excels in
>> doing, rather we should adopt industry standards and build content and
>> tool-ware around these standards.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kamal Ahluwalia
>>
>> Osellus Inc.
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #599821 is a reply to message #70126] |
Sat, 03 December 2005 00:09 |
Per Kroll
Messages: 60
Registered: July 2009 |
Member |
|
|
Hi Kamal,
you are making a good point that it is uncertain when SPEM 2.0 will become a
standard. The current timeline indicates a stable proposal by March 2006,
and then it typically takes 1-2 years for it to become a final standard. So,
based on how this evolves in the next few months, we need to determine
whether it makes sense to support SPEM 2.0 for the release of EPF v1.0.
If we find that it does not make sense to support SPEM 2.0 for EPF v1.0, we
should still look at whether there are certain aspects of the current spec
for SPEM 2.0 that we should support before it is a formal standard. As an
example, Borland (Karl Frank) made a good case for changes to the meta-model
that were required to provide good support for some of the agilistas views,
allowing you to e.g. produce a process without having tasks. Many agilistas
have a hot button around specifying tasks, and we should respect that. (My
personal view is that the tasks are still useful as descriptive background
material, and should not be interpreted as prescriptive guidance, but that
is not here or there).
I think this is an area where we need to listen to the community and hear
what capabilities people would like to see in the process engineering
framework, and then from that determine how to evolve the metamodel. So, I
hope that the EPF projetc will lead to more input and consensus around the
SPEM 2.0 effort.
Also, I do not think the key thing is when a standard is a final standard,
but to assess when it is stable enough to dare to do investments towards.
Regarding your proposal to move back to SPEM 1.1, I see mainly disadvantages
in that, and few advantages. SPEM 1.1 has a long list of already specified
deficiencies (see the OMG ADTF presentation from the SPEM team for a list),
which we want to avoid. SPEM v1.1 also has limited practical support
(Osellus and IBM are possibly the only 2 companies that have built tools
around it... :) ). So, moving back to SPEM 1.1, rather than something very
close to SPEM 2.0, would in my mind create a big cost in changing the tools
to support old stuff that we know is less good than what is close to SPEM
2.0, introducing a lot of deficiencies we have worked hard to remove, while
provide very few benefits. The cost of migrating the content is negligent
relative to the move back in capabilities and cost of code changes....
Cheers
/Per
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dm2f6o$jrs$1@news.eclipse.org...
> Hi Per
>
>
>
> SPEM 2.0 is in early stages of a long standardization process and it could
> be over a year before a final SPEM 2.0 specification is available.
> Moreover this final specification would most likely be different from this
> current joint-submission which is a work-in-progress. Based on this I
> feel its best if we put our efforts in creating content based on the
> current SPEM 1.1 specification. Osellus volunteers to convert any existing
> content, including what you may have, into the SPEM 1.1 format.
>
>
>
> Thanks,
>
> Kamal.
>
>
>
> "Per Kroll" <pkroll@us.ibm.com> wrote in message
> news:dm07lb$bcg$1@news.eclipse.org...
>> Hi Kamal,
>>
>> I agree with you that we should follow standards, and that is a part of
>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>> content IBM is suggesting to contribute is based on a meta-model that is
>> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal.
>> I hope that SPEM 2.0 will be stable enough soon enough so we can support
>> SPEM 2.0 in the first release of EPF v1.0. But to really committ to that,
>> we need to better understand the impact, understand who is willing to
>> work on it, and then plan accordingly.
>>
>> Any volunteers?
>>
>> Cheers
>>
>> /Per
>>
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dlt0vu$sa4$1@news.eclipse.org...
>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>> see this focus on software process modeling and the potential of EPF to
>>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and
>>> we have come across many teams utilizing this standard in modeling
>>> software processes across different methodologies. We would propose that
>>> EPF follow this widely adopted industry standard as the meta-model to
>>> create process modeling content. This will serve two key benefits.
>>> Firstly, it will ensure that the models conform to an existing
>>> non-proprietary industry standard which is more useable with minimum
>>> training. Secondly, it will serve as an excellent and very timely
>>> feedback mechanism to contribute to the evolving SPEM 2.0 submission
>>> channeled through many SPEM 2.0 co-submitters who are already
>>> contributors in EPF. Note that as part of SPEM 2.0 RFP one of the tasks
>>> we are required to do is the migration of all content from SPEM1.1 to
>>> SPEM 2.0. This will automatically ensure that none of the contributed
>>> process modeling content is wasted. As part of this project we should
>>> not interfere in the standard setting process which a standards body
>>> like OMG's excels in doing, rather we should adopt industry standards
>>> and build content and tool-ware around these standards.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Kamal Ahluwalia
>>>
>>> Osellus Inc.
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #599858 is a reply to message #70462] |
Wed, 07 December 2005 20:03 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Per
In our experience there is a large community of users having a good
understanding of SPEM 1.1 which is the current OMG standard released January
2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these users use
SPEM to model their processes applying the specification in varying degrees
as suited. Although this modeling may be done outside of a tool context, it
still enables them to use a methodology of their choice or even create their
own in-house methodology. One of the salient features of SPEM 1.1 being its
ability to model a process using any methodology, was very deliberately
introduced by the then working group which as you know included such
luminary orgs as Rational, IBM, Fujitsu, Adaptive and Softeam amongst
others. It is evident from reading SPEM 1.1 that the team was guided by the
considerations to keep the spec "inclusive" around methodologies and
software development environments yet keeping it relatively "lightweight".
An example of this is the fact that SPEM 1.1 does not have the concept of
"tasks" at all.
Without getting into too much detail about the on-going work in SPEM 2.0, I
would like to point out that we are in the stage wherein we are requesting,
gathering and applying modeling scenarios from the process modeling
community of users, including Borland. This also means defining fundamental
concepts without favoring any specific approach. This exercise is going very
well and we reiterate our call to modeling users (who may or may not have
used SPEM 1.1) to get in touch with me or any other members of the SPEM 2.0
working group to contribute their scenarios. Note that one does not have to
be an OMG member to raise issues with specifications and can do so by going
to http://www.omg.org/technology/issuesform.htm .
As far as your comments about SPEM 1.1, I would just have these
clarifications:
1. SPEM 1.1 is the current standard from OMG released January 2005. It is
not correct to characterize it as an old standard.
2. Most organizations adopting SPEM 1.1 move forward from a "no-standards"
approach to modeling to a methodology agnostic and industry standard
approach to modeling.
3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
SPEM 2.0 specification are related to re-using process elements and process
workflow, support for process enactment, support for process metrics,
provision of greater guidance for terms used, which came to light with
adoption by SEPG process teams/enterprise.
4. Though it is true that there are limited tools built on SPEM 1.1 I don't
know of any tools built for SPEM 2.0 (its not possible since the standard is
still in-progress !)
Per, our position still remains that instead of using seemingly heavyweight
and untested concepts requiring a steep learning curve which make up UMA or
waiting for SPEM 2.0 which is a while away, we start process content
creation and best practices definition using SPEM 1.1. Moreover, as Ricardo
mentioned in his presentation on the 6th of December the entry of BUP
content is still not complete. We have already volunteered our help in
moving all donated content, including BUP to SPEM 1.1. We see a huge risk in
building tools/content based on a meta-model that is not an industry
standard. Furthermore instead of defining alternate meta-models we should
let OMG with its proven standards creation process, create industry standard
meta-models which we can then use as part of EPF.
Kamal.
"Per Kroll" <pkroll@us.ibm.com> wrote in message
news:dmqnnb$a25$1@news.eclipse.org...
> Hi Kamal,
>
> you are making a good point that it is uncertain when SPEM 2.0 will become
> a standard. The current timeline indicates a stable proposal by March
> 2006, and then it typically takes 1-2 years for it to become a final
> standard. So, based on how this evolves in the next few months, we need to
> determine whether it makes sense to support SPEM 2.0 for the release of
> EPF v1.0.
>
> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
> we should still look at whether there are certain aspects of the current
> spec for SPEM 2.0 that we should support before it is a formal standard.
> As an example, Borland (Karl Frank) made a good case for changes to the
> meta-model that were required to provide good support for some of the
> agilistas views, allowing you to e.g. produce a process without having
> tasks. Many agilistas have a hot button around specifying tasks, and we
> should respect that. (My personal view is that the tasks are still useful
> as descriptive background material, and should not be interpreted as
> prescriptive guidance, but that is not here or there).
>
> I think this is an area where we need to listen to the community and hear
> what capabilities people would like to see in the process engineering
> framework, and then from that determine how to evolve the metamodel. So, I
> hope that the EPF projetc will lead to more input and consensus around the
> SPEM 2.0 effort.
>
> Also, I do not think the key thing is when a standard is a final standard,
> but to assess when it is stable enough to dare to do investments towards.
>
> Regarding your proposal to move back to SPEM 1.1, I see mainly
> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
> already specified deficiencies (see the OMG ADTF presentation from the
> SPEM team for a list), which we want to avoid. SPEM v1.1 also has limited
> practical support (Osellus and IBM are possibly the only 2 companies that
> have built tools around it... :) ). So, moving back to SPEM 1.1, rather
> than something very close to SPEM 2.0, would in my mind create a big cost
> in changing the tools to support old stuff that we know is less good than
> what is close to SPEM 2.0, introducing a lot of deficiencies we have
> worked hard to remove, while provide very few benefits. The cost of
> migrating the content is negligent relative to the move back in
> capabilities and cost of code changes....
>
> Cheers
>
> /Per
>
>
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dm2f6o$jrs$1@news.eclipse.org...
>> Hi Per
>>
>>
>>
>> SPEM 2.0 is in early stages of a long standardization process and it
>> could be over a year before a final SPEM 2.0 specification is available.
>> Moreover this final specification would most likely be different from
>> this current joint-submission which is a work-in-progress. Based on this
>> I feel its best if we put our efforts in creating content based on the
>> current SPEM 1.1 specification. Osellus volunteers to convert any
>> existing content, including what you may have, into the SPEM 1.1 format.
>>
>>
>>
>> Thanks,
>>
>> Kamal.
>>
>>
>>
>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>> news:dm07lb$bcg$1@news.eclipse.org...
>>> Hi Kamal,
>>>
>>> I agree with you that we should follow standards, and that is a part of
>>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>> content IBM is suggesting to contribute is based on a meta-model that is
>>> an evolution of SPEM 1.1, and pretty close to current SPEM 2.0 proposal.
>>> I hope that SPEM 2.0 will be stable enough soon enough so we can support
>>> SPEM 2.0 in the first release of EPF v1.0. But to really committ to
>>> that, we need to better understand the impact, understand who is willing
>>> to work on it, and then plan accordingly.
>>>
>>> Any volunteers?
>>>
>>> Cheers
>>>
>>> /Per
>>>
>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>>> see this focus on software process modeling and the potential of EPF to
>>>> further this cause. SPEM 1.1 is a widely adopted standard from OMG and
>>>> we have come across many teams utilizing this standard in modeling
>>>> software processes across different methodologies. We would propose
>>>> that EPF follow this widely adopted industry standard as the meta-model
>>>> to create process modeling content. This will serve two key benefits.
>>>> Firstly, it will ensure that the models conform to an existing
>>>> non-proprietary industry standard which is more useable with minimum
>>>> training. Secondly, it will serve as an excellent and very timely
>>>> feedback mechanism to contribute to the evolving SPEM 2.0 submission
>>>> channeled through many SPEM 2.0 co-submitters who are already
>>>> contributors in EPF. Note that as part of SPEM 2.0 RFP one of the tasks
>>>> we are required to do is the migration of all content from SPEM1.1 to
>>>> SPEM 2.0. This will automatically ensure that none of the contributed
>>>> process modeling content is wasted. As part of this project we should
>>>> not interfere in the standard setting process which a standards body
>>>> like OMG's excels in doing, rather we should adopt industry standards
>>>> and build content and tool-ware around these standards.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Kamal Ahluwalia
>>>>
>>>> Osellus Inc.
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #599895 is a reply to message #70596] |
Fri, 16 December 2005 02:56 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello.
I do not see a problem. The current SPEM2 submissions and UMA/EPF are based
on SPEM1.
SPEM1 models can be represented in this new schema as we have proven by
migrating RUP (consisting of thousands of model elements based on SPEM1)
into this new format. So SPEM1 users get all of their familiar concepts.
Hence, it is not unproven at all, but fully implemented and working. The
specifications also address the SPEM requirements for supporting any kind of
development process as well as defining a minimal set of concepts. We are
just fixing the obvious and often criticized problems (and bugs) of SPEM1
and donating extensions such as method plug-ins and capability patterns that
were a big success with our clients. Such extensions however have been
packaged in the recent SPEM2 specification in a way that they are purely
optional for an implementer. The proposed EPF tool implements these, but
they are not mandatory for using the tool.
The EPF project is about creating new innovations in process engineering as
well as supporting best process engineering practices. We have been working
on SPEM2 for one and a half years now. I organized bi-weekly calls for SPEM
stakeholders and interested parties and have been to each and every OMG
meeting talking to stakeholders, presenting our proposals, gathering
feedback, and incorporating this into the specification as well as our
proposed EPF tool. Our initial submission was supported by all but one
organization that submitted a letter of intend for the SPEM2 RFP. The
revised specification was supported unanimously by all submitters. After
all this work I can say that the specification is on the right track of
realizing what people want in the SPEM as well as the general
development-process space. We therefore feel confident that this donation
reflects the trends of the next generation of SPEM. Of course, both EPF and
SPEM2 are work in progress, but we believe they should mutually improve each
other with feedback from both communities (the list of contributors already
seems to overlap significantly that this seems feasible and coordinatable).
Thus, the EPF architecture is flexible enough to allow changes and
incorporate updates. But, going back to SPEM1 and throwing away dozens of
man years of development work and hundred thousands of lines of code towards
this new direction and only concentrating on the old ways seems not to be a
logical course of action to me at this point.
As we have seen with the Eclipse EMF and UML2 projects, early
implementations of proposed standards help not only with the verification
and validation of the OMG specification, but it also facilitates early
uptake and success of a specification. I think doing this with EPF and
SPEM2 is just a logical conclusion of the lesson learned from these
projects.
Finally, I think you are bit inflating the success of SPEM1, the size of the
communities you mentioned, as well as SPEM1 fitness for use. There is no
implementation out there which completely or literally implements the
specification. Therefore, content exchange between different SPEM1 tools
using the SPEM1 XMI schema has never been implemented successfully by
anyone. I claim that one reason for this is because SPEM1 was specified
without the validation of an implementation. EPF has the chance to ensure
that a SPEM standard is realized that is fully proven with an implementation
(as actually requested in the SPEM2 RFP) as well as more importantly has the
agreement, acceptance, and support by major players in the development
process domain. Looking at the expertise of committers listed in the EPF
proposal, I think we have a huge opportunity here to development something
great for Eclipse as well as OMG (OMG being one of the EPF supporters as
well).
To confirm what I said here a quote from the official OMG SPEM 2 Request for
Proposal document:
"SPEM 1.1 saw low uptake. Since its issuance, few implementations have been
released and it has not been recognized by industry analysts who also failed
to recognize its relevance to the middleware market. There have been a
number of low profiled or casual adopters of the specification as well as
few commercial implementations. It is suspected that ease of adoption has
been an issue, and some of the SPEM 1.1 semantics were ambiguous and hard to
understand by adopters and hence not used in their practices. Submitters
should analyze the limited success of SPEM 1.1, and attempt to address these
issues in their solutions."
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino, CA
Tel/Fax: +1 408 863-8716
Email: <mailto:phaumer@us.ibm.com>
____________________________________________________________ __
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dn7f6l$aqa$1@news.eclipse.org...
> Per
>
> In our experience there is a large community of users having a good
> understanding of SPEM 1.1 which is the current OMG standard released
> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
> users use SPEM to model their processes applying the specification in
> varying degrees as suited. Although this modeling may be done outside of a
> tool context, it still enables them to use a methodology of their choice
> or even create their own in-house methodology. One of the salient features
> of SPEM 1.1 being its ability to model a process using any methodology,
> was very deliberately introduced by the then working group which as you
> know included such luminary orgs as Rational, IBM, Fujitsu, Adaptive and
> Softeam amongst others. It is evident from reading SPEM 1.1 that the team
> was guided by the considerations to keep the spec "inclusive" around
> methodologies and software development environments yet keeping it
> relatively "lightweight". An example of this is the fact that SPEM 1.1
> does not have the concept of "tasks" at all.
>
>
>
> Without getting into too much detail about the on-going work in SPEM 2.0,
> I would like to point out that we are in the stage wherein we are
> requesting, gathering and applying modeling scenarios from the process
> modeling community of users, including Borland. This also means defining
> fundamental concepts without favoring any specific approach. This exercise
> is going very well and we reiterate our call to modeling users (who may or
> may not have used SPEM 1.1) to get in touch with me or any other members
> of the SPEM 2.0 working group to contribute their scenarios. Note that one
> does not have to be an OMG member to raise issues with specifications and
> can do so by going to http://www.omg.org/technology/issuesform.htm .
>
>
>
> As far as your comments about SPEM 1.1, I would just have these
> clarifications:
>
> 1. SPEM 1.1 is the current standard from OMG released January 2005. It is
> not correct to characterize it as an old standard.
>
> 2. Most organizations adopting SPEM 1.1 move forward from a "no-standards"
> approach to modeling to a methodology agnostic and industry standard
> approach to modeling.
>
> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
> SPEM 2.0 specification are related to re-using process elements and
> process workflow, support for process enactment, support for process
> metrics, provision of greater guidance for terms used, which came to light
> with adoption by SEPG process teams/enterprise.
>
> 4. Though it is true that there are limited tools built on SPEM 1.1 I
> don't know of any tools built for SPEM 2.0 (its not possible since the
> standard is still in-progress !)
>
>
>
> Per, our position still remains that instead of using seemingly
> heavyweight and untested concepts requiring a steep learning curve which
> make up UMA or waiting for SPEM 2.0 which is a while away, we start
> process content creation and best practices definition using SPEM 1.1.
> Moreover, as Ricardo mentioned in his presentation on the 6th of December
> the entry of BUP content is still not complete. We have already
> volunteered our help in moving all donated content, including BUP to SPEM
> 1.1. We see a huge risk in building tools/content based on a meta-model
> that is not an industry standard. Furthermore instead of defining
> alternate meta-models we should let OMG with its proven standards creation
> process, create industry standard meta-models which we can then use as
> part of EPF.
>
>
>
> Kamal.
>
>
>
> "Per Kroll" <pkroll@us.ibm.com> wrote in message
> news:dmqnnb$a25$1@news.eclipse.org...
>> Hi Kamal,
>>
>> you are making a good point that it is uncertain when SPEM 2.0 will
>> become a standard. The current timeline indicates a stable proposal by
>> March 2006, and then it typically takes 1-2 years for it to become a
>> final standard. So, based on how this evolves in the next few months, we
>> need to determine whether it makes sense to support SPEM 2.0 for the
>> release of EPF v1.0.
>>
>> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
>> we should still look at whether there are certain aspects of the current
>> spec for SPEM 2.0 that we should support before it is a formal standard.
>> As an example, Borland (Karl Frank) made a good case for changes to the
>> meta-model that were required to provide good support for some of the
>> agilistas views, allowing you to e.g. produce a process without having
>> tasks. Many agilistas have a hot button around specifying tasks, and we
>> should respect that. (My personal view is that the tasks are still useful
>> as descriptive background material, and should not be interpreted as
>> prescriptive guidance, but that is not here or there).
>>
>> I think this is an area where we need to listen to the community and hear
>> what capabilities people would like to see in the process engineering
>> framework, and then from that determine how to evolve the metamodel. So,
>> I hope that the EPF projetc will lead to more input and consensus around
>> the SPEM 2.0 effort.
>>
>> Also, I do not think the key thing is when a standard is a final
>> standard, but to assess when it is stable enough to dare to do
>> investments towards.
>>
>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>> already specified deficiencies (see the OMG ADTF presentation from the
>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has limited
>> practical support (Osellus and IBM are possibly the only 2 companies that
>> have built tools around it... :) ). So, moving back to SPEM 1.1, rather
>> than something very close to SPEM 2.0, would in my mind create a big cost
>> in changing the tools to support old stuff that we know is less good than
>> what is close to SPEM 2.0, introducing a lot of deficiencies we have
>> worked hard to remove, while provide very few benefits. The cost of
>> migrating the content is negligent relative to the move back in
>> capabilities and cost of code changes....
>>
>> Cheers
>>
>> /Per
>>
>>
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dm2f6o$jrs$1@news.eclipse.org...
>>> Hi Per
>>>
>>>
>>>
>>> SPEM 2.0 is in early stages of a long standardization process and it
>>> could be over a year before a final SPEM 2.0 specification is available.
>>> Moreover this final specification would most likely be different from
>>> this current joint-submission which is a work-in-progress. Based on
>>> this I feel its best if we put our efforts in creating content based on
>>> the current SPEM 1.1 specification. Osellus volunteers to convert any
>>> existing content, including what you may have, into the SPEM 1.1 format.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Kamal.
>>>
>>>
>>>
>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>> Hi Kamal,
>>>>
>>>> I agree with you that we should follow standards, and that is a part of
>>>> the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>>> content IBM is suggesting to contribute is based on a meta-model that
>>>> is an evolution of SPEM 1.1, and pretty close to current SPEM 2.0
>>>> proposal. I hope that SPEM 2.0 will be stable enough soon enough so we
>>>> can support SPEM 2.0 in the first release of EPF v1.0. But to really
>>>> committ to that, we need to better understand the impact, understand
>>>> who is willing to work on it, and then plan accordingly.
>>>>
>>>> Any volunteers?
>>>>
>>>> Cheers
>>>>
>>>> /Per
>>>>
>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter and
>>>>> co-submitter of SPEM 2.0 submission, we at Osellus are very excited to
>>>>> see this focus on software process modeling and the potential of EPF
>>>>> to further this cause. SPEM 1.1 is a widely adopted standard from OMG
>>>>> and we have come across many teams utilizing this standard in modeling
>>>>> software processes across different methodologies. We would propose
>>>>> that EPF follow this widely adopted industry standard as the
>>>>> meta-model to create process modeling content. This will serve two key
>>>>> benefits. Firstly, it will ensure that the models conform to an
>>>>> existing non-proprietary industry standard which is more useable with
>>>>> minimum training. Secondly, it will serve as an excellent and very
>>>>> timely feedback mechanism to contribute to the evolving SPEM 2.0
>>>>> submission channeled through many SPEM 2.0 co-submitters who are
>>>>> already contributors in EPF. Note that as part of SPEM 2.0 RFP one of
>>>>> the tasks we are required to do is the migration of all content from
>>>>> SPEM1.1 to SPEM 2.0. This will automatically ensure that none of the
>>>>> contributed process modeling content is wasted. As part of this
>>>>> project we should not interfere in the standard setting process which
>>>>> a standards body like OMG's excels in doing, rather we should adopt
>>>>> industry standards and build content and tool-ware around these
>>>>> standards.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Kamal Ahluwalia
>>>>>
>>>>> Osellus Inc.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
| |
| Re: EPF Metamodel [message #599902 is a reply to message #70715] |
Fri, 16 December 2005 20:17 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Yeah, we Germans just love our titles -- I promise, I will americanalize my
sig for this community :-)
Dr. rer. nat. = doctor rerum naturalium (Latin) = DSc, ScD, Doctor of
Science
____________________________________________________________ __
"Randy D. Smith" <randy.d.smith@intel.com> wrote in message
news:dnv1vr$if4$1@news.eclipse.org...
> Wow, this has been fun. But it's been a bit like (for me) watching a
> cricket match... I don't know a thing about the competing "teams" and the
> history behind them, I don't know the rules, I don't know "who's ahead",
> or any of that stuff. I just recognize the quality of play, even if it's
> outside my normal realm of experience.
>
> But one question I've got to ask... totally irrelevant to the discussion
> at hand...
>
> Peter Haumer wrote:
>
>> PETER HAUMER, Dr. rer. nat.
>
> What's a .. whatever that is? Looks fascinating. Haven't a clue what it
> means. The Dr. part looks familiar, but the rest might be Greek for all I
> know.
>
> Yes, completely irrelevant... feel free to ignore me. But I am curious.
> --
> RDS
|
|
|
| Re: EPF Metamodel [message #599917 is a reply to message #70702] |
Thu, 29 December 2005 18:58 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
Peter, Per
As an early adopter of SPEM and a co-submitter of SPEM 2.0 we are excited
that we are now discussing which version of the SPEM standard to adopt as
the exemplary meta-model for EPF, as opposed to adopting a proprietary UMA
meta-model.
To reiterate, and for further clarification, I and my colleagues at Osellus
are in favor of pursuing improvements in SPEM, in the form of SPEM 2.0 and
subsequent versions of this specification. We are simply saying that SPEM
2.0 is not a standard yet, as is SPEM 1.1. It would make sense to base a
new contribution to the open source community on a standard specification as
opposed to something that is work in progress. The last thing we all need
is the scenario where UMA/EPF is approved in the Eclipse Foundation, only to
find out that it is based on a metamodel that is not a standard, since SPEM
2.0 has converged on a different metamodel. It is essential that we let the
SPEM 2.0 work follow its own natural course, without any extraneous pressure
that it has to meet such and such open source initiative.
I agree that we have a difference in opinion as to how far our work on SPEM
2.0 has progressed. IBM seems to be of the opinion that we are almost
there, whereas our view is that much work is ahead of us and it is uncertain
what final shape SPEM 2.0 will assume.
You and Per have coherently and rightly pointed out that the current
submission is based on UMA, primarily since this draft has been authored by
IBM to begin with. However, I would not go as far as assuming that the
submission in its current form is indeed going to become the adopted
standard. As you know, we are in the middle of an exhaustive analysis of the
latest submission to ensure the concepts contained therein can reasonably
model most methodologies and not just RUP. We would also like to map out a
clear migration path between SPEM 1.0 to this submission. We have not seen a
mapping from SPEM 1.1 to the current SPEM 2.0 submission. If you have done
so, we would greatly appreciate receiving the representation of RUP in SPEM
1.1, the migration and mapping document and the resultant representation in
the current SPEM 2.0 submission.
As an organization that focuses on process modeling without being aligned to
a specific methodology, we are getting rich feedback from across the SEPG
groups when we look for modeling examples to test the concepts in SPEM 2.0
submission. Perhaps we are meeting a different set of process modeling user
community. All of our experiences have pleasantly surprised us with the
knowledge of SPEM 1.1 out in the community. The process modeling space has
changed considerably over the past year or so. Recently, we have noticed a
lot of emphasis on software process modeling as vouched by IBM's renewed
interested in this area, Microsoft's initiatives through VSTS, Borland's
approach on process modeling and Ivar Jacobson's creation of EUP to name
just a few tool/methodology initiatives. On top of the user experiences and
scenarios we elicit, we will be keeping all this in mind as we analyze the
current SPEM 2.0 submission to ensure it meets the overall industry needs as
well as the SPEM 2.0 RFP (which we had helped author).
In our view, users would be overwhelmed with the complexity and steep
learning curve being introduced with many of the concepts (like task
descriptors) even in core concepts of the SPEM 2.0 submission. If there is
an impression that SPEM 1.1 is "ambiguous and hard to understand", I don't
see how we can justify the current SPEM 2.0 submission which significantly
compounds this complexity. Rather, we propose adopting the SPEM 1.1 which
has over the last year proven to be lightweight and inclusive, as the EPF
meta-model. We will keep updating the SPEM 2.0 submission as a progressive
elaboration of the SPEM 1.1, including the feedback from early adopters of
EPF. When SPEM 2.0 becomes the official standard the migration path
contained as part of the standard would ensure that the content is
seamlessly migrated to the newer standard. In our view going forward with
adopting an in-progress submission ignores the known risks at this time.
I sympathize with the fact that this course of action may create a dilemma
for IBM. We are not proposing that thousands of lines of code be thrown
out. What we are proposing is to either wait for SPEM 2.0 to be ratified
before the approval of EPF in the Eclipse Foundation, or alternatively, for
IBM to offer the commercial version of UMA/EPF (as it is currently doing
with RUP/RMC) to the market while developing a SPEM 1.1 version of EPF for
submission to the Eclipse Foundation.
Kamal.
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:dntacg$k7$1@news.eclipse.org...
> Hello.
>
>
>
> I do not see a problem. The current SPEM2 submissions and UMA/EPF are
> based on SPEM1.
>
>
>
> SPEM1 models can be represented in this new schema as we have proven by
> migrating RUP (consisting of thousands of model elements based on SPEM1)
> into this new format. So SPEM1 users get all of their familiar concepts.
> Hence, it is not unproven at all, but fully implemented and working. The
> specifications also address the SPEM requirements for supporting any kind
> of development process as well as defining a minimal set of concepts. We
> are just fixing the obvious and often criticized problems (and bugs) of
> SPEM1 and donating extensions such as method plug-ins and capability
> patterns that were a big success with our clients. Such extensions
> however have been packaged in the recent SPEM2 specification in a way that
> they are purely optional for an implementer. The proposed EPF tool
> implements these, but they are not mandatory for using the tool.
>
>
>
> The EPF project is about creating new innovations in process engineering
> as well as supporting best process engineering practices. We have been
> working on SPEM2 for one and a half years now. I organized bi-weekly
> calls for SPEM stakeholders and interested parties and have been to each
> and every OMG meeting talking to stakeholders, presenting our proposals,
> gathering feedback, and incorporating this into the specification as well
> as our proposed EPF tool. Our initial submission was supported by all but
> one organization that submitted a letter of intend for the SPEM2 RFP. The
> revised specification was supported unanimously by all submitters. After
> all this work I can say that the specification is on the right track of
> realizing what people want in the SPEM as well as the general
> development-process space. We therefore feel confident that this donation
> reflects the trends of the next generation of SPEM. Of course, both EPF
> and SPEM2 are work in progress, but we believe they should mutually
> improve each other with feedback from both communities (the list of
> contributors already seems to overlap significantly that this seems
> feasible and coordinatable). Thus, the EPF architecture is flexible enough
> to allow changes and incorporate updates. But, going back to SPEM1 and
> throwing away dozens of man years of development work and hundred
> thousands of lines of code towards this new direction and only
> concentrating on the old ways seems not to be a logical course of action
> to me at this point.
>
>
>
> As we have seen with the Eclipse EMF and UML2 projects, early
> implementations of proposed standards help not only with the verification
> and validation of the OMG specification, but it also facilitates early
> uptake and success of a specification. I think doing this with EPF and
> SPEM2 is just a logical conclusion of the lesson learned from these
> projects.
>
>
>
> Finally, I think you are bit inflating the success of SPEM1, the size of
> the communities you mentioned, as well as SPEM1 fitness for use. There is
> no implementation out there which completely or literally implements the
> specification. Therefore, content exchange between different SPEM1 tools
> using the SPEM1 XMI schema has never been implemented successfully by
> anyone. I claim that one reason for this is because SPEM1 was specified
> without the validation of an implementation. EPF has the chance to ensure
> that a SPEM standard is realized that is fully proven with an
> implementation (as actually requested in the SPEM2 RFP) as well as more
> importantly has the agreement, acceptance, and support by major players in
> the development process domain. Looking at the expertise of committers
> listed in the EPF proposal, I think we have a huge opportunity here to
> development something great for Eclipse as well as OMG (OMG being one of
> the EPF supporters as well).
>
>
>
> To confirm what I said here a quote from the official OMG SPEM 2 Request
> for Proposal document:
>
>
>
> "SPEM 1.1 saw low uptake. Since its issuance, few implementations have
> been released and it has not been recognized by industry analysts who also
> failed to recognize its relevance to the middleware market. There have
> been a number of low profiled or casual adopters of the specification as
> well as few commercial implementations. It is suspected that ease of
> adoption has been an issue, and some of the SPEM 1.1 semantics were
> ambiguous and hard to understand by adopters and hence not used in their
> practices. Submitters should analyze the limited success of SPEM 1.1, and
> attempt to address these issues in their solutions."
>
>
>
> Thanks and best regards,
> Peter Haumer.
>
>
> ____________________________________________________________ __
>
> Rational Software | IBM Software Group
> PETER HAUMER, Dr. rer. nat.
> RUP Development, Cupertino, CA
> Tel/Fax: +1 408 863-8716
> Email: <mailto:phaumer@us.ibm.com>
> ____________________________________________________________ __
> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
> news:dn7f6l$aqa$1@news.eclipse.org...
>> Per
>>
>> In our experience there is a large community of users having a good
>> understanding of SPEM 1.1 which is the current OMG standard released
>> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
>> users use SPEM to model their processes applying the specification in
>> varying degrees as suited. Although this modeling may be done outside of
>> a tool context, it still enables them to use a methodology of their
>> choice or even create their own in-house methodology. One of the salient
>> features of SPEM 1.1 being its ability to model a process using any
>> methodology, was very deliberately introduced by the then working group
>> which as you know included such luminary orgs as Rational, IBM, Fujitsu,
>> Adaptive and Softeam amongst others. It is evident from reading SPEM 1.1
>> that the team was guided by the considerations to keep the spec
>> "inclusive" around methodologies and software development environments
>> yet keeping it relatively "lightweight". An example of this is the fact
>> that SPEM 1.1 does not have the concept of "tasks" at all.
>>
>>
>>
>> Without getting into too much detail about the on-going work in SPEM 2.0,
>> I would like to point out that we are in the stage wherein we are
>> requesting, gathering and applying modeling scenarios from the process
>> modeling community of users, including Borland. This also means defining
>> fundamental concepts without favoring any specific approach. This
>> exercise is going very well and we reiterate our call to modeling users
>> (who may or may not have used SPEM 1.1) to get in touch with me or any
>> other members of the SPEM 2.0 working group to contribute their
>> scenarios. Note that one does not have to be an OMG member to raise
>> issues with specifications and can do so by going to
>> http://www.omg.org/technology/issuesform.htm .
>>
>>
>>
>> As far as your comments about SPEM 1.1, I would just have these
>> clarifications:
>>
>> 1. SPEM 1.1 is the current standard from OMG released January 2005. It is
>> not correct to characterize it as an old standard.
>>
>> 2. Most organizations adopting SPEM 1.1 move forward from a
>> "no-standards" approach to modeling to a methodology agnostic and
>> industry standard approach to modeling.
>>
>> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for the
>> SPEM 2.0 specification are related to re-using process elements and
>> process workflow, support for process enactment, support for process
>> metrics, provision of greater guidance for terms used, which came to
>> light with adoption by SEPG process teams/enterprise.
>>
>> 4. Though it is true that there are limited tools built on SPEM 1.1 I
>> don't know of any tools built for SPEM 2.0 (its not possible since the
>> standard is still in-progress !)
>>
>>
>>
>> Per, our position still remains that instead of using seemingly
>> heavyweight and untested concepts requiring a steep learning curve which
>> make up UMA or waiting for SPEM 2.0 which is a while away, we start
>> process content creation and best practices definition using SPEM 1.1.
>> Moreover, as Ricardo mentioned in his presentation on the 6th of December
>> the entry of BUP content is still not complete. We have already
>> volunteered our help in moving all donated content, including BUP to SPEM
>> 1.1. We see a huge risk in building tools/content based on a meta-model
>> that is not an industry standard. Furthermore instead of defining
>> alternate meta-models we should let OMG with its proven standards
>> creation process, create industry standard meta-models which we can then
>> use as part of EPF.
>>
>>
>>
>> Kamal.
>>
>>
>>
>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>> news:dmqnnb$a25$1@news.eclipse.org...
>>> Hi Kamal,
>>>
>>> you are making a good point that it is uncertain when SPEM 2.0 will
>>> become a standard. The current timeline indicates a stable proposal by
>>> March 2006, and then it typically takes 1-2 years for it to become a
>>> final standard. So, based on how this evolves in the next few months, we
>>> need to determine whether it makes sense to support SPEM 2.0 for the
>>> release of EPF v1.0.
>>>
>>> If we find that it does not make sense to support SPEM 2.0 for EPF v1.0,
>>> we should still look at whether there are certain aspects of the current
>>> spec for SPEM 2.0 that we should support before it is a formal standard.
>>> As an example, Borland (Karl Frank) made a good case for changes to the
>>> meta-model that were required to provide good support for some of the
>>> agilistas views, allowing you to e.g. produce a process without having
>>> tasks. Many agilistas have a hot button around specifying tasks, and we
>>> should respect that. (My personal view is that the tasks are still
>>> useful as descriptive background material, and should not be interpreted
>>> as prescriptive guidance, but that is not here or there).
>>>
>>> I think this is an area where we need to listen to the community and
>>> hear what capabilities people would like to see in the process
>>> engineering framework, and then from that determine how to evolve the
>>> metamodel. So, I hope that the EPF projetc will lead to more input and
>>> consensus around the SPEM 2.0 effort.
>>>
>>> Also, I do not think the key thing is when a standard is a final
>>> standard, but to assess when it is stable enough to dare to do
>>> investments towards.
>>>
>>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>>> already specified deficiencies (see the OMG ADTF presentation from the
>>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has
>>> limited practical support (Osellus and IBM are possibly the only 2
>>> companies that have built tools around it... :) ). So, moving back to
>>> SPEM 1.1, rather than something very close to SPEM 2.0, would in my mind
>>> create a big cost in changing the tools to support old stuff that we
>>> know is less good than what is close to SPEM 2.0, introducing a lot of
>>> deficiencies we have worked hard to remove, while provide very few
>>> benefits. The cost of migrating the content is negligent relative to the
>>> move back in capabilities and cost of code changes....
>>>
>>> Cheers
>>>
>>> /Per
>>>
>>>
>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>> news:dm2f6o$jrs$1@news.eclipse.org...
>>>> Hi Per
>>>>
>>>>
>>>>
>>>> SPEM 2.0 is in early stages of a long standardization process and it
>>>> could be over a year before a final SPEM 2.0 specification is
>>>> available. Moreover this final specification would most likely be
>>>> different from this current joint-submission which is a
>>>> work-in-progress. Based on this I feel its best if we put our efforts
>>>> in creating content based on the current SPEM 1.1 specification.
>>>> Osellus volunteers to convert any existing content, including what you
>>>> may have, into the SPEM 1.1 format.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Kamal.
>>>>
>>>>
>>>>
>>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>>> Hi Kamal,
>>>>>
>>>>> I agree with you that we should follow standards, and that is a part
>>>>> of the plan. SPEM 2.0, as you know, is still evolving. The tooling and
>>>>> content IBM is suggesting to contribute is based on a meta-model that
>>>>> is an evolution of SPEM 1.1, and pretty close to current SPEM 2.0
>>>>> proposal. I hope that SPEM 2.0 will be stable enough soon enough so we
>>>>> can support SPEM 2.0 in the first release of EPF v1.0. But to really
>>>>> committ to that, we need to better understand the impact, understand
>>>>> who is willing to work on it, and then plan accordingly.
>>>>>
>>>>> Any volunteers?
>>>>>
>>>>> Cheers
>>>>>
>>>>> /Per
>>>>>
>>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter
>>>>>> and co-submitter of SPEM 2.0 submission, we at Osellus are very
>>>>>> excited to see this focus on software process modeling and the
>>>>>> potential of EPF to further this cause. SPEM 1.1 is a widely adopted
>>>>>> standard from OMG and we have come across many teams utilizing this
>>>>>> standard in modeling software processes across different
>>>>>> methodologies. We would propose that EPF follow this widely adopted
>>>>>> industry standard as the meta-model to create process modeling
>>>>>> content. This will serve two key benefits. Firstly, it will ensure
>>>>>> that the models conform to an existing non-proprietary industry
>>>>>> standard which is more useable with minimum training. Secondly, it
>>>>>> will serve as an excellent and very timely feedback mechanism to
>>>>>> contribute to the evolving SPEM 2.0 submission channeled through many
>>>>>> SPEM 2.0 co-submitters who are already contributors in EPF. Note that
>>>>>> as part of SPEM 2.0 RFP one of the tasks we are required to do is the
>>>>>> migration of all content from SPEM1.1 to SPEM 2.0. This will
>>>>>> automatically ensure that none of the contributed process modeling
>>>>>> content is wasted. As part of this project we should not interfere in
>>>>>> the standard setting process which a standards body like OMG's excels
>>>>>> in doing, rather we should adopt industry standards and build content
>>>>>> and tool-ware around these standards.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kamal Ahluwalia
>>>>>>
>>>>>> Osellus Inc.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: EPF Metamodel [message #599931 is a reply to message #70744] |
Thu, 05 January 2006 22:50 |
Sigurd Hopen
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Very interesting discussion. And I can easily see this from both sides :-)
since I once was part of the RUP team, and now working on defining other
processes / methodologies mainly based on the 2003 version of the RUP meta
model (both in-house for a large s/w development enterprise, and commercial
methods following the more traditional line of thinking).
Over the last year or two, I have defined a commercial (and significant)
project management method (following the more traditional lifecycle
definition) on the RUP2003 meta model, creating a plug-in to replace 2/3 of
RUPs PM discipline. As you know, the 2003 version of the RUP meta model is
fairly close to SPEM 1.1. (Yes, I said _fairly_ :-o).
I have made some observations on SPEM 1.1's appliciability to modelling
other methodologies through this work, that I'm happy to discuss with
anyone intersted, but I don't want to add to this already exciting e-mail
thread other than saying to Peter et al.: "I think the "old" standard is in
use in more places than you're aware of :-)". But org's frequently keep
quiet, they don't easily share their experience. Writing experience reports
or case studies don't generate revenue.... Usually !
I really look forward to see some of you in Atlanta in January, where we can
get a chance to discuss these things face-to-face.
/Sigurd Hopen
2-Pro Mentor, Norway
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message
news:dp1big$ohg$1@utils.eclipse.org...
> Peter, Per
>
> As an early adopter of SPEM and a co-submitter of SPEM 2.0 we are excited
> that we are now discussing which version of the SPEM standard to adopt as
> the exemplary meta-model for EPF, as opposed to adopting a proprietary UMA
> meta-model.
>
> To reiterate, and for further clarification, I and my colleagues at
> Osellus are in favor of pursuing improvements in SPEM, in the form of SPEM
> 2.0 and subsequent versions of this specification. We are simply saying
> that SPEM 2.0 is not a standard yet, as is SPEM 1.1. It would make sense
> to base a new contribution to the open source community on a standard
> specification as opposed to something that is work in progress. The last
> thing we all need is the scenario where UMA/EPF is approved in the Eclipse
> Foundation, only to find out that it is based on a metamodel that is not a
> standard, since SPEM 2.0 has converged on a different metamodel. It is
> essential that we let the SPEM 2.0 work follow its own natural course,
> without any extraneous pressure that it has to meet such and such open
> source initiative.
>
> I agree that we have a difference in opinion as to how far our work on
> SPEM 2.0 has progressed. IBM seems to be of the opinion that we are
> almost there, whereas our view is that much work is ahead of us and it is
> uncertain what final shape SPEM 2.0 will assume.
>
> You and Per have coherently and rightly pointed out that the current
> submission is based on UMA, primarily since this draft has been authored
> by IBM to begin with. However, I would not go as far as assuming that the
> submission in its current form is indeed going to become the adopted
> standard. As you know, we are in the middle of an exhaustive analysis of
> the latest submission to ensure the concepts contained therein can
> reasonably model most methodologies and not just RUP. We would also like
> to map out a clear migration path between SPEM 1.0 to this submission. We
> have not seen a mapping from SPEM 1.1 to the current SPEM 2.0 submission.
> If you have done so, we would greatly appreciate receiving the
> representation of RUP in SPEM 1.1, the migration and mapping document and
> the resultant representation in the current SPEM 2.0 submission.
>
> As an organization that focuses on process modeling without being aligned
> to a specific methodology, we are getting rich feedback from across the
> SEPG groups when we look for modeling examples to test the concepts in
> SPEM 2.0 submission. Perhaps we are meeting a different set of process
> modeling user community. All of our experiences have pleasantly surprised
> us with the knowledge of SPEM 1.1 out in the community. The process
> modeling space has changed considerably over the past year or so.
> Recently, we have noticed a lot of emphasis on software process modeling
> as vouched by IBM's renewed interested in this area, Microsoft's
> initiatives through VSTS, Borland's approach on process modeling and Ivar
> Jacobson's creation of EUP to name just a few tool/methodology
> initiatives. On top of the user experiences and scenarios we elicit, we
> will be keeping all this in mind as we analyze the current SPEM 2.0
> submission to ensure it meets the overall industry needs as well as the
> SPEM 2.0 RFP (which we had helped author).
>
> In our view, users would be overwhelmed with the complexity and steep
> learning curve being introduced with many of the concepts (like task
> descriptors) even in core concepts of the SPEM 2.0 submission. If there is
> an impression that SPEM 1.1 is "ambiguous and hard to understand", I don't
> see how we can justify the current SPEM 2.0 submission which significantly
> compounds this complexity. Rather, we propose adopting the SPEM 1.1 which
> has over the last year proven to be lightweight and inclusive, as the EPF
> meta-model. We will keep updating the SPEM 2.0 submission as a progressive
> elaboration of the SPEM 1.1, including the feedback from early adopters of
> EPF. When SPEM 2.0 becomes the official standard the migration path
> contained as part of the standard would ensure that the content is
> seamlessly migrated to the newer standard. In our view going forward with
> adopting an in-progress submission ignores the known risks at this time.
>
> I sympathize with the fact that this course of action may create a dilemma
> for IBM. We are not proposing that thousands of lines of code be thrown
> out. What we are proposing is to either wait for SPEM 2.0 to be ratified
> before the approval of EPF in the Eclipse Foundation, or alternatively,
> for IBM to offer the commercial version of UMA/EPF (as it is currently
> doing with RUP/RMC) to the market while developing a SPEM 1.1 version of
> EPF for submission to the Eclipse Foundation.
>
> Kamal.
>
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:dntacg$k7$1@news.eclipse.org...
>> Hello.
>>
>>
>>
>> I do not see a problem. The current SPEM2 submissions and UMA/EPF are
>> based on SPEM1.
>>
>>
>>
>> SPEM1 models can be represented in this new schema as we have proven by
>> migrating RUP (consisting of thousands of model elements based on SPEM1)
>> into this new format. So SPEM1 users get all of their familiar concepts.
>> Hence, it is not unproven at all, but fully implemented and working. The
>> specifications also address the SPEM requirements for supporting any kind
>> of development process as well as defining a minimal set of concepts. We
>> are just fixing the obvious and often criticized problems (and bugs) of
>> SPEM1 and donating extensions such as method plug-ins and capability
>> patterns that were a big success with our clients. Such extensions
>> however have been packaged in the recent SPEM2 specification in a way
>> that they are purely optional for an implementer. The proposed EPF tool
>> implements these, but they are not mandatory for using the tool.
>>
>>
>>
>> The EPF project is about creating new innovations in process engineering
>> as well as supporting best process engineering practices. We have been
>> working on SPEM2 for one and a half years now. I organized bi-weekly
>> calls for SPEM stakeholders and interested parties and have been to each
>> and every OMG meeting talking to stakeholders, presenting our proposals,
>> gathering feedback, and incorporating this into the specification as well
>> as our proposed EPF tool. Our initial submission was supported by all
>> but one organization that submitted a letter of intend for the SPEM2 RFP.
>> The revised specification was supported unanimously by all submitters.
>> After all this work I can say that the specification is on the right
>> track of realizing what people want in the SPEM as well as the general
>> development-process space. We therefore feel confident that this
>> donation reflects the trends of the next generation of SPEM. Of course,
>> both EPF and SPEM2 are work in progress, but we believe they should
>> mutually improve each other with feedback from both communities (the list
>> of contributors already seems to overlap significantly that this seems
>> feasible and coordinatable). Thus, the EPF architecture is flexible
>> enough to allow changes and incorporate updates. But, going back to
>> SPEM1 and throwing away dozens of man years of development work and
>> hundred thousands of lines of code towards this new direction and only
>> concentrating on the old ways seems not to be a logical course of action
>> to me at this point.
>>
>>
>>
>> As we have seen with the Eclipse EMF and UML2 projects, early
>> implementations of proposed standards help not only with the verification
>> and validation of the OMG specification, but it also facilitates early
>> uptake and success of a specification. I think doing this with EPF and
>> SPEM2 is just a logical conclusion of the lesson learned from these
>> projects.
>>
>>
>>
>> Finally, I think you are bit inflating the success of SPEM1, the size of
>> the communities you mentioned, as well as SPEM1 fitness for use. There
>> is no implementation out there which completely or literally implements
>> the specification. Therefore, content exchange between different SPEM1
>> tools using the SPEM1 XMI schema has never been implemented successfully
>> by anyone. I claim that one reason for this is because SPEM1 was
>> specified without the validation of an implementation. EPF has the
>> chance to ensure that a SPEM standard is realized that is fully proven
>> with an implementation (as actually requested in the SPEM2 RFP) as well
>> as more importantly has the agreement, acceptance, and support by major
>> players in the development process domain. Looking at the expertise of
>> committers listed in the EPF proposal, I think we have a huge opportunity
>> here to development something great for Eclipse as well as OMG (OMG being
>> one of the EPF supporters as well).
>>
>>
>>
>> To confirm what I said here a quote from the official OMG SPEM 2 Request
>> for Proposal document:
>>
>>
>>
>> "SPEM 1.1 saw low uptake. Since its issuance, few implementations have
>> been released and it has not been recognized by industry analysts who
>> also failed to recognize its relevance to the middleware market. There
>> have been a number of low profiled or casual adopters of the
>> specification as well as few commercial implementations. It is suspected
>> that ease of adoption has been an issue, and some of the SPEM 1.1
>> semantics were ambiguous and hard to understand by adopters and hence not
>> used in their practices. Submitters should analyze the limited success of
>> SPEM 1.1, and attempt to address these issues in their solutions."
>>
>>
>>
>> Thanks and best regards,
>> Peter Haumer.
>>
>>
>> ____________________________________________________________ __
>>
>> Rational Software | IBM Software Group
>> PETER HAUMER, Dr. rer. nat.
>> RUP Development, Cupertino, CA
>> Tel/Fax: +1 408 863-8716
>> Email: <mailto:phaumer@us.ibm.com>
>> ____________________________________________________________ __
>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>> news:dn7f6l$aqa$1@news.eclipse.org...
>>> Per
>>>
>>> In our experience there is a large community of users having a good
>>> understanding of SPEM 1.1 which is the current OMG standard released
>>> January 2005 http://www.omg.org/docs/formal/05-01-06.pdf . Many of these
>>> users use SPEM to model their processes applying the specification in
>>> varying degrees as suited. Although this modeling may be done outside of
>>> a tool context, it still enables them to use a methodology of their
>>> choice or even create their own in-house methodology. One of the salient
>>> features of SPEM 1.1 being its ability to model a process using any
>>> methodology, was very deliberately introduced by the then working group
>>> which as you know included such luminary orgs as Rational, IBM, Fujitsu,
>>> Adaptive and Softeam amongst others. It is evident from reading SPEM 1.1
>>> that the team was guided by the considerations to keep the spec
>>> "inclusive" around methodologies and software development environments
>>> yet keeping it relatively "lightweight". An example of this is the fact
>>> that SPEM 1.1 does not have the concept of "tasks" at all.
>>>
>>>
>>>
>>> Without getting into too much detail about the on-going work in SPEM
>>> 2.0, I would like to point out that we are in the stage wherein we are
>>> requesting, gathering and applying modeling scenarios from the process
>>> modeling community of users, including Borland. This also means defining
>>> fundamental concepts without favoring any specific approach. This
>>> exercise is going very well and we reiterate our call to modeling users
>>> (who may or may not have used SPEM 1.1) to get in touch with me or any
>>> other members of the SPEM 2.0 working group to contribute their
>>> scenarios. Note that one does not have to be an OMG member to raise
>>> issues with specifications and can do so by going to
>>> http://www.omg.org/technology/issuesform.htm .
>>>
>>>
>>>
>>> As far as your comments about SPEM 1.1, I would just have these
>>> clarifications:
>>>
>>> 1. SPEM 1.1 is the current standard from OMG released January 2005. It
>>> is not correct to characterize it as an old standard.
>>>
>>> 2. Most organizations adopting SPEM 1.1 move forward from a
>>> "no-standards" approach to modeling to a methodology agnostic and
>>> industry standard approach to modeling.
>>>
>>> 3. Many of the deficiencies in SPEM 1.1 which in turn are the RFP for
>>> the SPEM 2.0 specification are related to re-using process elements and
>>> process workflow, support for process enactment, support for process
>>> metrics, provision of greater guidance for terms used, which came to
>>> light with adoption by SEPG process teams/enterprise.
>>>
>>> 4. Though it is true that there are limited tools built on SPEM 1.1 I
>>> don't know of any tools built for SPEM 2.0 (its not possible since the
>>> standard is still in-progress !)
>>>
>>>
>>>
>>> Per, our position still remains that instead of using seemingly
>>> heavyweight and untested concepts requiring a steep learning curve which
>>> make up UMA or waiting for SPEM 2.0 which is a while away, we start
>>> process content creation and best practices definition using SPEM 1.1.
>>> Moreover, as Ricardo mentioned in his presentation on the 6th of
>>> December the entry of BUP content is still not complete. We have already
>>> volunteered our help in moving all donated content, including BUP to
>>> SPEM 1.1. We see a huge risk in building tools/content based on a
>>> meta-model that is not an industry standard. Furthermore instead of
>>> defining alternate meta-models we should let OMG with its proven
>>> standards creation process, create industry standard meta-models which
>>> we can then use as part of EPF.
>>>
>>>
>>>
>>> Kamal.
>>>
>>>
>>>
>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>> news:dmqnnb$a25$1@news.eclipse.org...
>>>> Hi Kamal,
>>>>
>>>> you are making a good point that it is uncertain when SPEM 2.0 will
>>>> become a standard. The current timeline indicates a stable proposal by
>>>> March 2006, and then it typically takes 1-2 years for it to become a
>>>> final standard. So, based on how this evolves in the next few months,
>>>> we need to determine whether it makes sense to support SPEM 2.0 for the
>>>> release of EPF v1.0.
>>>>
>>>> If we find that it does not make sense to support SPEM 2.0 for EPF
>>>> v1.0, we should still look at whether there are certain aspects of the
>>>> current spec for SPEM 2.0 that we should support before it is a formal
>>>> standard. As an example, Borland (Karl Frank) made a good case for
>>>> changes to the meta-model that were required to provide good support
>>>> for some of the agilistas views, allowing you to e.g. produce a process
>>>> without having tasks. Many agilistas have a hot button around
>>>> specifying tasks, and we should respect that. (My personal view is that
>>>> the tasks are still useful as descriptive background material, and
>>>> should not be interpreted as prescriptive guidance, but that is not
>>>> here or there).
>>>>
>>>> I think this is an area where we need to listen to the community and
>>>> hear what capabilities people would like to see in the process
>>>> engineering framework, and then from that determine how to evolve the
>>>> metamodel. So, I hope that the EPF projetc will lead to more input and
>>>> consensus around the SPEM 2.0 effort.
>>>>
>>>> Also, I do not think the key thing is when a standard is a final
>>>> standard, but to assess when it is stable enough to dare to do
>>>> investments towards.
>>>>
>>>> Regarding your proposal to move back to SPEM 1.1, I see mainly
>>>> disadvantages in that, and few advantages. SPEM 1.1 has a long list of
>>>> already specified deficiencies (see the OMG ADTF presentation from the
>>>> SPEM team for a list), which we want to avoid. SPEM v1.1 also has
>>>> limited practical support (Osellus and IBM are possibly the only 2
>>>> companies that have built tools around it... :) ). So, moving back to
>>>> SPEM 1.1, rather than something very close to SPEM 2.0, would in my
>>>> mind create a big cost in changing the tools to support old stuff that
>>>> we know is less good than what is close to SPEM 2.0, introducing a lot
>>>> of deficiencies we have worked hard to remove, while provide very few
>>>> benefits. The cost of migrating the content is negligent relative to
>>>> the move back in capabilities and cost of code changes....
>>>>
>>>> Cheers
>>>>
>>>> /Per
>>>>
>>>>
>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>> news:dm2f6o$jrs$1@news.eclipse.org...
>>>>> Hi Per
>>>>>
>>>>>
>>>>>
>>>>> SPEM 2.0 is in early stages of a long standardization process and it
>>>>> could be over a year before a final SPEM 2.0 specification is
>>>>> available. Moreover this final specification would most likely be
>>>>> different from this current joint-submission which is a
>>>>> work-in-progress. Based on this I feel its best if we put our efforts
>>>>> in creating content based on the current SPEM 1.1 specification.
>>>>> Osellus volunteers to convert any existing content, including what you
>>>>> may have, into the SPEM 1.1 format.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kamal.
>>>>>
>>>>>
>>>>>
>>>>> "Per Kroll" <pkroll@us.ibm.com> wrote in message
>>>>> news:dm07lb$bcg$1@news.eclipse.org...
>>>>>> Hi Kamal,
>>>>>>
>>>>>> I agree with you that we should follow standards, and that is a part
>>>>>> of the plan. SPEM 2.0, as you know, is still evolving. The tooling
>>>>>> and content IBM is suggesting to contribute is based on a meta-model
>>>>>> that is an evolution of SPEM 1.1, and pretty close to current SPEM
>>>>>> 2.0 proposal. I hope that SPEM 2.0 will be stable enough soon enough
>>>>>> so we can support SPEM 2.0 in the first release of EPF v1.0. But to
>>>>>> really committ to that, we need to better understand the impact,
>>>>>> understand who is willing to work on it, and then plan accordingly.
>>>>>>
>>>>>> Any volunteers?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> /Per
>>>>>>
>>>>>> "Kamal Ahluwalia" <kamal@osellus.com> wrote in message
>>>>>> news:dlt0vu$sa4$1@news.eclipse.org...
>>>>>>> As an early Software Process Engineering Meta-model (SPEM) adopter
>>>>>>> and co-submitter of SPEM 2.0 submission, we at Osellus are very
>>>>>>> excited to see this focus on software process modeling and the
>>>>>>> potential of EPF to further this cause. SPEM 1.1 is a widely adopted
>>>>>>> standard from OMG and we have come across many teams utilizing this
>>>>>>> standard in modeling software processes across different
>>>>>>> methodologies. We would propose that EPF follow this widely adopted
>>>>>>> industry standard as the meta-model to create process modeling
>>>>>>> content. This will serve two key benefits. Firstly, it will ensure
>>>>>>> that the models conform to an existing non-proprietary industry
>>>>>>> standard which is more useable with minimum training. Secondly, it
>>>>>>> will serve as an excellent and very timely feedback mechanism to
>>>>>>> contribute to the evolving SPEM 2.0 submission channeled through
>>>>>>> many SPEM 2.0 co-submitters who are already contributors in EPF.
>>>>>>> Note that as part of SPEM 2.0 RFP one of the tasks we are required
>>>>>>> to do is the migration of all content from SPEM1.1 to SPEM 2.0. This
>>>>>>> will automatically ensure that none of the contributed process
>>>>>>> modeling content is wasted. As part of this project we should not
>>>>>>> interfere in the standard setting process which a standards body
>>>>>>> like OMG's excels in doing, rather we should adopt industry
>>>>>>> standards and build content and tool-ware around these standards.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kamal Ahluwalia
>>>>>>>
>>>>>>> Osellus Inc.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 04:34:15 GMT 2024
Powered by FUDForum. Page generated in 0.02938 seconds |
] 
Search
Help
Register
Login
Home
