kennett.fussell@gsa.gov
Posts 29
|
FACADatabase Task Force Meeting Agenda
1. Review Minutes and Contact Information.
The Task Force meeting began about 1:00 pm with the members identifying themselves on the phone and in the room. Only two members were unable to attend. Bernie Coston from the IRS added his phone information to the Membership List.
Ken Fussell asked if there were any corrections or additions to the minutes, and none were offered.
2. Review, discuss, and finalize proposed charter.
Feedback via Forum:
Ken acknowledged the task force members who had visibly utilized the online forum thus far, himself, Maggie Weber, Kathy Plowitz-Warden, Angel Saumure, David Clary and Bruce Troutman. Maggie had taken Ken’s “extended version of the task force charter” and thoroughly streamlined it. Both Angel and Kathy commented favorably on Maggie’s effort and Kathy added a few additional comments on grammar and construction. Everyone felt that the charter was pretty solid, so the group moved along to Ken’s concern that the charter required an ACR component and that a central purpose of the resulting system would be that the system support and facilitate the ACR.
ACR component:
The group clarified in discussion that its task might extend to recommending to the Director of Committee Management and the CMOs how a more flexible, less lock-step ACR be conducted. And, that, even if the group was not prepared, at the conclusion of its work, to recommend how the ACR be conducted government-wide, it remained part of the group’s charge to assure that the eventual system supported the ACR process. The ACR would have to be part of our thinking and considered for its needs and impact every step of the design and implementation process. The group moved on.
First task – Constituencies:
Ken pointed out that a component that should be included in our awareness from the very get-go was the user constituencies for the eventual system. We discussed the reality that the limited view of the constituency for the first cut of the first system imposed a constraint on the design that severely limited the eventual flexibility of the evolving system. Again, while we did not resolve what the total array of constituencies were, we did resolve to hold the issue in our awareness as we proceeded through these early months and to effectively identify an acceptable collection before we concluded the design process.
3. Review and demonstration of use of the Forum for communication and record-keeping.
Ken walked through the layout and some of the features of the Forum application.
• The RSS feature – the RSS feed works with current browsers to alert the user that a change has taken place in the application’s information. It works with IE7, which we could not demonstrate in the conference room because the computer had IE6 installed.
• Posting order – Kathy suggested that the posting order for discussion threads might be more useful if they were listed as most recent first, which reverses the order that is currently displayed. Georgia agreed. We decided to experiment with that approach.
- Requirements development
Ken explained how he envisioned the forum supporting the group in identifying the requirements. Rather than making notes about what features of the current system are useful, or what features could be discarded, or what features we should have in the new system, we could just post our ruminations to the forum. This would allow the discussions to start, develop, and perhaps even by resolved by the time we held the next meeting. We noted that David had been using the Forum for exactly that purpose during the previous week. Ken read and discussed a couple of David’s entries as examples of how the forum was going to be useful to us as a vehicle for capturing the requirements. The use of forum was for capturing the requirements was returned to many times throughout the meeting, with examples from Jim on document capture and archiving via committee website; Kathy regarding the consultation process; Maggie regarding coordination on the consultation process and regulatory development; Bruce on the use of the forum to identify the requirements and the problems, not the solutions to the problems; and Ken urging continuous use.
4. System Requirements
- Retain all the identified functionality of current system
Ken suggested that about 99% of the current system does what we want and we will be careful to avoid losing what the system currently does that we like. No objections to that opinion were voiced. The discussions used the examples already posted to elaborate on how the forum would help us. Susanne clarified how the forum permitted searching and gathering together the information and topics captured in the forum. There was some discussion dealing with the concern that the whole project was potentially so big and encompassing that it would overwhelm us unless we broke it up into manageable chunks. We discussed that and pretty much acknowledged that this was going to be a best effort based on what we already had achieved with the first version of the system and, like the first version, when we presented it to the world it would be as complete as we could make it, but there would be no reason to consider it finished and unchangeable.
- Add new requirements via Forum
As we look at the current system, when a feature we are using strikes us as important, we will note that in the forum, so that the rest of task force can interact with our observations. We will take the same approach when we notice the lack of a feature that we could use. Kathy observed that it was hard to build something without having defined what the something does or is supposed to accomplish. Ken observed that it might be more circular, we will be figuring out what we want by talking about what we want. Bruce pointed out that our development was iterative the first time around and it would be this time as well, only we will be starting with what we already have. We will put up a system and learn what else we want it to do by interacting with the system we put up, and we record our observations in the forum so we do not lose them.
Ken suggested that the process would embrace
• capturing and discussing the requirements in the forum to the extent possible and resolving some issues in meetings,
• moving the agreed upon requirements to a requirements/documentation database that would also be maintained and accessible to the task force, and
• Incorporating the requirements in the database into the continuously developing prototyped system.
The group as a whole asked for clarification on how new topics were posted to the forum and Ken demonstrated adding a new topic. We then discussed how much organization each of us has to bring to the development process. We also discussed the functionality and requirements of the RSS feed the forum has built into its design. The RSS feed can be set up to automatically alert us when new items are added to the forum. The RSS feed works automatically with the Microsoft IE 7 browser, but requires securing and installing plug ins for earlier MS browsers.
5. Demonstration of prototyping capability of new technology.
We took a look at a prototype that was built by from a revised table structure from the current system. Bruce inserted a link to the prototype into the forum. We were not suggesting that the prototype was what we wanted, but rather demonstrating how quickly something could be put together that included a lot of the functionality we were looking for. The demonstration led to further discussions of what we like in the current system and what we want in the future system. Ken and Bruce emphasized that the demo provided at this point was beyond plain vanilla; it was useless for display purposes for a specific user and was oriented to showing the new functionality we would acquire and how quickly we could produce a product.
6. Set a Time, Place, and proposed Agenda for next meeting.
We agreed that we would likely try for a meeting the week of 4/17/07.
|