Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epf-dev] Method Engineering and adding a third method component repository to the EPF toolset


Ok. Can you make it on the 27th?

 Monday, March 27th, 8:00 - 10:00 PT, 16:00 - 18:00 GMT

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/18/2006 04:47

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





Peter,
I would be very interested in working on this feature including
requirements, user interface design, and usability testing.  With a full
time job at the SEI and my other duties, I do not have the time to
volunteer for actual detailed design and implementation work.
Don

Peter Haumer wrote:
>
> 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
>  


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


Back to the top