RE: [epf-dev] Showing collaboration in OpenUP

[Jim Ruehlin <jruehlin@xxxxxxxxxx>]

The bugzilla link referenced in the previous post is incorrect. The
correct link is https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258

 

- Jim

 

____________________

Jim Ruehlin, IBM Rational

RUP Content Developer

Eclipse Process Framework (EPF) Committer www.eclipse.org/epf

email:   jruehlin@xxxxxxxxxx

phone:  760.505.3232

fax:      949.369.0720

 

________________________________

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark.Dickson@xxxxxxxxx
Sent: Tuesday, January 30, 2007 9:39 AM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Showing collaboration in OpenUP

 

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 
_______________________________________________ 
epf-dev mailing list 
epf-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/epf-dev