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

["Jaana Nyfjord" <jaana@xxxxxxxxx>]

I also agree with adding this extra capability pattern. It makes certainly
makes sense, and I believe it will only improve the position of OpenUP.

My only concern is that we should be very clear and consistent with the
message about what is considered "default", and what are variations in
order to avoid any misunderstanding.

Cheers
Jaana N



 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/IBM@IBMUS
> Sent by: epf-dev-bounces@xxxxxxxxxxx
> 06/29/2007 11:37 AM
> 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] 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" <blyons@xxxxxxxxxxxxx>
> Sent by: epf-dev-bounces@xxxxxxxxxxx
> 06/29/2007 06:14 AM
>
> Please respond to
> Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
>
>
> To
> "Eclipse Process Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
> 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@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
>