[epf-dev] Showing collaboration in OpenUP

[Mark.Dickson@xxxxxxxxx]

Nutshell of this discussion: Capability Patterns should be the primary
focus for expressing collaboration in OpenUP/Basic. They could be the first
port of call for users to understand how OpenUP/Basic works in detail.

Here's the story...
In the Architecture Content call today, we discussed how to redefine the
architecture content to show focus on delivering software, rather than
models and documents per-se.

We looked at an outline of the architecture work proposed by Jim (see the
attachment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=165245 and the
previous posting to epf-dev by Jim for the document). This is a very useful
outline and is a good illustration of the idea that we are doing
architecture to get software. In doing so, we can produce models and
document aspects of the architecture if they help - perhaps with the notion
in mind that we do "just enough architecture to enable the team to develop
software coherently." (I'd like to propose that as a heading under one of
the  OpenUP/Basic principles, by the way, probably under Balance or Focus).

If we examine the activity diagrams Jim produced in his document, it's
clear that we are looking at a collaboration across Requirements,
Architecture, Development and Test roles and tasks - probably with a dose
of Project Management in there for good measure. We got on to discussing
the idea of how we show collaboration in the OpenUP/Content, especially
with reference to the discussion last week about late role assignment and
making the Task content more role-agnostic (around Additional Performers).

It seemed to me that Jim's activity diagram was similar to a Capability
Pattern. It shows how tasks (and hence roles) combine to achieve a goal -
this case identifying and then proving a the architecture. Not all the
activities in the diagram map directly to a Task in OpenUP/Basic but that's
not really important for the purposes of this discussion.

It might be that we have focused too much on Tasks and shoe-horned
collaboration into the task descriptions. If I want to change the focus of
the architecture content to producing a build rather than an
"Architecture" artifact, it is tempting to list "Build" as one of the
outputs of "Develop the Architecture." In the overall scheme of things,
this doesn't seem right though. It is better to bring in Tasks from the
other content packages (like Development and Test) to achieve this goal.
Which means defining a capability pattern.

"Hang on," I thought, "this sounds very familiar..."

This is exactly what RUP does. RUP defines Activities in the reference
workflows (which themselves are capability patterns in RMC). These show how
Tasks from different disciplines combine. The Tasks themselves are fairly
light on Additional Performers (it looks like additional performers are
listed where the work done by that role introduces some sort of constraint
on the Primary Performer but I'm sure someone from IBM can clarify).

So, we can reason that if we want to show collaboration explicitly in the
process, we should do it in the Capability Patterns first and be much more
sparse with Additional Performers than we have been. This would be an
approach that is consistent with RUP, which presumably would help with
scaling OpenUP/Basic.

As I write this, I am struck by the distinct possibility that this posting
is the email equivalent of a large penny dropping for me (and me alone) and
the rest of you are thinking "Well done Dickson, do try and keep up..." If
so, I apologiset. I can't read everything that get's posted, you know :-)

cheers

mark

Mark Dickson
Executive Consultant
EAS Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx


Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever.

This email and any files transmitted with it are confidential and protected by client privilege.  It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
     Xansa, Registered Office: 420 Thames Valley Park Drive,
     Thames Valley Park, Reading, RG6 1PU, UK.
     Registered in England No.1000954.
     t  +44 (0)8702 416181
     w  www.xansa.com