- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
email: <mailto:jruehlin@xxxxxxxxxx>jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax: 949.369.0720
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf
Of "Chris Sibbald" <Chris.Sibbald@xxxxxxxxxxxxx>
Sent: Tuesday, April 04, 2006 12:44 PM
To: "Eclipse Process Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
Cc: External Chris Sibbald <csibbald@xxxxxxxx>
Subject: RE: [epf-dev] Overarching
considerations (was: Status from3/30 BUPcall with authors)
Hi Ricardo,
There is actually a fairly widely accepted
requirement sub-type known as an Interface
Requirement. (Remember the + in FURPS+).
In my previous email I was referring to external
interfaces to other systems (not the UI).
Although one could consider the UI as an
interface requirement, I wouldnt think of it
that way since this immediately places a
constraint on development so its probably
better to have some wiggle room and call it a
prototype vs. an interface requirement. Once
you call it a requirement expectations are set
accordingly. (Note that there may very well be
valid constraints on the UI, such as
accessibility requirements which should be captured and verified).
As I said I will defer GUI
architecture/prototype to the experts 8-). We
do currently have an artifact for the ui_prototype in BUP.
Cheers,
Chris
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Tuesday, April 04, 2006 2:49 PM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] Overarching
considerations (was: Status from3/30 BUPcall with authors)
Chris,
Considering that Supporting Requirements capture
the 'FURPS' (Functional, Usability, Reliability,
Performance and Supportability) requirements
(did I spell it right? :-), then interface
related requirements would be captured in the
'U' section of this artifact. These and
storyboards (plus UI prototype) should cover
what is needed in terms of UI. The thing is we
don't have storyboards as an artifact. Should we
consider a guideline for that?
Would business rules fit on the 'F' section of
the Supporting Requirements' artifact?
Cheers,
Ricardo Balduino
"Chris Sibbald" <Chris.Sibbald@xxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
04/04/2006 11:11 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
"Eclipse Process Framework Project Developers List" <epf-dev@xxxxxxxxxxx>
cc
External Chris Sibbald <csibbald@xxxxxxxx>
Subject
RE: [epf-dev] Overarching considerations (was:
Status from 3/30 BUPcall with authors)
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 dont 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 dont 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 dont 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 cant put in on Software Architecture Document
because stakeholders usually dont 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
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at <http://www.telelogic.com/>www.telelogic.com
Chris Sibbald
Vice President, Standards and Technology
Telelogic North America Inc.
255 Albert Street, Suite 600
Ottawa
Ontario K1P 6A9
Canada
Phone: +1 (613) 266 5061
Fax: +1 (613) 482 4538
Mobile phone: +1 (613) 266 5061
<mailto:Chris.Sibbald@xxxxxxxxxxxxx>Chris.Sibbald@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------
The information contained in this e-mail,
including any attachment or enclosure, is
intended only for the person or entity to which
it is addressed and may contain confidential
material. Any unauthorized use, review,
retransmissions, dissemination, copying or other
use of this information by persons or entities
other than the intended recipient is prohibited.
_______________________________________________
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev