hiho,
We have been sensitive to the element-count
size of the process throughout the authoring effort and this has kept our eye
on the ball with respect to making the process understandable. In a meeting on
the Design the Solution task one person might mention “what about a task
for database design?” and someone else would pipe up with “what
about user experience?” The focus on keeping the process understandable
kept us from blowing it out into something much larger…. element-count wise.
Contrasting some recent posts, I do not
discount the importance of keeping the scale down, page-count wise. We have an
experienced, well-educated group of people as contributors here and at each
step any one of us could wax poetic about the topic at hand. Understanding the
size we have in front of us and the importance of having an understandable
process should keep our eye on the ball, keeping us from adding fluff.
Most people have experienced process
descriptions in the form of books that are inherently quantifiable. It is reasonable
to talk about the number of pages in this process; but in using that same
measurement unit, we should make sure we are calculating it similarly. A book
would not have so much space spent on the linkages that this process does. A
book will not have each small topic start on a new page.
Jim’s method provides a baseline
that we can compare against as we move from 0.9 to 1.0. But I don’t
think it provides a comparative number to process content that one might find
in book form. I’d be interested in finding out how many pages of actual
content someone would be expected to read and intellectually digest if they
want to examine the process from end-to-end. We’ll have to find another
means to calculate that.
-----------
b
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Armstrong
Sent: Friday, December 01, 2006
6:52 AM
To: 'Eclipse Process Framework
Project Developers List'
Subject: RE: [epf-dev] Discovered
Size of OpenUP/Basic
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.
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>
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