[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Re-architecting OpenUP Telecon Tuesday August 22nd
|
I'll try to see if I can participate. However, I'll be in
the Upper Peninsula of Michigan camping, so I can't speak to the cell phone
reception and general mayhem at-large. If I can't make it, I guess the biggest
point I have (irrespective of the graphic) is that we should represent
collaboration pretty clearly. I think it would be ironic if we claim that OpenUP
is collaborative, but with little evidence of such collaboration in the actual
process model. So, I propose that our capability patterns not be
discipline-focused (which doesn't represent collaboration with other roles very
well), but instead be collaboration-focused. That is, they should include at
least one role (and appriopriate tasks) from at least two of the domains
(management, user, development). In the four-circle graphic (with the product at
the center), these proposed capability patterns are represented on the arrows
between the domains. Then I suggest that we represent complete team-focused
collaboration (which is also product-focused) as configurations of these
capability patterns in each of the four phases (represented by their intent vs.
their actual names in the product circle).
I believe in the current OpenUP method content, each domain
is reasonably decoupled from another (as it relates to interdependencies between
tasks and work products), with the exception of key work products such as work
item list and others. In the collaboration approach I described, there would be
pretty high coupling in the inter-domain capability patterns. So, the
consequences of this would be if some one wanted to replace a domain, we would
place pretty few constraints on what they replaced it with (based on the shared
work products). However, they would need to redefine the capability patterns
that represented collaboration with the other two domains. This does not trouble
me, however. Basically the capability patterns are method content configured
into process, so if someone replaces a big chunk of OpenUP method content (like
an entire domain), it seems only natural that they would need to redefine the
collaboration that the replaced domain has with the other two pre-existing
domains (i.e. redefine part of the existing process, but not redefine the
existing method content).
Have a great week!
Thanks, Chris ~:|
Chris Armstrong ~:|
President
Armstrong Process Group, Inc.
651.491.5575 c
715.246.0383 f
6514915575@xxxxxxxxxxx cell
message
www.aprocessgroup.com
"proven practical process"
Come see APG
at:
---------------
Eclipse Process Framework F2F Meeting -
www.eclipse.org/epf
Washington, DC, August 10-11, 2006
---------------
14th IEEE International
Requirements Engineering Conference
Minneapolis, MN, September 11-15, 2006 -
www.re06.org
OK, I found them in bugzilla
entry https://bugs.eclipse.org/bugs/show_bug.cgi?id=152354 Cheers Per
Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process
Framework
Rational Software, IBM Corp
408-342-3815
Per
Kroll/Cupertino/IBM@IBMUS
Sent
by: epf-dev-bounces@xxxxxxxxxxx
08/18/2006 05:16 PM
|
Please respond
to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx> |
|
|
To
| Eclipse Process Framework Project
Developers List <epf-dev@xxxxxxxxxxx>
|
|
cc
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>,
epf-dev-bounces@xxxxxxxxxxx
|
|
Subject
| RE: [epf-dev] Re-architecting
OpenUP Telecon Tuesday August 22nd |
|
Hi,
I can attend.
Brian, which slides are you referring to? I see a
Word document from 7/24 with one graphic showing a Venn diagram. Is there more
than that graphic?
Also, was there a discussion in DC about a potential 4th pie,
suggested by Scott, dealing with Deployment? My gut feeling is that it is a good
idea, but we do not have much on deployment today. It could serve as better to
wait a little before adding it, so we do not have a pie advertising our big
hole.. :)
Also, before taking a clear stand on whether that pie makes sense,
I would like to see the underlying process model to ensure that it is reasonably
well decouplde from the other "pies"..
Cheers
Per Kroll
STSM, Manager Methods: RUP /
RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM
Corp
408-342-3815
"Brian Lyons"
<blyons@xxxxxxxxxxxxx>
Sent by:
epf-dev-bounces@xxxxxxxxxxx
08/18/2006 02:30 PM
|
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] Re-architecting
OpenUP Telecon Tuesday August 22nd |
|
hiho,
I’ll be there.
Can we also ensure that Chris Armstrong is on the call?
During the face-to-face I was enamored with all the thought that went into
the graphics he created, but I want to make sure we have a unified perspective
and that the Venn/evil-eye ideas synch with the pie ideas.
------------ b
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve
Adolph
Sent: Friday, August 18, 2006 1:45 PM
To: 'Eclipse
Process Framework Project Developers List'
Subject: [epf-dev]
Re-architecting OpenUP Telecon Tuesday August 22nd
Good morning
everyone.
During this morning’s General
and Overarching issues telecon we decided that we need a telecon to discuss the
issues raised by bugzilla issue
| 152354
| 12:17:11
| maj
| P3
| All
| NEW
| EPF
| Content
| 1.0
| ---
| Re-architecting and
Re-positioning OpenUP |
This
call is scheduled for Tuesday August 22nd at 8:00am PDT. Please
refer to the calendar for call details.
This call may have to be re-scheduled if Per Kroll is not
available.
Best regards,
Steve_______________________________________________
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
