Skip to main content

[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

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
*************************************


Back to the top