Re: [epf-dev] Method Engineering and adding a third method component rep

[Peter Haumer <phaumer@xxxxxxxxxx>]

EPF Composer has been designed to manage,
compose, configure and scale for large amounts of method content and processes.
 However, I completely agree with Scott that these two sub-projects
aim at providing the right entry points to avoid the "too much to
read and sift through before I can even start tailoring" criticism.
 

Anyway, the Q&A-based process composition
wizards has been discussed in the last committer meeting.  Would you
be interested in contributing such a tool capability?  

See this link for our current tool vision
document, which does not include this capability, yet, because we did not
have committers willing to work on it, yet.

http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.epf/design/EPF%20Composer%201.x%20Vision.rtf?rev=HEAD&cvsroot=Technology_Project&content-type=text/rtf


Thanks and best regards,
Peter Haumer.

______________________________________________________________

Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino, CA
Tel/Fax: +1 408 863-8716
______________________________________________________________

Donald Firesmith <dgf@xxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

03/17/2006 07:02

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
Subject	Re: [epf-dev] Method Engineering and adding a third method component        repository to the EPF toolset

Scott W. Ambler wrote:

>On Fri, March 17, 2006 8:51 am, Donald Firesmith said:
><snip>
>  
>
>> Much of the philosophy
>>around these two repositories seems to be based on providing a
>>/minimalistic /set of method components that can be selected, modified,
>>and possibly extended.
>>    
>>
><snip>
>  
>
>>At the OPEN Process Framework Repository Organization, we have
taken the
>>opposite approach.  We believe that it is easier to not include
existing
>>method components that are not needed than it is to create new
>>high-quality ones from scratch, and it is easier to tailor out
parts of
>>method components than it is to add missing parts, especially for
many
>>projects that do not have (or have access to) trained
>>methodologists/process engineers.
>>    
>>
>
>I think that there is clearly room for both approaches.
>
>However, my experience is that organizations which don't have trained
>methodologists (or whatever you want to call people like us) also struggle
>to cut down a process to something which would actually work for them.
>So, I wouldn't hold out much hope that the "lots of stuff, cut
it down"
>approach will fare much differently than the "lots of options,
put it
>together" approach.
>
>Fundamentally, a fool with a process is still a fool.
>
>- Scott
>  
>

Scott,
Totally agree.  Process engineering is difficult to do effectively
(either big and tailor down or small and tailor up) without significant
training, experience, and/or help (e.g., consultant or trainer).  This
is one reason why a "process consultant" tool is so critical
if an 
organization lacks access to a trained consultant.  We really need
a 
tool that provides advice based on questions regarding the endeavor 
suggesting which method components are probably appropriate and how they
might need to be tailored. 

Still, fundamentally, a fool with a tool is still a fool.

;-)

Don

>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>  
>


_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev