Meeting Minutes –
High Level Notes from Per
Kroll:
BUP Status (Brian) – Report
from the Component Team
Tools/Meta model status
(Charlie)
DSDM Contribution (Mark
Dickson)
Value Based Software
Engineering (Barry Boehm)
Telelogic Status (Chris
Sibbald)
BUP Break-out in the
Afternoon:
End to end Content
Improvement
Meeting Attendees:
|
Name |
Company |
|
Apurva
Jain |
USC |
|
Barry
Boehm |
USC |
|
Bernard
Clark |
Unified
Process Group |
|
Brian
Lyons |
Number
Six |
|
Bruce
MacIsaac |
IBM |
|
Charlie
Yan |
IBM |
|
Chris
Sibbald |
Telelogic |
|
DJ Villiers |
Ivar
Jacobson Intl |
|
Jesal |
USC |
|
Jim
Ruehlin |
IBM |
|
Jim
Thario |
IBM |
|
Kelvin
Low |
IBM |
|
Kirti
Vaidya (tentative) |
Covansys |
|
Kurt Sand |
Telelogic |
|
Mark
Dickson |
DSDM |
|
Naveena
Bereny |
IBM |
|
Per Kroll |
IBM |
|
Peter
Haumer |
IBM |
|
Ricardo
Balduino |
IBM |
|
Sigurd
Hopen |
2ProMentor |
|
Sunita
Chulani |
IBM
Research |

Ø Deployment content needs to be improved. We among others need to address promotion of different types of builds, user acceptance testing, understanding what it takes to the deploy the product, alpha and beta testing, and the actual deployment with cut-over plans, etc.
Ø Stakeholder is a new role. It is inclusive of Executive Sponsor, End Users, Buyer, and other people inside and outside the project.
o Stakeholder is a co-performer for among others the following tasks; Define Vision, Find and Outline Requirements, Detail Requirements, User Acceptance, and the Milestone reviews / decisions (iteration and phase).
Ø Collaboration.
o We need to look over “Additional Performers”
o Facilitated workshops, reviews, achieving consensus, etc
o Win-win negotiation
o Daily scrums
(NOTE: Sub-project to be referred to as Component because of technicalities in Eclipse Foundation).
Core principles: how to expose and espouse collaboration? Other principles (architecture, requirements, iterative) more clearly demonstrated.
Need further discussion on architecture of BUP itself, how to extend, dependencies.
Draft content development guidelines will be available next week. (Quality bars need to be defned, 2 levels intial and release).
Discussion of scope of BUP (project vs. program, development team vs. IPT) For example, we say “BUP is complete…”, but within which context/scope.
CM: what about baselines, review/accept/reject
Plug-ins that build off of BUP: MDD/MDA, VBSE, Agile modeling…”not just a bunch of un-related things”.
Need to add deployment discipline? Need to get early feedback from users/consumers of BUP? Need some tutorials.
Eclipse development community drive by 3 main artifacts: code, bugzilla, tutorial
Showed Eclipse Dashboard. Notes on statistics and dev process: only information from bugzilla and news group rolled up…important to use these facilities to get accurate statistics.
Version control beta in next build.(M2)…will test/release in M3 XML schema defined (need to review as it needs to be frozen April 15).
We will have a session on Bugzilla (voting).
Plans for M3 presented…need to review and vote. Will freeze V1.0 API at M3.
Currently off-line development (daily build) being done. At each milestone a build will be made available for download.
DSDM is a structure development process.
Key principles:
Iterative Dev, Time boxed delivery …Business-focused, collaborative development.
Strong in pre-Inception/pre-development stages/phases.
Covers more than SW development.

Day 1's EssUP breakout session
involved a more detailed review of the EssUP concepts: alphas and betas,
competencies, practices. There was agreement that these ideas seemed strong but
without a formal definition it will be very difficult to achieve a common
understanding and be able to map these concepts into the BUP space. Several
different conceptual definitions of alphas and betas were raised and it was not
clear how they relate to artifacts and templates.
Within EPF we would like to
distinguish between the information in a project, its representation and
templates, but we are not sure whether alphas and betas are similar or
orthogonal. The distinction between competencies, roles and skills was also not
clear. The idea of competencies seems good, but the current set of competencies
seems very similar to the BUP roles, and then the value of competencies is not
evident.
We all agree that practices
should be separated from the underlying process and from each other. Using the
current EPF tools, we are able to model practices separately using capability
patterns, but not yet the ability to separate practices from process. There was
agreement that the user experience concepts are strong: we would like to adopt
the ideas of electronic cards, guidelines and gameboards in EPF. However we are
unsure about the value of hardcopy cards in a real project, although it will be
useful for training purposes.
The exact scope of the EssUP
contribution has not yet been defined, but will
draw on the following items,
which we agreed could be valuable to EPF:
- practices as a "chunk" of process
- separating and composing practices and
separating practices from
processes
- alphas, betas, competencies but these need
to be better understood
- activity approaches
- cards, guidelines, gameboards
- list of EssUP process elements (artifacts,
tasks)
- process development guidelines
No Notes - Sorry!

No notes – sorry
Need to define what type of project is the ideal candidate for BUP OOTB.
Minimal BUP content for V1.0 (GAP analysis)
- Need to address fielding/acceptance, impacts PM, Dev, Test, Stakeholder (new, see below) roles.
- Stakeholder role
· Add role, add role as co-performer of RM and Test tasks as appropriate.
- Responsible and additional performer introduced in SPEM 2.0
- Guidelines for Collaboration Techniques
· Facilitate Workshop
· Real time status (add to Monitor and Control task)
- Achieve Concurrence has been added (with guideline for review).
- Add Guideline/Concept re: Collaboration to Plan Iteration task that discusses collaboration of Tester, Analyst, Dev, Stakeholder to Planning.
- Add Practice for each of the four overarching principles inc. Collaboration (note current practices need to be cleaned up).
Ø Create a dev outreach page on http://www.eclipse.org/epf/ and also make this type of info more visible on front page
Ø Use the epf logos on presentations, e-mail footer, corporate websites, etc.
Ø Make a reference list of press mentions…
Ø If you present, post a note about it on http://www.eclipse.org/epf/ and we should now and then post a note to the epf newsgroup about “upcoming events”
Ø Put all presentations on http://www.eclipse.org/epf/
Ø Make available presos for users looking to sell the adoption of EPF to their company
Ø Push blogs, and cross link to various communities, such as SPIN and Agile Alliance
Ø Leverage newsgroups and mailing lists, get involved in discussions. Always cross reference. Needs to be developer to developer discussion.
Ø Clarify how we fit with other projects
Ø SPIN Networks
o Contact Paul Clemmons
o International process consulting (TCS is sponsoring) – Barry Boehm
We reviewed the sample
EssUP material from the Use Case Driven Development practice, with the goal of
reaching an intuitive understanding of alphas, betas and competencies. The
review did improve our individual understanding, but did not help build a common
understanding or definitions of these concepts. We decided we would need to
schedule a confcall with Ivar Jacobson and Ian Spence from Ivar Jacobson
Consulting in order to discuss formal definitions in detail.
Next steps:
- discuss EssUp core process concepts in
detail, during week of 27 March
- compare BUP & EssUP process elements
(artifacts, tasks), during week
of 27 March
- compare process schemas, in early april
- define specific EssUp contribution, by early
April
- investigate Ivar Jacobson Consulting's legal
implications of the EssUP
contribution
-
discuss candidate
technical solutions for separating & composing
-
practices
Website re-design
Wiki
May 16-18, location TBD by vote
Telecon April 17
Infrastructure
working example – CV, Bugzilla (Ricardo)