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
[EMAIL PROTECTED] 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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Per Kroll
Sent: Friday, August 18, 2006 9:16 PM
To: Eclipse Process Framework Project Developers List
Cc: Eclipse Process Framework Project Developers List; [EMAIL PROTECTED]
Subject: RE: [epf-dev] Re-architecting OpenUP Telecon Tuesday August 22nd
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/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/18/2006 05:16 PM
|
|
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"
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/18/2006 02:30 PM
|
|
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
