Hi Folks,
My $.02:
Glossary: I think in the majority of cases
this is a must to ensure everyone is speaking the same language. I don’t
think there will be too much pushback by including it as an optional artifact,
to be included depending upon the knowledge of the team with the application domain.
Where to put it, RM domain?
GUI architecture: defer to the experts 8-)
Interface requirements: absolutely
essential in my humble opinion, but could easily be a section of the supporting
requirements (since they are constraints).
Business Rules: hmmm. I think Use
Case and supporting requirements should be able to capture the business rules.
Data Modeling: defer to the experts.
Deployment: I think we should include this
in BUP, timing will depend upon priorities and available time.
Cheers,
Chris
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Tuesday, April 04, 2006 2:01
PM
To: Eclipse
Process Framework Project Developers List
Subject: [epf-dev] Overarching
considerations (was: Status from 3/30 BUPcall with authors)
Ana
Thank
you for your observations.
I
think these are good points to discuss with each subgroup (or discipline
owners) as pointed in the email below. You may want to join these groups or
interact with the listed owners.
In
a nutshell, the discussion should be around:
-
if glossary and rules have to be captured, are they worth of having their own
artifact or being in a section inside the Vision? The former increases number
of artifacts in BUP (do we desire that?) as where as the later, although seems
to preserve the number of artifacts, may cause the Vision doc to be cluttered.
-
GUI architecture: we may consider a guideline explaining how to address these
concerns. Is this something you would like to contribute to by writing such
guideline, in case we decide to cover it?
-
Interface with external systems: these systems (who) should be captured and
described as actors in the Use Case model. Any further description in terms of types
of interaction (what) is expected with these systems could be seen as
Supporting Requirement and captured in such artifact. But we may need to
revisit architecture/development tasks to eventually include step or guidance
(how) to develop interfaces to such systems.
-
Data modeling hasn't been discussed to be in BUP (yet, as far as I remember).
Could it be in a plug-in later?
-
Deployment: we've been postponing a more serious consideration of that
discipline in BUP. My take is that we should cover the essentials of it, and your
suggestions below seem adequate. Now it's a decision on if we include it in
release 1.0 in September or later. I see it in core BUP though, not as a
plug-in. If we decide for having it, would you be willing to add content on
that?
Comments
anyone?
Cheers,
Ricardo Balduino
IBM | EPF Committer
Ana Valente Pereira
<apereira@xxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
04/02/2006 04:39 AM
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
To
|
Eclipse Process Framework
Project Developers List
<epf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [epf-dev] Status from 3/30 BUP call with
authors
|
|
Sorry
for this long mail but I will have no access to the internet for
the next 2 weeks and I wont be able to attend the
next conference call….
so I will try to resume all my content authoring
ideas for contributing
to BUP 1.0 here… you can move to bugzilla
what you agree to add and I
will pick up work when I come back
As I told in Bilbao meeting, my experience with
the RUP comes from
several years of “small projects “
(teams of 3 to 6 people and involve 3
to 6 months of development effort) … and
there are some good practices
that I would like to see in BUP, even in small
projects, otherwise I
believe there will be a lot of plug-ins to BUP
adding these basic things:
Requirements:
... vision and use cases are not enough in
requirements ...even in small
projects:
1) Glossary: if you don’t define project
domain terms somewhere the
definition will end-up mixed with the use
cases… when needed we also add
a simple domain model to the glossary (this is not
big upfront
design…see
(http://www.agiledata.org/essays/agileDataModeling.html) …
and sometimes stakeholders express their
requirements in these terms
more easily than in use cases (I want a shopping
cart) … can we add a
Glossary to BUP?… or at least a chapter to
the Vision?
2) Rules: the same for business rules: separate
business rules out of
use cases… rules are also requirements that
can developed separately …
if they are spread out on use cases they will end
up spread out in the
code… can we add a Rule Catalog artifact to
BUP or a specific section on
the Supporting Requirements? (I am quoting Scott
Ambler again but I know
that he is reading this email list
http://www.agilemodeling.com/artifacts/businessRule.htm)
… sometimes
stakeholders don’t care much about reading
use cases but they do care
about getting business rules definition right
Architecture
… get stakeholders involved in the
architecture (at the system boundaries)
1) GUI Architecture - If we let the developers
pick up scenarios and
implement them without some kind of user interface
guidelines and global
mechanisms (menus structure,, navigation map
… etc) the GUI will be a
mess … even with the prototype … I
think that it is missing some kind of
user Interface structuring and guidance …
can we add these
responsibility to the architect or analyst?...and
discuss it with the
stakeholder along with the prototype?
2) Interface with external Systems – more
and more we have to develop
code for systems where the actor is not a person
but another system. The
architect should identify these communication
interfaces and discuss
them with the stakeholders responsible for those
systems …because
usually external systems have to be modified to
use the services we are
providing (or vice-versa) this is not a bit
discussion on SOA (the
interface can be a file or a stored procedure, for
instance) …but it can
lay out the foundation for a SOA plug-in to BUP
latter … this is part of
the architecture but we can’t put in on
Software Architecture Document
because stakeholders usually don’t read
these document … but they need
it…I think that we also need a step on Task:
Analyze the Architecture on
this subject (identify external services?)
3) There is nothing on Data Modeling on BUP? (even
agile?)
Deployment…there is no deployment
discipline? What is the purpose of
making the software if it is not for deploying?
…what is the purpose of
Transition Phase in BUP ? it does not have to be a
lot of content … I
propose that we consider the minimum:
1) If we have a Build work product on
Implementation I would add a
“Release” work product on deployment
with some System Requirements,
Installation Instructions and known issues …
we have an example on
(http://www.eclipse.org/epf/downloads/downloads.php)
…and add a task for
Create Release
best regards
Ana Pereira
Brian Lyons wrote:
> hiho,
>
> On Thursday, 3/30 at 8am PST, there was a
conference call on assigning
> ownership to BUP content as we modify and
complete the IBM donation
> for the 1.0 launch scheduled for 9/1/2006.
>
> On the call were:
>
> · Steve Adolph, UBC
>
> · Ricardo Balduino, IBM
>
> · Mark Dickson, Xansas/DSDM Consortium
>
> · Chris Doyle, Synergy Plus
>
> · Brian Lyons, Number Six Software,
Inc.
>
> · Bruce MacIsaac, IBM
>
> · Jim Ruehl, IBM
>
> · Chris
Sibbald, Telelogic
>
> We decided to have each content package in
BUP assigned to a committer
> (or – based on duration it is taking
– someone on track to be a
> committer). We discussed that the templates
package is not really a
> logical separate area, but only broken out for
convenience of process
> engineers; each template would be the
responsibility of the owner of
> the relevant discipline. In this pass the
Process is not the focus.
>
> The assignment of a package does not imply
that the individual is
> solely responsible for authoring all the
content. The assignment of
> the package is responsibility that the
content gets authored.
>
> Based on the participants on the call, the
responsible parties are
> shown below. One addition is that we have a
pending decision on
> project management because Kirti Vaidya had
proclaimed an interest in
> that, but was not on the call.
>
> *Package*
>
>
>
> *Owner*
>
> architecture
>
>
>
> Chris Dickson, Xansas
>
> change_management
>
>
>
> <vacant>
>
> development
>
>
>
> <vacant>
>
> general
>
>
>
> Steve Adolph, UBC
>
> project_management
>
>
>
> Kirti Vaidya, Covansys (pending)
>
> requirements
>
>
>
> Chris Sibbald,
Telelogic
>
> test
>
>
>
> Brian Lyons, Number Six Software
>
> Ricardo Balduino of IBM will manage the
overall architecture of the
> process. Based on the way EPF Composer works,
Ricardo will be
> responsible for managing all relationships
between elements. And he is
> responsible for creating any additional
elements that will
> subsequently be assigned to reside in a
package.
>
> If you are a committer or on your way to
becoming one and you have an
> interest in being responsible for cm or
development, please reply.
>
> Everyone interested in contributing content
should be getting Eclipse
> setup for CVS to access BUP. That is the best
way to get the most
> up-to-date content. This is the real-time
development repository that
> committers check their work into. Official
committers have read-write
> access, but anyone can use it to regularly
pull the very latest content.
>
> There will be a conference call on Thursday,
4/6 at 8am PST to discuss
> updates and status of this work. We have a
milestone on 4/15 to be
> underway with authoring content and have all
elements defined (albeit
> possibly incomplete). As the various
guidelines are often driven by
> the detail in the other process elements, we
are giving ourselves some
> leeway in not strictly baselining those by
that date.
>
> ------------ b
>
>------------------------------------------------------------------------
>
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>
>
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev