I agree that would have value. We could label them as sample variations of 
OpenUP we have seen an interest in.

We have one default view of what type of development we want to promote, 
but we realize that many would like to put their own twise. So, we provide 
some examples of such variations...

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963



Ricardo Balduino/Cupertino/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
06/29/2007 11:37 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@eclipse.org>


To
Eclipse Process Framework Project Developers List <epf-dev@eclipse.org>
cc

Subject
Re: [epf-dev] Multiple Capability Patterns -- some unpublished?







I believe that having a few extra capability patterns that show a couple 
of different ways of using OpenUP is fine. What we don't want to have is 
100 more patterns to create 200 different variations :-) 
We want to keep OpenUP minimal, and it is fine if you can slightly vary 
it, without major customization, as it comes out-of-the-box. 
We can provide 1 or 2 canned configurations that allow the process to be 
easily published with those variations you mentioned below. Ideally, no 
matter what configuration you publish, the published process is called 
OpenUP. 

Does it make sense? Are we aiming that for this release or next? 

Ricardo Balduino
IBM Rational Software (www.ibm.com/rational)
Eclipse Process Framework (www.eclipse.org/epf)



"Brian Lyons" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 
06/29/2007 06:14 AM 

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@eclipse.org>


To
"Eclipse Process Framework Project Developers List" <epf-dev@eclipse.org> 
cc

Subject
[epf-dev] Multiple Capability Patterns -- some unpublished?








hiho, 
  
We want OpenUP to be an enactable process, but also it should be a good 
example of usage of the Eclipse Process Framework. 
  
We have had some discussion about whether or not there is development in 
Inception.  The discussion has led us to not include development as the 
?default? (i.e. the only supplied Inception iteration template) while 
having some verbiage around possibly including additional activities for 
development. 
  
The original 0.9 release didn?t enforce Test-driven development.  In 
discussions we noted that we wanted to push TDD because it is a very 
valuable technique.  The current Develop Solution activity is strictly 
TDD. But TDD is something that some organizations are not applying. 
  
What do people think about including some additional capability patterns 
in the OpenUP repository that would not be in the default published OpenUP 
process?  This gives us a stronger message of ?This is the default, but it 
is considered ?valid? to?? for some of these expected variations.  And 
this might make the repository a stronger example of appropriate usages of 
EPF (the repository has information and some amount of that is assembled 
into a published process). 
  
                                  ------------ b
_______________________________________________
epf-dev mailing list
epf-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/epf-dev

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

Reply via email to