Re: [epf-dev] RE: OMG SPEM 2.0 proposal

[Peter Haumer <phaumer@xxxxxxxxxx>]

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