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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote: -----
To: "Eclipse Process Framework Project Developers List" <[email protected]>
From: "Scott W. Ambler" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
> phone: 760.505.3232
> fax: 949.369.0720
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
