[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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