|
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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Armstrong 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 ~:| Come see APG at: From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Per Kroll
|
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
