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 tomorrows 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,
Ill 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 mornings 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
