Skip to main content

[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


Back to the top