[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: Collaboration in OpenUP/Basic (was Re: [epf-dev]Re-architectingOpenUP Telecon Tuesday August 22nd)
|
I think this makes sense longterm. For
now, I think we said that we should have 4 packages, which may later be
broken out into 4 separate plug-ins. Converting packages to plug-ins is
probably required down the road as we move OpenUP form 0,9 to 1.0, since
it will make it much more extensible. Also, there are probably a number
of other improvements we need to make to make OpenUP easier to extend.
We are experimenting more and more with that within IBM, and if other companies
are experimenting, pls make sure to share your experiences and changes
requests on OpenUP.
So, yes, put all roles and collaboration
stuff in the Collaboration package.We may also place some of the core work
products that are used by several of the other sub-processes, such as Work
Items List and Vision in that package. I think these are the type of changes
I hope to see on Monday as a result of Ricardo's and Jim's refactoring.
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
408-342-3815
"Chris Sibbald"
<Chris.Sibbald@xxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
08/25/2006 08:38 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
cc
| External Chris Sibbald <csibbald@xxxxxxxx>
|
Subject
| RE: Collaboration in OpenUP/Basic (was
Re: [epf-dev]Re-architectingOpenUP Telecon
Tuesday August 22nd) |
|
How about a plug-in called "Team"
that includes all the roles as suggested by Todd and collaborative principles/practices?
This way there will be dependencies from other packages to this,
but it will minimize the N**2 coupling that would occur between plug-ins?
Cheers,
Chris
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Adolph
Sent: Thursday, August 24, 2006 7:18 PM
To: 'Eclipse Process Framework Project Developers List'
Subject: RE: Collaboration in OpenUP/Basic (was Re: [epf-dev]Re-architectingOpenUP
Telecon Tuesday August 22nd)
Hi Mark:
I think you make a good point
when you suggest a plugin for collaboration in OpenUP. I think plain vanilla
OpenUP/Basic needs to state at its core we recognize the importance of
collaboration. But simply suggesting collaboration is important is like
saying it’s important to be nice to people on your project. How do you
operationalize this? At the moment, the purpose of the white paper I am
trying to write is to convey a couple of ideas how the core principles
may be operationalized. The white paper is really a poor substitute for
guidelines. Collaboration guidelines could then be written up and distributed
as part of plugin. This way we could have different implementation of the
core principles (e.g. practices for co-located teams versus practices for
less than co-located teams ).
Best regards,
Steve
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark.Dickson@xxxxxxxxx
Sent: Wednesday, August 23, 2006 3:37 AM
To: Eclipse Process Framework Project Developers List
Subject: Collaboration in OpenUP/Basic (was Re: [epf-dev] Re-architectingOpenUP
Telecon Tuesday August 22nd)
Hi all
Sorry I wasn't able to make the Re-architecting
call - I am in the in the midst of a house move this week, so I'm a bit
overloaded.
Deliving into Steve's point below I agree
with the point about collaborating roles. I have some thoughts I'd like
to contribute to the discussion. I'm not suggesting that we should change
anything for the Spetember release by the way.
When I first got involved I saw the "Additional
Performer" tag as a potentially powerful way of demonstrating the
collaborative nature of the process.
I guess this is influenced by a the way
that DSDM approaches things. DSDM looks at the roles responsible for production,
contribution to, review of and acceptance of artifacts (products). Although
this might look a little prescriptive from a superficial perspective, it
drives home the point that software development is a social activity rather
than a solo one.
In the UP context, Tasks (IMHO) should
show how people come together to do work (represented by the delivery of
Work Products). I see the Primary Performer as the lead role on a Task
- held responsible for the quality and delivery of products to the team.
The Additional Performer provides a guide to who the Primary Performer
(and PM) needs to involve in the Task.
In this way, we embed collaboration throughout
the process. Like Scott's Agile Data plugin, it's an approach that I am
following in the DSDM Plugin for Business Stakeholders.
I see that it does present a problem though,
when looking at OpenUP/Basic as the kernel for OpenUP in the large, in
that it creates potentially tight coupling between process packages.
Maybe it's something that can be added
to OpenUP/Basic through a plugin? I guess it could create an opportunity
for a literal interpretation that collaboration is an optional extra in
OpenUP. Maybe such a plugin could be presented as providing more explict
guidelines on how to effect collaboration in OpenUP? The argument being
that vanilla OpenUP/Basic advocates and implies the same but is not explicit
or prescriptive on the subject - thereby leaving it to the commonsense
judgement of experienced practitioners?
It's something to think about for the post-September
version(s) of OpenUP anyway.#
cheers
Mark
Mark Dickson
Principal Solution Architect
SAE Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx
-----epf-dev-bounces@xxxxxxxxxxx
wrote: -----
To: "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>, <chris.armstrong@xxxxxxxxxxxxxxxxx>
From: "Scott W. Ambler" <swa@xxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
Date: 08/22/2006 01:36PM
Subject: Re: [epf-dev] Re-architecting OpenUP Telecon Tuesday August 22nd
One of the things that I've been trying to
do in the agile DB techniques plug in is to have every task performed by
a pair (e.g. primary and secondary roles). In the text I describe
how they work together. It's likely not a perfect solution, but it's
a start.
This is definitely worth discussing in the
call.
- Scott
----- Original Message -----
From: Steve
Adolph
To: chris.armstrong@xxxxxxxxxxxxxxxxx
; 'Eclipse
Process Framework Project Developers List'
Sent: Monday, August 21, 2006 1:53
PM
Subject: RE: [epf-dev] Re-architecting
OpenUP Telecon Tuesday August 22nd
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 22 nd 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
_______________________________________________
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
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
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com
Chris Sibbald
Vice President, Standards and Technology
Telelogic North America Inc.
255 Albert Street, Suite 600
Ottawa
Ontario K1P 6A9
Canada
Phone: +1 (613) 266 5061
Fax: +1 (613) 482 4538
Mobile phone: +1 (613) 266 5061
Chris.Sibbald@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------
The information contained
in this e-mail, including any attachment or enclosure, is intended only
for the person or entity to which it is addressed and may contain confidential
material. Any unauthorized use, review, retransmissions, dissemination,
copying or other use of this information by persons or entities other than
the intended recipient is prohibited.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev