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"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 08/25/2006 08:38 AM
|
|
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote: -----
To: "Eclipse Process Framework Project Developers List" <[email protected]>, <[EMAIL PROTECTED]>
From: "Scott W. Ambler" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] ; '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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ; [EMAIL PROTECTED]
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/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED] 08/18/2006 05:16 PM
|
|
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" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 08/18/2006 02:30 PM
|
|
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
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
[EMAIL PROTECTED]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
