Hi Folks,
Ricardo is correct. At the June 12 RM content review
we discussed moving the method elements related to Use Cases (Guideline,
Concept, Checklist) to a separate sub-package. The method elements related
to Use Cases and Actors would remain in the base requirements package.
We did not discuss making OpenUP/Basic agnostic of requirements technique
at that meeting.
I vote for a package named uc_modeling within the
scope of the requirements package.
My $0.02
Cheers,
Chris
Hi all, I haven't necessarily brought up the discussion on making
OpenUP/Basic agnostic of requirements technique - at least not now - meaning
that we would refactor how use cases are used throughout the method. Though
that's important, it would demand a broader discussion on what is then the
generic requirement type that would be used as input/output of tasks when use
cases are suppressed. Is that something we want to discuss an incorporate in our
tight schedule for release 1 or should we postpone the discussion for release
2?. My point here was about use case
modeling (use-case diagrams, namely). Only the use-case model artifact and
related guidance/tasks would be refactored to this package (not the use case
spec nor the actor - these would still be at the high level package for now,
until we refactor things out as mentioned in the paragraph above).
Scott referred the various types of
modeling considered by Agile Modeling (AM), where use cases fit under Usage
Modeling. I wonder if a broader discussion on how to add Agile Modeling on top
of OpenUP/Basic would help to clarify this. Scott is that something you would
like to drive? :-) This discussion is
important, because the way AM defines this seems to be different than what I
stated above: for AM, use-case specs, actors, use-case diagrams and such would
be under this notion of Usage Modeling, not only use-case diagrams - the visual
modeling part of use-case approach - as I was considering. From the responses I got so far (thank you, by the way)
it seems the preferred approach is to keep separate sub-packages under each main
package. The question is whether to generically call these packages
visual_modeling or be more specific, like uc_modeling (under
requirements). Any more thoughts?
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
"Brian Lyons"
<blyons@xxxxxxxxxxxxx> Sent by: epf-dev-bounces@xxxxxxxxxxx
06/20/2006 06:41 AM
Please respond
to Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx> |
|
To
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [epf-dev] Refactoring of Visual
Modeling packages |
|
hiho,
This is a key distinction. The usage of use cases vs.
some other
requirements technique is a completely different decision than the
usage
of visual modeling.
I appreciate that we have the sub-packages.
We just need to think of
the process repository architecture that best
serves our need going
forward with more and more optional sub-packages (given
the reasonable
premise that WAGNI -- we are gonna need it).
There will
be techniques per discipline that could be factored in or
out, especially
once the tool and process are adopted by the community
at large. There
also will be families of related techniques that cross
disciplines. My
opinion would be that a consistent organizational
technique that is intuitive
and usable for each of the above
circumstances would be to localize the
sub-packages to give context to
the process engineer and then deal with
cross-discipline things like
visual modeling like it is now: just have
identically named sub-packages
in multiple disciplines.
We will also
need to find a way to communicate more complex notions on
how these
sub-packages fit in. You might say: here are a set of
explicit
requirements techniques and you must pick one to have a
complete process.
You might say: these two techniques are mutually
exclusive. For
the moment, these nuances can just go in the Brief
Description of the
sub-package.
So, I suggest that we keep the sub-packages as-is and add a
use cases
sub-package within the requirements discipline.
--------- b
-----Original Message-----
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of
Scott W. Ambler
Sent: Tuesday, June 20, 2006 8:03 AM
To: Eclipse Process
Framework Project Developers List
Subject: Re: [epf-dev] Refactoring of
Visual Modeling packages
How about calling the package modeling instead
of
visual_modeling? Many of the modeling artifacts, such as use cases
and business rules specifications, are textual in nature not
visual.
Shouldn't we go for something a bit more generic?
-
Scott
At 01:50 PM 6/19/2006, you wrote:
>Hi
all,
>
>As part of implementing bug "Refactor Use-Case Model into
separate
>package (https://bugs.eclipse.org/bugs/show_bug.cgi?id=147349),
I
>though of creating a package called visual_modeling (under
>Requirements package), following the same convention used in
>Architecture and Development packages.
>
>Another level of
refactoring I though could be useful - that I would
>like to ask your
opinion about - is: should we put all these vm
>packages together in only
one package called visual_modeling? This
>package would be outside of
Architecture, Development and RM, but
>would contribute stuff to each of
them. This would offer an
>all-or-nothing approach, where visual modeling
is fully included in
>a given configuration or
not.
>
>Please, let me know what you think. If there aren't strong
contrary
>opinions, I'll proceed with the
refactoring.
>
>Thanks,
>
>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
mailing
list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
====================================================
Scott
W. Ambler :-)
Practice Leader Agile Development, IBM
Rational
www.ambysoft.com/scottAmbler.html
Every organization gets the
process that it deserves.
Refactoring Databases: Evolutionary Database
Design
(www.ambysoft.com/books/refactoringDatabases.html) is now available.
_______________________________________________
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
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com
Chris Sibbald
Vice President, Standards and Technology
Telelogic North America Inc.
255 Albert Street, Suite 600
Ottawa
Ontario
K1P 6A9
Canada
Phone: +1 (613) 266 5061
Fax: +1 (613) 482 4538
Mobile phone: +1 (613) 266 5061
Chris.Sibbald@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------
The information contained in this e-mail, including any attachment or enclosure, is intended only for the person or entity to which it is addressed and may contain confidential material. Any unauthorized use, review, retransmissions, dissemination, copying or other use of this information by persons or entities other than the intended recipient is prohibited.