[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Intro page + Plus comments for all content leads++
|
Hello Per,
Concerning the additional roles for the tasks in intent I
agree that the Architect, Developer and Test should be additional roles to
ensure requriements are feasible and verifiable. I propose we add these
three additional performers to the three tasks in
requirements.
The three requirements tasks contain the step Achieve
Concurence. I think they fine as is, along with the associate
guidance Effective Requirements Reviews as these two elements do discuss
internal reviews to ensure that requirements are feasible and verifiable.
If you think there should be an additional sentence added to the step: Achieve
Concurence I have no problem with that. Let me know what you think and I
will create bugzilla entries and make the changes.
Cheers,
Chris
Hi, attached you find my draft description of each subprocess
and the foundational collaboration layer. I am writing this disconnected, so
cannot put it into bugzilla right now. The text would probably benefit from a graph for each sub-process to
capture the essence of that sub-process. I have not yet reflected on what such a
graph may look like. As I wrote the
text, I made a number of comments that I hope is a good read for all content
leads, as well as other people writing content. I e.g. suggest changes to most
of the tasks in Intent and Solutions Development to better reflect collaborative
development, with more roles involved in the various tasks. I think the
counter-argument is that if every role needs to participate in every task, does
that not only clutter the model? That would be a valid concern, but as a
minimum, we need to make sure that it is crystal clear to the analyst that they
should not only capture requirements, but that they need to involve developers,
architects and testers to validate the requriements and ensure that they are
understood. This could be done through a simple change to the step "Achieve
Concurrence". The same type of thinking probably applies to most or at least
many tasks in the intent and solutions development sub-processes.
Comments? Cheers Per
Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process
Framework
Rational Software, IBM Corp
408-342-3815
Bruce
Macisaac/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx
09/14/2006 09:01 PM
|
Please respond
to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx> |
|
|
To
| steve@xxxxxxxxxxxxxxxxx
|
|
cc
| "'Eclipse Process Framework Project
Developers List'" <epf-dev@xxxxxxxxxxx>
|
|
Subject
| [epf-dev] Intro
page |
|
Hi Steve,
As you recall, at Wednesday's status meeting I
expressed the concern that the intro graphic, while cool, introduces another set
of things that look a lot like the disciplines, which could be confusing.
To address this concern, Per has agreed to draft up some pages for each of
these areas.
After Sept 30, we can further explore my proposal to align these
areas with the disciplines.
(For reference, here is what I had in mind - although from informal
discussions, it looks like it will take a while to gel):
- rename "Intent" to be "Requirements",
to match the discipline
- Solution would have sub-disciplines of Implementation, Test, AnD,
and later deployment.
- Management would have CM and Project Management, and later
Environment.
-
Communication and Collaboration becomes a new discipline that describes general
concepts and responsibilities of all team members.
For now, the Any Role and "submit a
change request" would be in this discipline. Longer term would be general
review procedures, guidance on scrums, searching for reusable assets and
providing feedback, resolving conflict, etc.)
Hope that works for you.
Cheers,
Bruce MacIsaac
Manager - RUP/OpenUP
Content
bmacisaa@xxxxxxxxxx
phone: (408)863-8718
_______________________________________________
epf-dev mailing
list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
