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 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