We were merely correcting the misunderstandings that
had come out in the last EPF meeting and were reflected in the EPF minutes. I
believe IBM put the topic of Osellus SPEM 2.0 proposal on the agenda of the
last EPF meeting, not Osellus. We brought these corrections to
the attention of the IBM representative in OMG and were
asked to bring them up in this forum. Could you please touch
base with him so we know exactly what we should do.
Could you clarify what you regard as “wrong and
misleading” in our statements either in this forum or OMG. It isn't
possible for us to clarify or correct any points without knowing the
specific technical issues. I am not sure why IBM doesn't welcome an open
technical discussion around the meta-model framework.
Can you please let me know who are the submitting and
supporting companies that are active in both EPF and SPEM 2.0? We would like
to collaborate with them.
Thanks
Kamal Ahluwalia
Osellus Inc.
www.osellus.com
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Haumer
Sent: Monday, July 31, 2006 1:41
PM
To: Eclipse Process Framework
Project Developers List
Cc: Eclipse Process Framework
Project Developers List; epf-dev-bounces@xxxxxxxxxxx
Subject: Re: [epf-dev] RE: OMG
SPEM 2.0 proposal
We find many of your statements regarding our
submission to be plain wrong and misleading, but we will discuss the specifics
of SPEM 2.0 proposal within OMG, and as stated earlier, we ask you to take such
SPEM-specific discussions off this list and have them within OMG. We encourage
anybody in EPF interested in SPEM to join the discussion within OMG. Several
submitting and supporting companies are active in both EPF and SPEM 2.0, all of
them supporting the Adaptive, ESI, Fujitsu, IBM, Softeam submission.
Thanks and best regards,
Peter Haumer.
______________________________________________________________
PETER HAUMER, Dr. rer. nat.
Rational Method Composer | Eclipse Process Framework
Rational Software | IBM Software Group
Tel.: +1 408 863-8716
______________________________________________________________
|
"Kamal Ahluwalia"
<kamal@xxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
07/27/2006 15:03
|
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
|
To
|
"Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[epf-dev] RE: OMG SPEM 2.0 proposal
|
|
Hi All
As
indicated earlier we would now take the opportunity to address the
mis-understanding related to SPEM 2.0. Specifically, we would respond to issues
relating to our submission that we noticed had come up for discussion at the UK face-to-face
meeting on 060619.
1. On
the claim that this submission is a “counterproposal”.
Our
submission (supported by Sun Microsystems, Borland and Microsoft and others) is
a comprehensive stand alone proposal in response to the SPEM 2.0 RFP which
Osellus had helped author. It is incorrect to refer to it as a “counterproposal”.
2. On
the claim that this submission is “based
on IBM /Adaptive et al SPEM proposal” and “more aligned towards Microsoft”
Our
objective in this submission has been to remain inclusive. It has been created
with an interest in supporting RUP, MSF, Macroscope and all other software
process modeling methodologies including different agile methodologies and
concepts. It includes the work done, as part of our prior involvement as a
co-submitter of the IBM proposal, for more than a year. Most significantly, it
includes direct feedback from SPEM 1.1 adopters. It is precisely for this
reason that it is gaining momentum with all major corporations/institutions who
are reviewing it. Since we don’t have pressures to support a pre-existing
tool or service offerings we remain transparent and flexible in incorporating
this feedback. We have requested feedback on the submission from this forum
earlier. We have also requested feedback from IBM which they have refused to
give. What we find most perplexing in this assertion is that if our submission
is based on the IBM proposal, how it can also be “aligned towards Microsoft”.
It is
our view that the IBM submission only protects the interests of a commercially
available tool, RMC and its underlying proprietary UMA metamodel.
We
feel that in order to get wider community involvement it is imperative that the
metamodel framework does not come across as favoring a specific methodology or
worse still as a design document of a pre-existing commercially offered tool
and service offerings pre-built around it. This has two serious implications.
Firstly, it may result in at best an incomplete and at worst an inferior
solution since the problem definition has only been solutioned from a single
methodology/tool/organization perspective. Contrast this with a transparent
approach that remains inclusive and considers different options before deciding
on an optimal solution. Secondly it will result in a lack of incentive to
innovate on the part of other organizations that now have to compete against an
organization that has already influenced the meta-model in favor of its
pre-existing tools and service offerings. Contrast this with an unbiased meta-model
giving equal opportunity to all organization for unrestricted innovation.
Here
are some examples in the IBM proposal that we feel highlight its bias towards
RUP/RMC:
a)
Method Plugin: This is a very specific RUP concept that is not suitable to be
adopted as part of an industry specification.
b) WP:
RUP-specific WP classes. Hardwiring specific classes suitable for RUP only is
not appropriate. Instead the meta-model should enable tool implementations to
extend and implement WP classes for particular implementation.
c)
Variability: Biased to uphold RUP content management and publishing
requirements. This is an over-engineered tool implementation concept that would
make it unnecessarily complex for use across other methodologies and process
frameworks.
d)
Delivery Process, Capability Patterns, Method Content: Needless introduction of
new terminology to implement concepts that can be explained with
modification/expansion of existing SPEM entities.
3.
On the claim that this submission is “closer
to SPEM 1.1, causing the tool to move back 3 years in technology”
The
Osellus proposal is progressive and forward looking. The IBM submission lists
the following seven key “new
capabilities for process authors”. Let us examine our
submission with each of these key capabilities in the IBM proposal:
a) “Clear separation of method content definitions
from the development process application of method content”
We
achieve this goal. Instead of resorting to introducing new terminology, we have
used a simple “process element definition and usage” pattern. Using
this pattern we can easily account for the separation of process element
definition such as defining activities and their usage in process component
(reusable cluster of activities in a specific area) or processes (end to end
processes which are most likely composed out of process components).
b) “Consistent maintenance of many alternative
development processes”
We
achieve this goal. The same extensibility mechanism that we use for process element
extensibility is used for extending a process component or processes. >From the
feedback we have received this reuse of the extensibility pattern is a superior
concept due to it being more intuitive and not overly complex.
c) “Many different lifecycle processes”
We
achieve this goal. Our metamodel supports multiple lifecycle models without
constraining a user to choose a specific lifecycle modeling approach. This is
achieved with a careful regard against over-engineering the process element
entities such that they can be crafted into whatever lifecycle approach that is
needed.
d) “Flexible process variability and extensibility
plug-in mechanism”
We
achieve this goal. Rather than using an over-engineered tool specific mechanism
to achieve process and process element extensibility we have introduced a
simpler extension feature. Our extensibility implementation balances the needs
of process adherence (for instance as a SEPG directive to draw from OSSP) with
a practical and low-overhead way to customize and tailor processes for specific
project environments. This submission supports the extension of process
elements as well as their usage in process workflows, ensuring a kind of live
binding of the base element to the usage element. This ensures the creation of
simple and flexible process models that dynamically respond to changes in base
elements. This low-overhead reusability mechanism can be utilized by agile self
organizing teams as well as structured software process engineering groups.
e) “Multiple ‘views’ of Process
content”
We
achieve this goal. A tool implementation of our meta-model can choose to
represent the core process data in any number of ways since these views will be
derived from the same object model. Interchanging data from one tool to another
may result in additional views based out of the same data structure. Moreover
we believe that a meta-model should go only as far as providing the necessary
data structure to let tool implementation generate “views” of their
choice rather than prescribing such and such views in the meta-model
f) “Reusable process patterns of best practices for
rapid process assembly”
We
achieve this goal. Process Components, packages as a reusable cluster of
elements, can be reused at different locations in the same process or across
different processes. Our advanced approach of achieving this goal offers
opportunity for real time automatic change propagation.
g) “Replaceable and reusable Process Components
realizing the principles of encapsulation”
We
achieve this goal. Our implementation of Process Components offers a choice of
packaging a cluster of activities that can be used and extended into larger
process components or included into delivery processes.
I am
not sure how a tool built with this meta-model will take it back 3 years since
the meta-model achieves each of the key capabilities introduced in the IBM
submission and more. If anything basing the meta-model on UMA is bound to hold
it back due to the limited objectives (of a single tool/organization) it was
created to support.
We
have achieved a balance between being forward looking and preserving existing
investments by organizations in SPEM. Our concern here is that the IBM
submission will result in a serious disruption to the investments made in SPEM
(which is being used by numerous corporations around the world) as it
introduces significant modifications in the meta-model forcing most
organizations to start from scratch while defining their process elements and
processes
4. On
the claim that this submission is “more
focused on process enactment than process authoring”
Treating
processes as published shelf-ware only would move us back not forward in
provisioning an exemplary process framework. Support for process enactment has
been extensively demanded by early SPEM adopters who see it as the next step in
the evolution of the process modeling domain. Their early investments in
software process modeling using SPEM can be fully realized with a wider (more
practioners empowered with buy-in) and deeper (actual “consumption”
of processes in real projects) process adoption. It increases the chances of
achieving better software quality since the best practices and guidances are
viewed in terms of enactment/endeavor domain on real projects and not just
published binders/websites. It lays the foundation for process governance and
adherence to process frameworks by providing process metrics from enactment
which can also enable process improvement. Furthermore, Enactment cannot be an
afterthought but rather work in coordination with well thought out process
authoring concepts that support it.
The
IBM meta-model does not address enactment.
Please
let me know if there are additional grounds for confusion which I have not
addressed. If needed, Osellus would be happy to participate in conference
call(s) to dispel any further confusion regarding our SPEM 2.0 submission.
Thanks,
Kamal
Ahluwalia
Osellus
Inc.
www.osellus.com
From: Kamal Ahluwalia
Sent: Friday, July 07, 2006 11:07 AM
To: 'Eclipse Process Framework Project Developers List'
Subject: OMG SPEM 2.0 proposal
Hi
We
noticed that there was some mis-understanding relating to SPEM 2.0 in the
recent meeting minutes from the UK
face-to-face. We touched based with IBM and they have suggested we raise them
with the wider mailing list. In due course we will be elaborating on some key
aspects of the proposal which will help in clearing the air for everyone.
On a
related SPEM note, in the recent OMG meeting in Boston on 28th June, a motion for
one meeting cycle extension was voted in favor to give an opportunity for the
two proposals to be formed into a single proposal if possible. Depending on the
progress made there is a possibility of submitting a single proposal in the
next OMG meeting in late September.
Thanks
Kamal
Osellus
Inc.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
