You’ve provided some very
interesting insights, Onno. Based on what you wrote, here’s a potential
list that we could present to introduce the benefits of using the Wiki tool
with OpenUP:
- Increase
process performance with timely and specific guidance.
- Improve
process customization by easily documenting the actual process on top of
the defined process.
- Capture
process related experience through pattern harvesting and process-related
experiences.
- Rapidly
gather useful feedback by directly editing process content. (is this part
of 1 & 2?)
- Improve
process content without learning the metamodel or Composer (is this part
of 1 & 2?)
It seems like this list (or one like it)
would be useful to people who were evaluating whether to use OpenUP with the
Wiki. Comments?
Regarding #2 above, is Onno’s distinction
between actual vs defined process one that we should elaborate on in OpenUP
process guidance? Perhaps in some guidance about how to use OpenUP?
- Jim
____________________
Jim Ruehlin, IBM
Rational
RUP Content
Developer
Eclipse Process
Framework (EPF) Committer
email:
jruehlin@xxxxxxxxxx
phone:
760.505.3232
fax:
949.369.0720
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Straaten, Onno van
der" <onno.van.der.straaten@xxxxxxxxxxxxx>
Sent: Tuesday, August 08, 2006
1:14 AM
To: "Eclipse Process
Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
Subject: RE: [epf-dev] How to
access the OpenUP Wiki
What helps me think about purpose, usage
of Wiki technology, is scope. Within my company we found it usefull to
distinguish two: project and enterprise. Now of course there is also the OpenUP
community, the internet public and maybe more? An interesting idea was
discussed yesterday of offering this as a internet service, so there would be
no need to install software for EPF users to have Wiki functionality.
More in scope of the project or enterprise
is I think that it can help raise the ability to perform a process because
guidance can be added quickly and by everyone.
Another interesting viewpoint is I think
the distinction between standard processes and defined processes as described in
CMMI. Maybe for instance OpenUP is a standard process that is described at a
more general level that may not be directly usable to perform a process, or put
in another maybe better way, to have a good ability to perform it. A Wiki can
help when elaborating the process description so that the resulting defined
process can be performed. And Wiki in this respect means quick changes and
improvements and fast acceptance.
What I also like is that is a good tool
for capturing process-related experiences. When starting from a standard
process such as OpenUP or the RUP it can help bridge the gap between the
process description and the actual processes.
Best Regards,
Onno
.
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Ruehlin
Sent: maandag 7 augustus 2006
17:28
To: epf-dev@xxxxxxxxxxx
Subject: RE: [epf-dev] How to
access the OpenUP Wiki
The Wiki’s purpose is threefold (at
least as currently identified):
- Gather
feedback more powerfully than a mechanism such as email. Authors can
attach comments to a page, but also add/modify the page directly. Actually
changing content to describe an idea is more powerful than just describing
the idea. Email only provides the later.
- Identify
process patterns. Patterns are generally not discovered by discrete
descriptions. They emerge by abstracting common elements from specific
examples. Often those examples don’t explicitly describe those
abstractions. A Wiki can make patterns more apparent by showing them
“in use” with commentary and context. Code “smell”
is an example of this, where users can’t quite explain how they know
some code is bad, but they can give examples, build on top of existing
issues, talk around and over the problem, etc.
- Empower
practitioners to create content without the need to learn Composer or to
worry much about metamodels and such. Process engineers can take these
Wiki enhancements and add them to the process through Composer.
- Jim
____________________
Jim Ruehlin, IBM
Rational
RUP Content
Developer
Eclipse Process
Framework (EPF) Committer
email:
jruehlin@xxxxxxxxxx
phone:
760.505.3232
fax:
949.369.0720
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of "Scott W. Ambler" <swa@xxxxxxxxxxxx>
Sent: Monday, August 07, 2006 8:05
AM
To: "Eclipse Process
Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
Subject: Re: [epf-dev] How to
access the OpenUP Wiki
On Fri, August 4, 2006 6:19 pm, Peter Haumer
said:
< snip>
> In the same call we define a process on how to use the Wiki with the
> public,
Is the goal of the Wiki just to be able to gather input from the public
from a single source (e.g. we have a Wiki set up on the web which anyone
can post to) or is it something that we can publish to (e.g. instead of
generating straight HTML pages, we generate Wiki pages).
If the latter, it seems to me that we need to be able to support a range
of Wikis.
> how to harvest feedback, assign responsibilities (e.g. discipline
> owners harvest from their disciplines), when and how generate Bugzilla's,
> when to upload new versions of OpenUP to the Wiki, etc.
Shouldn't the Wiki just link to the current download page to keep it easy?
> We write up an introduction page for the public wiki experiment explaining
> the scope and communicating the usage model to be posted in the Wiki as
> well as EPF homepage.
Make sense.
> We clean-up the Wiki, upload the latest OpenUP version, and announce the
> Wiki experiment to the public
The Wiki needs to be as easy to use as possible. If we're only using it
to gather feedback, how is this any better than a mailing list?
- Scott
Practice Leader Agile Development, IBM Rational
http://www.ambysoft.com/scottAmbler.html
Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html
) is now
available.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
This e-mail and any attachment is for
authorised use by the intended recipient(s) only. It may contain proprietary
material, confidential information and/or be subject to legal privilege. It
should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
_______________________________________________
