Hi Guys:
This opens a useful area of discussion,
and also may help us develop the principles what is definitely “in”
and what is optional. Most of my experience is with projects with less than 50
staff members and more often less than 10. We rarely did extensive domain
modeling because we believed it was not necessary and what modeling we
performed was usually limited to UML diagrams on white boards. I agree with
Ricardo here, for the process-still-known-as-BUP domain modeling should be kept
to a minimum, with the goal of simply creating a common project vocabulary.
I’m restating the obvious, but the
process must be minimal such that a small team (say less than 5 people) or even
an individual would enthusiastically embrace it. Plugins should then enable the
process to scale with the size and complexity of the project. The
exciting opportunity this opens for us is the addition of plugin modules that
extend this minimal description. The utility is not so much that additional
activities and artifacts these plugin models introduce, but the criteria for
when to add a plugin to the basic process – in other words the criteria
for growing the process. For example, what risks does a specific domain
modeling plugin mitigate and therefore when is it appropriate to add domain modeling
to the minimal process? The answers to this question will make this EPF and BUP
truly useful to its adopters. This is what motivated me to join this project in
the first place, looking at how to scale UP rather than trying to tailor down
That’s my 2 cents worth anyways.
Best regards,
Steve Adolph
Consultant
WSA Consulting Inc
Vancouver Canada
P +1 604 696 0460
F +1 604 696 0470
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Friday, February 10, 2006
2:54 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Re: What do we
do for an analysis model
Hi Chris,
You
definitely have a good point here, and that is the type of feedback we expect
to hear from the community about the proposed work. Now the challenge is to get
consensus on what would be a good release 1.0 for BUP which can provide a
minimal -- still complete -- process.
That
being said, I understand your concern about this "big jump", where it
seems analysis activities are missing. In fact, when proposing BUP we
considered that in small projects these analysis activities are
"transparent" and kind of absorbed by tasks performed by the
architect and developer roles. At some extent, the architect does some high
level analysis (finding key abstractions, understanding architectural
constraints, etc). The developer also has to do some analysis for his/her use
case/scenario, finding the classes that are part of that use-case realization.
That seemed to bring a more straightforward approach to analysis and design.
Comments on this will be appreciated.
Regarding
a domain model: one of the intents for BUP is certainly not to be so
model-centric or advocate big up-front design. Actually, we may think of design
being captured using different approaches, like UML diagrams (even in a whiteboard),
CRC cards, etc. These are variants for what we hope to see plug-ins extending
BUP. Up-front design thinking should be allowed, but not a premise. If one
wants to follow a "design as you go" approach, it should also be
allowed to do. I'd just be a bit cautious when adding different levels of
abstractions for models and diagrams, in order to avoid having people thinking
we are imposing a heavy way of doing design in BUP. If, in your opinion,
there's a lack of information that a nice glossary could suppress, than we have
to think about it.
Again,
we want a minimal, yet complete process :-)
Comments
from the others will be appreciated.
Regards,
Ricardo
Balduino
Senior Software Engineer
IBM | RUP Team | EPF Committer
Phone: 1 (408) 863-5019 (TL: 560-5019)
www.ibm.com
www.eclipse.org/epf
Ricardo Balduino
Senior Software Engineer
IBM | RUP Team | EPF Committer
Phone: 1 (408) 863-5019 (TL: 560-5019)
www.ibm.com
www.eclipse.org/epf
epf-dev-request@xxxxxxxxxxx
Sent
by: epf-dev-bounces@xxxxxxxxxxx
02/10/2006 09:00 AM
Please
respond to
epf-dev
|
|
To
|
epf-dev@xxxxxxxxxxx
|
cc
|
|
Subject
|
epf-dev Digest, Vol 2, Issue 3
|
|
Message: 1
Date: Fri, 10 Feb 2006 17:17:23 +1100
From: ChrisDoyle@xxxxxxxxxxxxxx
Subject: [epf-dev] What do we do for an analysis
model
To: epf-dev@xxxxxxxxxxx
Message-ID:
<OF2BA98BB8.058BB295-ONCA257111.002218B3-CA257111.00228D45@xxxxxxxxxxxxxx>
Content-Type: text/plain;
charset="us-ascii"
Hi All,
I would like to ask a question regarding the
analysis discipline in BUP.
>From what I can see from the available
documents, there is a significant
jump from the use-case model to the use-case
realisation. In RUP and other
processes there are a number of tasks and work
products based around
domain analysis (analysis model).
>From my own experience on small to medium size
projects, a critical part
of any project has been domain analysis. Output
from domain analysis is a
domain model but looking at the BUP documents
there appears to be neither
glossary (which can provide some of the detail)
nor a domain object model.
So my question is should the analysis model be
left out of BUP and
mentioned as a "consideration" which can
be included by other plug-ins? No
doubt you considered this and I would be
interested in hearing your
thoughts. NB the BUP method content may already
have guidance on this
subject so I'm looking forward to seeing the BUP
plugin as a download (is
it available yet?).
Chris Doyle
Solution Specialist
Synergy Plus Pty Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/epf-dev/attachments/20060210/0a8566a0/attachment.html
------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
End of epf-dev Digest, Vol 2, Issue 3
*************************************