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

[Per Kroll <pkroll@xxxxxxxxxx>]

I think the value discussion is tricky.
I am convinced that we can create a 2,000 page process where every page
adds value. It will be hard to say "This page as no value, or not
enough value" when you have no baseline to measure against.

Good points where made about that you
cannot just count page numbers, that say very little.
But we also know that if you have too
much information, few will read it, and it will be hard to find it. 

So, let's turn it to how I would like
to be able to present OpenUP:
----- My future presentation-----
OpenUP consists of a small, extensible
but complete, base process, called OpenUP/Basic.

• OpenUP/Basic has a small kernel of 50 pages (18 tasks, 19 artifacts, 6 roles, each on an average of 1 page <plus structural info, but I do not count that>). We think that everybody in the project should have a rough understanding of these 50 pages, they create a shared baseline for our collaboration.
• OpenUP/Basic also provide 80 pages of additional guidelines, concepts etc, that provides some more meat for those that need it.
• To allow people to make practical use of OpenUP/Basic, we have added some examples and templates. This adds another 50 pages of material.

Now, there
are naturally tons of additional knowledge one can add to this knowledge
base. We provide some of this knowledge as a series of plugins. For example,
for those that want more information on Deployment or Agile Modeling can
add plug-ins for those domains. In the same way, you can add content (plug-in)
with content around MDD or a more rigourous and detailed requirements process.

---- End My future presentation-----

----An example of a bad presentation---------
We have some +500 pages of content,
and it is all good stuff. You should read it. And you need it all. You
might need even more, so you can add a lot of additional pages of content
though plug-ins...
---- End An example of a bad presentation---------

Now, I understand that nobody would
do the latter. I think we are close to the former, but we do not know,
and that concerns me. What I really want to force happening is us having
to figure out how to get a guideline on how to do use cases to be no more
than 2 or 3 pages long. I can easily write something that is 10 pages long,
and I can read books that are 200 pages long on use cases. But we MUST
have a mechanism that forces us to carefully weigh every word. The best
books in teh world are short and concise, such as the one-minute manager,
and it is cumbersome to produce. My concern is NOT whether we end up with
a 180 or 230 page process, but whether we are truly challenging ourself
to be as concise as we ever could be, or we just choose to include the
10-page guideline because "it is all pretty good stuff" and we
have no means of stating that it is too long... Hence, we will not force
our self to write the best possible content as often as we should... 

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963

Jim Ruehlin/Irvine/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

12/01/2006 10:53 AM

Please respond to
Eclipse Process Framework Project Developers List        <epf-dev@xxxxxxxxxxx>

To	epf-dev@xxxxxxxxxxx
cc
Subject	RE: [epf-dev] Discovered Size of OpenUP/Basic

I agree with Brian in that
the page count should mostly be used as a baseline so we can manage the
size of the process going forward. There are some crudities in the count
that, I think, make this page count high (final pages that are nearly blank,
text that may be larger than what’s found in a book, task descriptors
that duplicate information, a flexible navigation style that you can’t
have in a book). 
 
However, it’s probably true
that some people will look at the bulk and say we’re too heavy. At the
least, we need to have an answer even if we don’t cut down the size. Moving
sections into plug-ins is technically feasible, but in the end the published
process will be the same size so I’m not sure if how well that would address
those critics.
 
Here’s something to think
about: Schwaber’s “Agile Project Management with Scrum” and Beck’s
“Extreme Programming Explained” are just over 150 pages each (including
appendices and excluding the index). Scrum only addresses PM, and XP only
addresses development. OpenUP/Basic addresses much more of the process.

 
Take the 4 main areas of OpenUP/Basic
(RM, PM, Architecture, and Development) and assign equivalent page lengths.
150 x 4 = 600 pages. Than add just 50 pages for CM and overarching stuff.
So for OpenUP/Basic to be equivalent in size to the popular Agile books,
it would need to be 650 pages long.
 
So if we use two of the most
popular Agile books as benchmarks, we’re still 100 pages “lighter” than
existing process descriptions, even with the conservative method we used
to estimate the pages. 
 
- 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

---

From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Brian Lyons"
<blyons@xxxxxxxxxxxxx>
Sent: Friday, December 01, 2006 5:44 AM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] Discovered Size of OpenUP/Basic
 
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.
 
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>
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev