[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] Re: What do we do for an analysis model
|
I don´t think that a domain model can be considered a "big upfront
design"... and from my experience I can tell that it helps to understand
the use case model... and even for some of our customers it is easy to
say that "one person can have more that one car"... than writing the use
cases for the car management system... not all the requirements can be
expressed in the form of use cases... I see a domain model as a product
from business modeling instead of analysis
we have been working with a basic "home made" version of the unified
process in the last years and what has worked for us is clear
requirements (domain model&glossary + use case specifications) and a
solid architecture, that provides guidelines for the developers... most
of the time the use cases are so clear that the developers skip "formal
analysis and design" and spend more time on unit testing instead... the
only analysis that we don´t give up is the user interface analysis
(navigation map, prototype etc) .. but I dont see that in the BUP as
well ... even in a minimal process I think that it should be considered...
regards
Ana
WSA Consulting Inc wrote:
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
*************************************
------------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
