The common theme here is Appeal and Easy of Use. Which is of course is a
big challenge since the OpenUP needs to appeal and be easy to use by a
broad audience who posses a myriad of competencies and problems to solve.
There is value in using plug-ins as needed (e.g. software development
process for low-ceremony projects, high-ceremony projects, data-base design
heavy projects, real-time embedded system engineering type projects, system
engineering projects focused on DODOF, etc. ) and yes some of the content
pages might be tweaked a bit to be more clear and concise.
Seems to me the answer to this size dilemma is embodied in the following:
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?”
What is important is the complexity of the process (i.e how many
pages do I have to read to complete a task? How many tasks do I have
to perform to get the job done? How many artifacts do I need to
produce and do they all bring value? Can I understand what I have to
do? Is it consistent? Can I find the information I need when I need
it?)
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.
Therefore, since our target audience's needs are very diverse in what
they're looking for to help them do their jobs our database, so to speak,
of the totality of method (process + method content) will be voluminous by
nature.
The key though is for us to insulate the end-user from its breadth and
width and design OpenUP around consumability scenarios based user goals and
how their performance of their task at hand is measured and then offer the
user and apealing and easy to use the portal to the EPF repository of
methods (process + method content).
Take care,
Russell
Jim
Ruehlin/Irvine/IB
[EMAIL PROTECTED]
To
Sent by: [email protected]
[EMAIL PROTECTED] cc
clipse.org
Subject
RE: [epf-dev] Discovered Size of
12/01/2006 07:53 OpenUP/Basic
AM
Please respond to
Eclipse Process
Framework Project
Developers List
<[EMAIL PROTECTED]
org>
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: [EMAIL PROTECTED]
phone: 760.505.3232
fax: 949.369.0720
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of "Brian Lyons" <[EMAIL PROTECTED]>
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: [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
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
_______________________________________________
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
