Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top