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