Home » Archived » EPF » What level of granularity of Published Plugins should we be aiming to build?
| What level of granularity of Published Plugins should we be aiming to build? [message #23988] |
Sat, 18 November 2006 17:42  |
Eclipse User |
|
|
|
Based on comments made in the EU F2F meeting on 9/10 Nov on this subject and
my subsequent reading up of the EPF-Composer / SPEM 2 presentations found on
this newgroup; I am still a little in the dark as to where EPF is headed in
terms of the level of granularity we should be aiming for in producing
Process Plugins. (I must just add I'm relatively new at using EPF-C)
I think it's probably safe to say that the level of OpenUP is a little too
granular because if any processes extends or modifies the base process, the
dependencies of other processes on changes to OpenUP might be too closely
coupled (i.e. Any change to the basic OpenUP might render multiple dependent
processes faulty which could require rework or worse totally invalidate
parts of them.) I think it makes more sense to publish Processes the size of
say Scrum for example; at the Discipline level of granularity not the
overall whole process level?
Per Kroll suggested that we probably need to bed down some of the major
Process Plugins end-to-end before starting on the more add-on type
components, which makes sense, because we can then refactor everything later
as we reach a more comfortable level and it beds down.
I ask this because I'd like to write some extension plugins that could
extend various processes such as OpenUP, Scrum, etc. I'm thinking of doing
an "Iterative Risk Management" Plugin or an "Estimation and Metrics Tracking
Plugin" which would extend the normal level of detail mentioned in OpenUP
for example.
Also this begs the question - if I was to write this Risk Management lower
level granularity plugin as open, would it be published on the website with
OpenUP at the current version? Or would it be published as a stand alone
plugin, even through it extends OpenUP? What if someone on their own
tailored project process website wanted to use it, but they had already
extended another version of the OpenUP?
Comments?
regards
---------------------------------------------------
Charles Edwards - Processwave
--------------------------------------------------
|
|
|
| Re: What level of granularity of Published Plugins should we be aiming to build? [message #24054 is a reply to message #23988] |
Mon, 20 November 2006 16:40  |
| Eclipse User |
|
|
|
Originally posted by: phaumer.xxx.com
Hello Charles.
This is a good question. There are two main criteria for making this
plug-in design decision: (1) configurability and (2) ownership.
(1) The idea behind method plug-in is that these are the real configuration
units. Something you distribute and install or something that you select
for inclusion/exclusion into a method configuration. Hence, if you develop
a true optional extension to OpenUP then you create it as a plug-in. If you
create several extensions you indeed look to minimize dependencies and
analyze cohesion amongst you method elements to decide if you combine them
into one or several plug-ins.
As I understand the current design decision of OpenUP Basic to place
everything into one plug-in, it is because it represents the minimal but
complete process with just a few minor optional elements here and there. For
example, you can get rid of visual modeling or use case models with package
level configurations, but overall this is supposed to be one unit. It is
not possible to get rid of roles, for example, because the roles defined in
Basic are all the essential roles one needs.
(2) As plug-ins are represented as files you might want to consider
ownership for your decision as well. Because, the current version control
scheme in EPFC does not support concurrent development with
branch-compare-merge you need to make sure that all your different authors
have access to more or less their own files. Hence, plug-ins can be created
based on different content areas or domains different authors are working on
in parallel. See the version control guide on the EPF homepage for details,
but basically a plug-in is represented as one plugin.xmi file plus the rich
text content for each element is placed into its own separate file. The
idea is that one plugin designer creates elements and models their
relationships and that content developers or authors write the element's
contents in parallel.
In respect to your last question: When you publish you either select (a) a
configuration, which could combine any set of plug-in and package
selections. Hence, you could publish your RM content standalone as well as
an extension to OpenUP Basic. You just need to create two configurations
for both cases that reference the right plugins and content packages. Or
(b) you select a process such as a delivery process and you would publish
everything used by that process only.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Charles Edwards" <charles.edwards@processwave.com> wrote in message
news:ejo29v$ibl$1@utils.eclipse.org...
> Based on comments made in the EU F2F meeting on 9/10 Nov on this subject
> and my subsequent reading up of the EPF-Composer / SPEM 2 presentations
> found on this newgroup; I am still a little in the dark as to where EPF is
> headed in terms of the level of granularity we should be aiming for in
> producing Process Plugins. (I must just add I'm relatively new at using
> EPF-C)
>
> I think it's probably safe to say that the level of OpenUP is a little too
> granular because if any processes extends or modifies the base process,
> the dependencies of other processes on changes to OpenUP might be too
> closely coupled (i.e. Any change to the basic OpenUP might render multiple
> dependent processes faulty which could require rework or worse totally
> invalidate parts of them.) I think it makes more sense to publish
> Processes the size of say Scrum for example; at the Discipline level of
> granularity not the overall whole process level?
>
> Per Kroll suggested that we probably need to bed down some of the major
> Process Plugins end-to-end before starting on the more add-on type
> components, which makes sense, because we can then refactor everything
> later as we reach a more comfortable level and it beds down.
>
> I ask this because I'd like to write some extension plugins that could
> extend various processes such as OpenUP, Scrum, etc. I'm thinking of doing
> an "Iterative Risk Management" Plugin or an "Estimation and Metrics
> Tracking Plugin" which would extend the normal level of detail mentioned
> in OpenUP for example.
>
> Also this begs the question - if I was to write this Risk Management lower
> level granularity plugin as open, would it be published on the website
> with OpenUP at the current version? Or would it be published as a stand
> alone plugin, even through it extends OpenUP? What if someone on their
> own tailored project process website wanted to use it, but they had
> already extended another version of the OpenUP?
>
> Comments?
>
> regards
> ---------------------------------------------------
> Charles Edwards - Processwave
> --------------------------------------------------
>
>
|
|
|
| Re: What level of granularity of Published Plugins should we be aiming to build? [message #568763 is a reply to message #23988] |
Mon, 20 November 2006 16:40 |
| Eclipse User |
|
|
|
Hello Charles.
This is a good question. There are two main criteria for making this
plug-in design decision: (1) configurability and (2) ownership.
(1) The idea behind method plug-in is that these are the real configuration
units. Something you distribute and install or something that you select
for inclusion/exclusion into a method configuration. Hence, if you develop
a true optional extension to OpenUP then you create it as a plug-in. If you
create several extensions you indeed look to minimize dependencies and
analyze cohesion amongst you method elements to decide if you combine them
into one or several plug-ins.
As I understand the current design decision of OpenUP Basic to place
everything into one plug-in, it is because it represents the minimal but
complete process with just a few minor optional elements here and there. For
example, you can get rid of visual modeling or use case models with package
level configurations, but overall this is supposed to be one unit. It is
not possible to get rid of roles, for example, because the roles defined in
Basic are all the essential roles one needs.
(2) As plug-ins are represented as files you might want to consider
ownership for your decision as well. Because, the current version control
scheme in EPFC does not support concurrent development with
branch-compare-merge you need to make sure that all your different authors
have access to more or less their own files. Hence, plug-ins can be created
based on different content areas or domains different authors are working on
in parallel. See the version control guide on the EPF homepage for details,
but basically a plug-in is represented as one plugin.xmi file plus the rich
text content for each element is placed into its own separate file. The
idea is that one plugin designer creates elements and models their
relationships and that content developers or authors write the element's
contents in parallel.
In respect to your last question: When you publish you either select (a) a
configuration, which could combine any set of plug-in and package
selections. Hence, you could publish your RM content standalone as well as
an extension to OpenUP Basic. You just need to create two configurations
for both cases that reference the right plugins and content packages. Or
(b) you select a process such as a delivery process and you would publish
everything used by that process only.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Charles Edwards" <charles.edwards@processwave.com> wrote in message
news:ejo29v$ibl$1@utils.eclipse.org...
> Based on comments made in the EU F2F meeting on 9/10 Nov on this subject
> and my subsequent reading up of the EPF-Composer / SPEM 2 presentations
> found on this newgroup; I am still a little in the dark as to where EPF is
> headed in terms of the level of granularity we should be aiming for in
> producing Process Plugins. (I must just add I'm relatively new at using
> EPF-C)
>
> I think it's probably safe to say that the level of OpenUP is a little too
> granular because if any processes extends or modifies the base process,
> the dependencies of other processes on changes to OpenUP might be too
> closely coupled (i.e. Any change to the basic OpenUP might render multiple
> dependent processes faulty which could require rework or worse totally
> invalidate parts of them.) I think it makes more sense to publish
> Processes the size of say Scrum for example; at the Discipline level of
> granularity not the overall whole process level?
>
> Per Kroll suggested that we probably need to bed down some of the major
> Process Plugins end-to-end before starting on the more add-on type
> components, which makes sense, because we can then refactor everything
> later as we reach a more comfortable level and it beds down.
>
> I ask this because I'd like to write some extension plugins that could
> extend various processes such as OpenUP, Scrum, etc. I'm thinking of doing
> an "Iterative Risk Management" Plugin or an "Estimation and Metrics
> Tracking Plugin" which would extend the normal level of detail mentioned
> in OpenUP for example.
>
> Also this begs the question - if I was to write this Risk Management lower
> level granularity plugin as open, would it be published on the website
> with OpenUP at the current version? Or would it be published as a stand
> alone plugin, even through it extends OpenUP? What if someone on their
> own tailored project process website wanted to use it, but they had
> already extended another version of the OpenUP?
>
> Comments?
>
> regards
> ---------------------------------------------------
> Charles Edwards - Processwave
> --------------------------------------------------
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 25 19:09:30 EDT 2025
Powered by FUDForum. Page generated in 0.07169 seconds |
Home