[155] in Project_DB
3 July 1997 Project Database meeting
daemon@ATHENA.MIT.EDU (Bill Cattey On the Road)
Thu Jul 3 13:54:55 1997
Date: Thu, 03 Jul 97 12:05:50 EDT
From: wdc@MIT.EDU (Bill Cattey On the Road)
To: project-db@MIT.EDU
Attendance:
tjm, brendakg, wdc, brlewis, miki, mbarker
Next Meeting:
Thu 17 July 10:30-12:00 E40-316
Agenda:
1. Action Item Review
- Achievement/Goal entry
- Quarterly report generaton
- Has Bob Ferrara been in he loop?
2. How do we publicize/use?
- team leaders
- directors use
3. Converting to BRL
4. Setting stage for V2.
----
Action Items:
Miki will send, to project-db list, instructions on using Quarterly
report interface.
Miki will extract a list of team leaders from project db and email it to
mbarker.
mbarker will edit miki's instructions and email them to the team leaders
Tim will put, on the Discovery pages, a link that is a query to the DB
for the Discovery Quarterly status.
Miki will tell Tim how to do it.
Everyone: People should try Bruce's brl-based interface on OPS-5 and
should think about whether it should be rolled out now or later (with
version 2).
Bruce will send a separate note about the brl test page to the pdb list.
----
Information:
Bruce has completed the re-implementation of the Project DB interface in
brl and has it on OPS-5 for testing.:
https://ops-5.mit.edu/fcgi-bin/brl-fcgi/brlpdb/index.html
----
Setting the stage for version 2:
Three areas remaining incomplete:
1. Remaining confusion on the part of directors on using/applying the
system.
2. Providing utility for those actually leading projects.
3. Closing the loop with the project requirements document.
----
Requirements Doc issues:
Classes of problems with the existing Requirements Doc:
Groups of people were mentioned as customers, but not consulted for
requirements.
There were many requirements for which no attempt was made to implement.
It seems that the requirements document was not intended to measure what
level of accomplishment was made.
It would have been much better if the requirements written down better
fit the utility of the system.
For example, NONE of the requirments in the User Expectations section
were actually met.
Many requirements were anonymous, so there was nobody to talk to for
push-back or negotiation of any sort.
--
Differences between what we did and what we should have done:
Requirements should be organized by the stakeholder of the particular
requirement. In this way requirements are organized, and NOT anonymous.
Requirements that come from individuals within a group of stakeholders
should be retained so they are not lost, and flagged so that the context
of the issue is preserved.
Requirements should be testable. One way to make this happen is to
identify the stakeholders, and name the stakeholder's use scenarios.
----
Brainstorming on Possible scope and schedule for V2 effort:
We believe that Version 2 will require changing the Schema.
It would be nice if Version 2 efforts followed a real project workflow
including documentation, training, etc.
Various gut-level opinions of what the appropriate timeframe should be.
