The development of the composite_command classes must come first; once this is in place, the create-repository command will be implemented. Once repositories can be created, work on basic XML parsing will proceed, followed by implementation of the file and query immediate-mode commands. A text-mode submit command, presenting a series of prompts (text for PCDATA and CDATA elements/attributes, and numbered menus for enumerated attributes) should follow, pursued closely by the edit command.
With these core commands in place, YakTrack is at least marginally functional and usable, and in fact will begin tracking its own defects, use cases, requirements, etc. By getting the core functionality up and running early, the development team will get rapid hands-on experience with the tools, making them into customers of their own product. This should increase awareness of functionality gaps or defects in YakTrack, and create the tight the feedback loop that user-developers bring to development projects.
Once these are in place, the email gateway functionality can be added (which primarily addresses the file and query commands, although a request-form might be useful to request a "blank form" for a given issue type), while other immediate-mode commands are added (split-issue and merge-issues, for example). Each time a command is added to the immediate mode, it can be followed by additions to the email gateway and web gateway if desired. Email and web implementation of any given immediate command can be concurrent (email and web gateways are essentially independent).
It would probably work well to partition the development team along these lines, with one team working on core functionality, a smaller team keeping the email gateway aligned with the core effort, and a larger team working on the web gateway features. A feature team dedicated to immediate-mode GUI tools is also feasible, although users desiring GUI functionality will probably opt for the web gateway.
The immediate mode commands should be in place by end of April 2000, with simple email gateway functionality by mid-May. This will serve as a functional/evolutionary prototype for the system, and can be used as an initial release (although if major architectural problems seem to be buried in the existing prototype code, the existing code can be discarded and rewritten prior to public release).
Since part of this project involves a distributed development team, I would like to see customer representatives from each of the user classes involved in interface development and prototyping; customer input from all areas is necessary in order to create a product which satisfies the majority of our proposed customer base.
Unit tests will use a Python-based test framework, probably PyUnit, for testing low-level functionality. A sample repository with some example reports will be included and used to test proper operation of the tools as a whole (including local additions to the basic application). Whether scripted by the shell or by a simple Python program, tests will be written to file a valid report, file an invalid report, query for different items, query for invalid items, etc. Each use case determined for the product will have a scripted test associated; each functional requirement will have a PyUnit test associated. Interactive tools such as the submit command could be tested by hand or by testing frameworks such as DejaGnu or SC-Test.
Scripted tests will primarily file "stock" issue reports and query against them, comparing results with known good output.
Prior to any build being marked as a stable release, it must pass all regression testing scripts and unit tests. To ensure requirements coverage, all functional requirements (maintained in the project's YakTrack repository) should have dedicated unit tests. In addition, I would like to see the team institute and maintain an inspection process under which a code base is frozen and inspected independently by volunteers, with a "virtual" logging meeting (via IRC or similar chat area) to list extant defects observed by the team. Customer participation, in the form of user inspection of requirements or interface critiques, would be very much appreciated. While the bazaar style of open-source development finds many obvious defects, I still believe there is much to be gained by a systematic inspection process in addition to the standard open-source practices.