[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[epf-dev] Size matters...
- From: Per Kroll <pkroll@xxxxxxxxxx>
- Date: Wed, 6 Dec 2006 19:05:31 -0700
- Delivered-to: firstname.lastname@example.org
I hope you will find the attached spreadsheet
very interesting. Thanks Brian for helping out to produce it.
It shows for each package (minus General,
I did not do this yet)
1) How many method elements we have
of each type
2) How many pages of core content we
have (pages of actual text for roles, artifacts and tasks)
3) How many pages of Guidance content
we have (pages of actual text for all Guidance types minus Examples
and Templates, since I do not think these should count)
- We have a total of 45 pages of core
content. This is all you need to read to get a complete process. Great.
- We have a total of 140 pages of guidance
content. This is pretty OK, but there are some imbalances we should fix.
- There is a reasonable balance across
the packages in terms of # of method elements. This is good.
- There is twice the number of pages
for Requirements than for the average package. We need to fix that. Good
news, the reviews we have had will cut down the pages a lot (but my guess,
- Test is weak. Not many pages there.
- Project management and requirements
has almost all the templates. Does that make sense? Probably, because you
typically use whiteboard or tools for the other packages....
- Project management and Architecture
has all examples. I think other areas should have examples too. OK, I have
fought against investing a lot in examples, but I thought we had some...
Can we produce one example for each artifact??
Some more detailed comments
- Guidance around Use Cases: 27 pages
is way too much
- Concept: Using Visualization is empty
- I think we can have one Concept for
Mechanisms. I do not think we need 4; Analysis, Design, Architectural,
- Gudieline: Design Components Representation
is empty => Remove
- Guideline: Design Visually => I
think too long. Especially considering that we also have a Concept paper
on 2 pages. I rather have us guide on how to do certain type of design,
which may include Visual Modeling, than talk about Visual Modeling for
the sake of visual modeling....
- Can we merge Concept: Pattern and
Concept: Business Pattern?
- Test has way too short descriptions
throughout. 0.1 pages, 0.25 pages, ....
- Test probably also have too few process
- Change Request: I suggest removing
Concept and Guideline and moving the text (even extended versions of the
current text) to the Artifact and Task. I do not think we need to explain
what a Change request is, it is pretty obvious. Look at the artifact if
you do not know.
- Do we need more meat in project mgmt?
Or is this the ideal length? Feels like the guidelines here are briefer
than in other areas. I think partially because almost all of the content
has been written from scratch versus in many other areas, a lengthier version
has been shorten down...
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
OpenUP Content v0.3.xls
Description: MS-Excel spreadsheet