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
------------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev