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.