Home » Archived » EPF » Customizing lifecycle phases
| Customizing lifecycle phases [message #29541] |
Wed, 14 February 2007 22:28  |
Eclipse User |
|
|
|
Originally posted by: christopher.fuhrman.etsmtl.ca
Hello,
I have some questions about lifecycle phases, as I'm thinking of using
EPF in a scenario that involves higher ceremony software development. I
have long worked with the UP and RUP, so I very much understand the
concept of the 4 phases contained in OpenUP/Basic.
Of course, higher ceremony projects still fit into the four phases. But
I see a problem between phases as they fall into EPF, as I don't think
*all* of the disciplines' activities transition cleanly from one phase
to the next, even if the model and its WBS say they should.
An example of the problem is that higher ceremony projects may expect
certain artifacts to stabilize enough to go under change control, say,
after a formal peer review. Examples of these are requirements,
high-level design, low-level design and (possibly) code. Using the
OpenUP/Basic, these stabilization milestones fall somewhere within the
Elaboration and Construction phases, but not necessarily always on the
boundaries between the phases. In reality, iterations on a work product
not under change control are much less formal than those with change
control - change requests have to be filed, etc. The change control
example is just one dimension of the problem.
It would seem that the WBS (process) part of EPF requires defining
activities (and descriptors to tasks, work products, etc.) relative to a
*phase*. So, I think it means that I can't specify WBS differences for
evolving documents under change control within the same phase.
I see two solutions to this problem:
1) add more phases so that the change-control transitions are explicit
between phases (e.g., add a phase for when the requirements are not yet
under CC, for when the requirements *are* under change control but the
high-level design is not, etc.). This solution seems the most explicit,
since it becomes clear to all people what phase a project is in, because
such and such artifact is now under CC. It implies that if an artifact
is under CC, then any of the upstream (waterfall) artifacts are as well.
2) "fudge" the workflows in the existing 4 phases, so that I can take
into consideration CC or not. It seems that Activity diagrams can have
task descriptors with certain [conditions]. This option seems less clear
from a global perspective, but would benefit from "reusing" the
OpenUP/Basic model with perhaps fewer changes to it.
So, here are my questions related to the respective solutions I see:
1) Is it possible to add/modify lifecycle phases starting with the
OpenUP/Basic model, using the EPF plug-in approach?
2) Rather than adding finer-grained phases, how does a WBS take into
consideration the "if/then" notions of "work product under change
control" conditions?
For example, in OpenUP/Basic, the Lifecycle "Activity: Develop Solution
(for requirement) (within context)" has some alternative activities in
the workflow (using [major change] and [small change] and [trivial
change] transitions). This seems to accommodate the "gray area" between
changes. As I look at this same activity defined in the Transition
phase, I see that there is no longer the possibility for [major change],
which is consistent with the UP. So, within Elaboration and
Construction, [major change] is possible, but not in the Transition
phase. I'm wondering if this same compromise will work for my problem of
change-control transitions.
I realize that the tutorials for process authoring are "coming soon",
but I hope these questions will be welcomed just the same.
Regards,
Cris Fuhrman
|
|
|
| Re: Customizing lifecycle phases [message #29595 is a reply to message #29541] |
Thu, 15 February 2007 01:47  |
| Eclipse User |
|
|
|
Originally posted by: phaumer.xxx.com
Hello Cris.
Sorry about the missing tutorial. I promise I will provide them "soon". The
last one took me over 6h to do, so I just need to find such a large chunk of
time in my agenda. I will cover scenarios for creating processes top down
(tailoring an existing process) or bottom up (creating a process using
reusable capability patterns and method content). Here some quick answers
to your questions:
(1) The way I would do this is to create an new empty delivery process in my
own plug-in. I would then create the phases (using right-click
New-->Phase), iterations, milestones that you need manually. Then I would
start dragging in Capability Patterns from OpenUP. You could take a whole
iteration pattern in case you just want to make minor changes or drag in the
lower level patterns one by one if you really want to build up your new
phase iterations. In case you need to make changes you have the following
options: (a) Right-click->Local Contribution on an activity this will allow
to add new elements such as tasks to an existing activity without breaking
the link to the underlying pattern (i.e. changes to the pattern by us will
make it automatically into your process once you import a new openup plugin
version). (b) right-lick->Local Replacement Deep Copy: gives you your local
copy of an activity and its sub-elements that you can freely modify.
(2) Unfortunately decision points do not map nicely to WBS. So what we
decided to do was to just not represent them. If you create a decision point
in a diagram there will be no predecessor dependencies create between the
incoming and outgoing activities. The information about the decision is
only present in the Activity diagram. The WBS will just list the
participating activities and the user needs to decide if he wants to
instantiate an activity or task or not when he maps the process to a project
plan.
By coincidence, I modeled these patterns in OpenUP/Basic myself by creating
one capability pattern that had everything (i.e. both decision points) in
it. I applied the pattern in all three phase. However, for Transition I
did the following after dragging in the patterns and selecting Extends. I
right-clicked the Develop Architecture task descriptor and select suppress.
I then opened the diagram and adjusted the layout as the task descriptor and
its related decision points were hidden from the diagram now.
I hope this helps, at least from the tool usage perspective. Let us know
what you decided to do.
Peter.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Cris Fuhrman" <christopher.fuhrman@etsmtl.ca> wrote in message
news:er02eg$ei0$1@utils.eclipse.org...
> Hello,
>
> I have some questions about lifecycle phases, as I'm thinking of using EPF
> in a scenario that involves higher ceremony software development. I have
> long worked with the UP and RUP, so I very much understand the concept of
> the 4 phases contained in OpenUP/Basic.
>
> Of course, higher ceremony projects still fit into the four phases. But I
> see a problem between phases as they fall into EPF, as I don't think *all*
> of the disciplines' activities transition cleanly from one phase to the
> next, even if the model and its WBS say they should.
>
> An example of the problem is that higher ceremony projects may expect
> certain artifacts to stabilize enough to go under change control, say,
> after a formal peer review. Examples of these are requirements, high-level
> design, low-level design and (possibly) code. Using the OpenUP/Basic,
> these stabilization milestones fall somewhere within the Elaboration and
> Construction phases, but not necessarily always on the boundaries between
> the phases. In reality, iterations on a work product not under change
> control are much less formal than those with change control - change
> requests have to be filed, etc. The change control example is just one
> dimension of the problem.
>
> It would seem that the WBS (process) part of EPF requires defining
> activities (and descriptors to tasks, work products, etc.) relative to a
> *phase*. So, I think it means that I can't specify WBS differences for
> evolving documents under change control within the same phase.
>
> I see two solutions to this problem:
>
> 1) add more phases so that the change-control transitions are explicit
> between phases (e.g., add a phase for when the requirements are not yet
> under CC, for when the requirements *are* under change control but the
> high-level design is not, etc.). This solution seems the most explicit,
> since it becomes clear to all people what phase a project is in, because
> such and such artifact is now under CC. It implies that if an artifact is
> under CC, then any of the upstream (waterfall) artifacts are as well.
>
> 2) "fudge" the workflows in the existing 4 phases, so that I can take into
> consideration CC or not. It seems that Activity diagrams can have task
> descriptors with certain [conditions]. This option seems less clear from a
> global perspective, but would benefit from "reusing" the OpenUP/Basic
> model with perhaps fewer changes to it.
>
> So, here are my questions related to the respective solutions I see:
>
> 1) Is it possible to add/modify lifecycle phases starting with the
> OpenUP/Basic model, using the EPF plug-in approach?
>
> 2) Rather than adding finer-grained phases, how does a WBS take into
> consideration the "if/then" notions of "work product under change control"
> conditions?
>
> For example, in OpenUP/Basic, the Lifecycle "Activity: Develop Solution
> (for requirement) (within context)" has some alternative activities in the
> workflow (using [major change] and [small change] and [trivial change]
> transitions). This seems to accommodate the "gray area" between changes.
> As I look at this same activity defined in the Transition phase, I see
> that there is no longer the possibility for [major change], which is
> consistent with the UP. So, within Elaboration and Construction, [major
> change] is possible, but not in the Transition phase. I'm wondering if
> this same compromise will work for my problem of change-control
> transitions.
>
> I realize that the tutorials for process authoring are "coming soon", but
> I hope these questions will be welcomed just the same.
>
> Regards,
>
> Cris Fuhrman
|
|
|
| Re: Customizing lifecycle phases [message #29614 is a reply to message #29595] |
Thu, 15 February 2007 03:37 |
| Eclipse User |
|
|
|
Originally posted by: christopher.fuhrman.etsmtl.ca
Peter Haumer wrote:
> Hello Cris.
> Sorry about the missing tutorial. I promise I will provide them "soon". The
> last one took me over 6h to do, so I just need to find such a large chunk of
> time in my agenda. I will cover scenarios for creating processes top down
> (tailoring an existing process) or bottom up (creating a process using
> reusable capability patterns and method content). Here some quick answers
> to your questions:
Thank you so much for the detailed answers and the quick response.
Please do not apologize for "missing" tutorials. I am amazed at how much
exists so far, and I can only imagine how much work goes into them (6h
seems too short, did you include preparation time?).
[snip]
> I hope this helps, at least from the tool usage perspective. Let us know
> what you decided to do.
I think after what you have said, we'll be going the extra phase route.
It doesn't appear to be that difficult from the tool perspective and we
can reuse delivery process info from OpenUP/Basic. I will try to write
back once we've made some progress with some trials.
Thanks again,
Cris
--
Prof. Christopher Fuhrman
Department of Software and IT Engineering
University of Quebec - École de technologie supérieure (ETS)
http://profs.logti.etsmtl.ca/cfuhrman/index.shtml?en
+1 (514) 396 8638
|
|
|
| Re: Customizing lifecycle phases [message #576352 is a reply to message #29541] |
Thu, 15 February 2007 01:47 |
 Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Cris.
Sorry about the missing tutorial. I promise I will provide them "soon". The
last one took me over 6h to do, so I just need to find such a large chunk of
time in my agenda. I will cover scenarios for creating processes top down
(tailoring an existing process) or bottom up (creating a process using
reusable capability patterns and method content). Here some quick answers
to your questions:
(1) The way I would do this is to create an new empty delivery process in my
own plug-in. I would then create the phases (using right-click
New-->Phase), iterations, milestones that you need manually. Then I would
start dragging in Capability Patterns from OpenUP. You could take a whole
iteration pattern in case you just want to make minor changes or drag in the
lower level patterns one by one if you really want to build up your new
phase iterations. In case you need to make changes you have the following
options: (a) Right-click->Local Contribution on an activity this will allow
to add new elements such as tasks to an existing activity without breaking
the link to the underlying pattern (i.e. changes to the pattern by us will
make it automatically into your process once you import a new openup plugin
version). (b) right-lick->Local Replacement Deep Copy: gives you your local
copy of an activity and its sub-elements that you can freely modify.
(2) Unfortunately decision points do not map nicely to WBS. So what we
decided to do was to just not represent them. If you create a decision point
in a diagram there will be no predecessor dependencies create between the
incoming and outgoing activities. The information about the decision is
only present in the Activity diagram. The WBS will just list the
participating activities and the user needs to decide if he wants to
instantiate an activity or task or not when he maps the process to a project
plan.
By coincidence, I modeled these patterns in OpenUP/Basic myself by creating
one capability pattern that had everything (i.e. both decision points) in
it. I applied the pattern in all three phase. However, for Transition I
did the following after dragging in the patterns and selecting Extends. I
right-clicked the Develop Architecture task descriptor and select suppress.
I then opened the diagram and adjusted the layout as the task descriptor and
its related decision points were hidden from the diagram now.
I hope this helps, at least from the tool usage perspective. Let us know
what you decided to do.
Peter.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Cris Fuhrman" <christopher.fuhrman@etsmtl.ca> wrote in message
news:er02eg$ei0$1@utils.eclipse.org...
> Hello,
>
> I have some questions about lifecycle phases, as I'm thinking of using EPF
> in a scenario that involves higher ceremony software development. I have
> long worked with the UP and RUP, so I very much understand the concept of
> the 4 phases contained in OpenUP/Basic.
>
> Of course, higher ceremony projects still fit into the four phases. But I
> see a problem between phases as they fall into EPF, as I don't think *all*
> of the disciplines' activities transition cleanly from one phase to the
> next, even if the model and its WBS say they should.
>
> An example of the problem is that higher ceremony projects may expect
> certain artifacts to stabilize enough to go under change control, say,
> after a formal peer review. Examples of these are requirements, high-level
> design, low-level design and (possibly) code. Using the OpenUP/Basic,
> these stabilization milestones fall somewhere within the Elaboration and
> Construction phases, but not necessarily always on the boundaries between
> the phases. In reality, iterations on a work product not under change
> control are much less formal than those with change control - change
> requests have to be filed, etc. The change control example is just one
> dimension of the problem.
>
> It would seem that the WBS (process) part of EPF requires defining
> activities (and descriptors to tasks, work products, etc.) relative to a
> *phase*. So, I think it means that I can't specify WBS differences for
> evolving documents under change control within the same phase.
>
> I see two solutions to this problem:
>
> 1) add more phases so that the change-control transitions are explicit
> between phases (e.g., add a phase for when the requirements are not yet
> under CC, for when the requirements *are* under change control but the
> high-level design is not, etc.). This solution seems the most explicit,
> since it becomes clear to all people what phase a project is in, because
> such and such artifact is now under CC. It implies that if an artifact is
> under CC, then any of the upstream (waterfall) artifacts are as well.
>
> 2) "fudge" the workflows in the existing 4 phases, so that I can take into
> consideration CC or not. It seems that Activity diagrams can have task
> descriptors with certain [conditions]. This option seems less clear from a
> global perspective, but would benefit from "reusing" the OpenUP/Basic
> model with perhaps fewer changes to it.
>
> So, here are my questions related to the respective solutions I see:
>
> 1) Is it possible to add/modify lifecycle phases starting with the
> OpenUP/Basic model, using the EPF plug-in approach?
>
> 2) Rather than adding finer-grained phases, how does a WBS take into
> consideration the "if/then" notions of "work product under change control"
> conditions?
>
> For example, in OpenUP/Basic, the Lifecycle "Activity: Develop Solution
> (for requirement) (within context)" has some alternative activities in the
> workflow (using [major change] and [small change] and [trivial change]
> transitions). This seems to accommodate the "gray area" between changes.
> As I look at this same activity defined in the Transition phase, I see
> that there is no longer the possibility for [major change], which is
> consistent with the UP. So, within Elaboration and Construction, [major
> change] is possible, but not in the Transition phase. I'm wondering if
> this same compromise will work for my problem of change-control
> transitions.
>
> I realize that the tutorials for process authoring are "coming soon", but
> I hope these questions will be welcomed just the same.
>
> Regards,
>
> Cris Fuhrman
|
|
|
| Re: Customizing lifecycle phases [message #576405 is a reply to message #29595] |
Thu, 15 February 2007 03:37 |
| Eclipse User |
|
|
|
Originally posted by: christopher.fuhrman.etsmtl.ca
Peter Haumer wrote:
> Hello Cris.
> Sorry about the missing tutorial. I promise I will provide them "soon". The
> last one took me over 6h to do, so I just need to find such a large chunk of
> time in my agenda. I will cover scenarios for creating processes top down
> (tailoring an existing process) or bottom up (creating a process using
> reusable capability patterns and method content). Here some quick answers
> to your questions:
Thank you so much for the detailed answers and the quick response.
Please do not apologize for "missing" tutorials. I am amazed at how much
exists so far, and I can only imagine how much work goes into them (6h
seems too short, did you include preparation time?).
[snip]
> I hope this helps, at least from the tool usage perspective. Let us know
> what you decided to do.
I think after what you have said, we'll be going the extra phase route.
It doesn't appear to be that difficult from the tool perspective and we
can reuse delivery process info from OpenUP/Basic. I will try to write
back once we've made some progress with some trials.
Thanks again,
Cris
--
Prof. Christopher Fuhrman
Department of Software and IT Engineering
University of Quebec - École de technologie supérieure (ETS)
http://profs.logti.etsmtl.ca/cfuhrman/index.shtml?en
+1 (514) 396 8638
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:30:00 GMT 2024
Powered by FUDForum. Page generated in 0.04525 seconds |
] 
Search
Help
Register
Login
Home
