RE: [epf-dev] Discovered Size of OpenUP/Basic

["Scott W. Ambler" <swa@xxxxxxxxxxxx>]

Mark's point that we need to ensure that the quality of the content is
high is a very good one which I agree with completely.  At the same time,
we're going to take heat if there is a lot of extraneous material, which I
guess is a quality issue.

If there is a possibility to move material into a separate plug-in then we
should consider it.  Perhaps the visual modeling material?  Refactoring
out some plug ins would have a few advantages:
1. It would slim down the base process, which I still think is a good thing.
2. It provides some examples of plug-ins, which would also be good.  We've
been talking a lot about the opportunity for plug-ins, but not a lot has
emerged yet.  Granted, there is a lot of good work going on with plug-ins
which should soon bear fruit.  Speaking of which, the ADT plug-in will
soon be available for review.

- Scott

On Fri, December 1, 2006 6:51 am, Chris Armstrong said:
> I completely agree with Mark's perspective. We shouldn't be as concerned
> about size, but more about essential content. To Scott's point, it might
> not
> be a bad idea to consider refactoring content into multiple plugins, so
> for
> those organizations and teams that are concerned about size can control it
> (but we should probably get some feedback from the user community before
> we
> dive into it). One thing about Jim's page count to consider is that method
> content is re-published in the various descriptors used in the capability
> patterns and delivery process. This might artificially inflate the
> "actual"
> size of original content...
>
> Thanks, Chris ~:|
>
>   _____
>
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Mark.Dickson@xxxxxxxxx
> Sent: Friday, December 01, 2006 4:14 AM
> To: Eclipse Process Framework Project Developers List
> Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic
>
>
> I think we should worry less about the number of pages and more about the
> value of the content on each page.
>
> The number of pages will be artificially bloated by the page layout
> delivered by Composer. For example the Architecture work product covers
> two
> pages of printed paper but only delivers about half a page of text in a
> 12pt
> font.
>
> On a more general point, I am uncomfortable about the way recent
> discussions
> have focused on the size of the process, as if somehow smaller means more
> agile. I do not believe that agility is a function of the size of the
> process. It is a function of how people behave, not what the process does
> or
> does not explicitly document.
>
> I believe that it is important that OpenUP/Basic delivers value to it's
> users. I do not think that the primary audience for OpenUP/Basic is going
> to
> be projects made up of small teams of battle-hardened agile development
> veterans. Projects like that don't really need to refer to *any* written
> process.
>
> So who's our audience? Small teams of less experienced developers adopting
> new technologies and techniques? People who want to use the Unified
> Process
> but want a free alternative to RUP? I think so. If that is the case then
> OpenUP/Basic had better be delivering some real content - by which I means
> actual practices and guidance to help them reach a point where they don't
> need it anymore.
>
> That stuff consumes pages. And (if done right) delivers value.
>
> When deciding what to chop out of OpenUP/Basic, we need to make sure that
> we
> ask the question "does this content deliver value to our audience?" If the
> answer is yes and we are still at 542 pages, then I am ok with that.
>
> Cheers
>
> Mark
>
>
> Mark Dickson
> Principal Solution Architect
> SAE Practice
> m 0780 1917480
> w www.xansa.com <https://extranet.xansa.com/,DanaInfo=www.xansa.com+>
> e mark.dickson@xxxxxxxxx
>
>
> -----epf-dev-bounces@xxxxxxxxxxx wrote: -----
>
>
>
> To: "Eclipse Process Framework Project Developers List"
> <epf-dev@xxxxxxxxxxx>
> From: "Scott W. Ambler" <swa@xxxxxxxxxxxx>
> Sent by: epf-dev-bounces@xxxxxxxxxxx
> Date: 12/01/2006 03:49AM
> Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic
>
> Seems to me that we need to cut it down dramatically.
>
> What material can we move out into separate plug-ins?
>
> - Scott
> On Thu, November 30, 2006 7:56 pm, Jim Ruehlin said:
>> The best estimate I have so far of the size of OpenUP/Basic is 542 pages
>> (8 ½ x 11). This is based on what?s in CVS as of 11/29/06. This should
>> give us an initial benchmark for our OpenUP/Basic 1.0 scoping efforts.
>>
>>
>>
>> I determined the size by creating a PDF of the entire website, doing a
>> breadth-first walk along the links starting with the Intro page. I didn?
>> t see anything missing, but I only made a cursory examination of the PDF
>> file. Glossary terms, templates, and examples are included in the page
>> count. Also, many web pages are longer than 8 ½ x 11, so this estimate
>> is based on a book layout, not a website layout.
>>
>>
>>
>> - 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
>>
>>
>> _______________________________________________
>> epf-dev mailing list
>> epf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/epf-dev
> <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or
> g,SSL+>
>>
>
>
> Practice Leader Agile Development, IBM Rational
> http://www-306.ibm.com/software/rational/bios/ambler.html
> <https://extranet.xansa.com/software/rational/bios/ambler.html,DanaInfo=www-
> 306.ibm.com+>
>
> Refactoring Databases (
> http://www.ambysoft.com/books/refactoringDatabases.html
> <https://extranet.xansa.com/books/refactoringDatabases.html,DanaInfo=www.amb
> ysoft.com+> ) is now
> available.
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
> <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or
> g,SSL+>
>
>
>
>
> 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
>


Practice Leader Agile Development, IBM Rational
http://www-306.ibm.com/software/rational/bios/ambler.html

Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html ) is now
available.