Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] RE: OMG SPEM 2.0 proposal

Hello Kamal,

 

There seems to be many areas where the SPEM team needs to resolve different perspectives, and I’m not informed enough to venture an opinion on most of the statements in your email. However there’s one inaccuracy I wanted to clear up. The statement:

 

It is our view that the IBM submission only protects the interests of a commercially available tool, RMC and its underlying proprietary UMA metamodel.

 

Is not accurate. IBM does not sell a tool with an underlying propriety UMA metamodel. You’re probably referring to EPF Composer which is based on UMA and SPEM. EPF Composer is an open source tool modifiable and distributable by anyone under the EPL. The metamodel is expressed in that tool. RMC provides commercial extensions to EPF Composer.

 

It’s my understanding that the EPF group has committed to supporting the SPEM proposal when it’s approved so the tool can be as open a platform as possible. It’s in the interest of the EPF group to see the SPEM group achieve rapid agreement on the next SPEM specification so we can reach our goals with the Composer tool.

 

Thanks,

Jim

 

____________________

Jim Ruehlin, IBM Rational

RUP Content Developer

Eclipse Process Framework (EPF) Committer

email:   jruehlin@xxxxxxxxxx

phone:  760.505.3232

fax:      949.369.0720

 


From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Kamal Ahluwalia" <kamal@xxxxxxxxxxx>
Sent: Thursday, July 27, 2006 3:03 PM
To: "Eclipse Process Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
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
--=_alternative 004830DB882571B9_=--

Back to the top