I wonder if the
desire to incorporate collaboration into the capability patterns works against
our desire to have our capability patterns relatively decoupled and therefore
replaceable. If collaboration cross cuts through all capability patterns this
can make replacement of a capability pattern problematic.
At the moment, the
only hint of collaboration we have is expressed in the content of the core
concepts which are a bit of a ?pretty bag? on the side of OpenUP. At first I
thought this was a poor way to express collaboration because I wanted
collaboration to permeate all through the OpenUP capability patterns. However
I am beginning to question both the practicality of this and the desirability.
The view that I am thinking may be more appropriate and practical within
the time frame we have is the domain based capability patterns express actions
and how those actions are coordinated
. Our core principles express coordination of understanding ? how a
team interprets the capability patterns. In other words, OpenUP is a software
development process that is expressed from two dimensions, as a set of
capability patterns (coordination of action), and as a set of concepts
(coordination of understanding). I also have a concern that
incorporating collaboration into the capability patterns may be too
prescriptive.
We can chat more
about this during tomorrow?s call.
Best regards,
Steve
From:
epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Chris Armstrong
Sent: Sunday, August 20, 2006 2:37 PM
To: 'Eclipse
Process Framework Project Developers List '
Subject: 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
From:
epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] 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 ; epf-dev-bounces@xxxxxxxxxxx
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/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 22 nd 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
