From: epf-dev-request@xxxxxxxxxxx
Reply-To: epf-dev@xxxxxxxxxxx
To: epf-dev@xxxxxxxxxxx
Subject: epf-dev Digest, Vol 19, Issue 10
Date: Thu, 5 Jul 2007 12:00:19 -0400 (EDT)
Send epf-dev mailing list submissions to
epf-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/epf-dev
or, via email, send a message with subject or body 'help' to
epf-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
epf-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of epf-dev digest..."
Today's Topics:
1. Re: Multiple Capability Patterns -- some unpublished?
(Jaana Nyfjord)
2. RE: General: Questions on Introduction to OpenUP node
intreebrowser (Ben Williams)
----------------------------------------------------------------------
Message: 1
Date: Wed, 4 Jul 2007 18:23:24 +0200 (CEST)
From: "Jaana Nyfjord" <jaana@xxxxxxxxx>
Subject: Re: [epf-dev] Multiple Capability Patterns -- some
unpublished?
To: "Eclipse Process Framework Project Developers List"
<epf-dev@xxxxxxxxxxx>
Cc: "Eclipse Process Framework Project Developers List"
<epf-dev@xxxxxxxxxxx>, epf-dev-bounces@xxxxxxxxxxx
Message-ID: <42603.24.80.155.80.1183566204.squirrel@xxxxxxxxxxxxxx>
Content-Type: text/plain;charset=iso-8859-1
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
>
------------------------------
Message: 2
Date: Wed, 4 Jul 2007 21:23:31 +0200
From: "Ben Williams" <Ben.Williams@xxxxxxxxxxxxx>
Subject: RE: [epf-dev] General: Questions on Introduction to OpenUP
node intreebrowser
To: "Eclipse Process Framework Project Developers List"
<epf-dev@xxxxxxxxxxx>
Message-ID:
<0B5F4532EB115E46920BDC5FE7938FFA076B3704@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
My comments embedded below,
Ben
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Per Kroll
Sent: Tuesday, July 03, 2007 5:26 AM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] General: Questions on Introduction to OpenUP node
intreebrowser
Hi,
I have a few questions regarding the node "Introduction to OpenUP"
- Should we merge "Introduction to OpenUP" and "OpenUP in a Nutshell"?
<I think yes>
[BW] I vote yes
- Will the overview graph be at "Introduction to OpenUP"? <I think yes,
but this is becoming a length page, is that wise for an intro page?>
[BW] As per Ricardos comments, yes I think it needs to be, and should be
displayed at the top of the page
- Do we still need "OpenUP Fundamental Concepts"? I have already
referenced the 4 phases, risk, and iteration from Governance lifecycle
and Iteration lifecycle respectively. I also referenced Software
Architecture from Micro iteration, and I could reference Use Case, from
Micro Increment, but I do not think there is a great logical connection
<I think no, we do not need "OpenUP Fundamental Concepts". >
[BW] What is the rationale for getting rid of this?
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com
Ben Williams
Director of Product Management, Lifecycle Solutions
Telelogic UK Ltd
Northbrook House, Oxford Science Park,
Oxford
OX4 4GA, United Kingdom
Phone: +44 020 7193 7067
Fax: +44 (1865) 784 286
Mobile phone: +44 (7710) 637 067
Ben.Williams@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------
The information contained in this e-mail, including any attachment or
enclosure, is intended only for the person or entity to which it is
addressed and may contain confidential material. Any unauthorized use,
review, retransmissions, dissemination, copying or other use of this
information by persons or entities other than the intended recipient is
prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://dev.eclipse.org/mailman/listinfo/epf-dev/attachments/20070704/4a503f01/attachment.html
------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
End of epf-dev Digest, Vol 19, Issue 10
***************************************
