Subject: Orange Process--Prototype 1.1 To: orange@MIT.EDU Cc: mbarker@MIT.EDU, owens@MIT.EDU Date: Thu, 20 Apr 1995 19:30:03 EDT From: Mike Barker [Note: This prototype may be a basis for "The Hephaestus User Document", a document detailing a scalable development process for supportable products. I think we should also start a similar prototype for the other document asap.] product: any acquired or internally developed code, documentation, procedure, etc., that is released for internal (development) or wider use, including both new work and changes or bug fixes to existing work. First prototype--rev. 1 1. The germ of an idea comes from somewhere. It may be a customer request, internal suggestion, or other source. As noted in the Requirements for a DCNS Development Process, only when a well defined Scope Statement has been provided will the Hephaestus process begin. Further, as stated in the Requirements document, staffing and other resources for a project will be determined without consultation with developers. Assignments will be made and followed without question. Thus, the "process before Hephaestus" provides DCNS-dev with a well defined Scope Statement, personnel assignments, and allocation of resources. Developers simply carry out the assignments provided by this other process. 2. A person "takes charge" of the idea. They start a notebook for this project containing at least the following sections: a. summary description b. project plan c. requirements--functions, performance, etc. d. architecture--overview, components, interactions, protocols e. detailed designs--per component, interfaces and functions f. development and testing notes g. release, bugs, revision notes h. review notes This notebook will be kept online, accessible by all supported platforms. To make them easy to locate, all notebooks will be logged in the DCNS-Dev homepage (http://web.mit.edu/afs/athena/astaff/project/dcnshtml/dev/home.html) in the projects section (http://web.mit.edu/afs/athena/astaff/project/dcnshtml/dev/projects.html) At any point in the project, the project developers may add to or modify material from any section. However, these modifications must be presented, fully explained, and justified to the "decision point" team. To help in maintaining the "project notebook", DCNS-dev developers will use RCS. In emergency cases, developers may take action (e.g., provide fixes or even complete programs) without completing the notebook or conducting a "decision point" review. HOWEVER, Hephaestus will pound you to little quivering bits if you don't document the actions taken and conduct a review as soon after the emergency has been handled. Where possible, online notes are highly recommended as ways to trace the actions taken. Note that during early stages of the process and for smaller projects, the following characterizations of these sections may not be completed. However, whenever appropriate, these sections should contain: b. project plan This section should contain at least a statement of the project goal, the steps expected, the estimated times of completion for each step, and the points in the process where "decision point" reviews will be conducted. c. requirements--functions, performance, etc. This section should contain at least a bullet list of mandatory functions. It may contain desirable attributes and descriptions of the users expectations. d. architecture--overview, components, interactions, protocols This section should contain at least a Yourdon "bubble chart" describing the architecture. e. detailed designs--per component, interfaces and functions This section should contain at least a list of the components with their interfaces and functions. f. development and testing notes This section should contain notes from the development and testing. Specific areas of interest include: a writeup of development bug fixes, copies of make logs, directions for testing and test results g. release, bugs, revision notes This section should contain notes from post-release work, including bugs, enhancements, modifications, and other work on this product. h. review notes This section will include minutes from each "decision point" review, including the list of those attending, purpose of the review, and results of the review. 3. there should be several "decision points" where the person "makes a case" for continuing the project. These probably include: a. after initial requirements discussion, early design, and initial layout of the project plan b. after most of design has been considered c. after initial coding and testing d. at release e. after program has been in use for a while To ensure that the product meets customer specifications, these decision points must include representatives of the customers who must approve further action on the project. To ensure that the product is adequately defined, maintainable, supportable, and well documented, the decision points must include representatives of DCNS-dev not otherwise involved in the project, representatives from support teams, plus at least one technically capable person from outside the DCNS organization. All of these people must agree that the product as represented by the notebook meets general standards in terms of definition, maintainability, supportability, and documentation before further action is taken. ------------------------------------------------------ Diane also pointed out: - What requirements are not satisfied by this prototye? scalability - It is not clear from the prototye how scalable it is. The prototype state a lower bound but does not state what the upper bound is on what is being kept in the notebook. I am not certain that the lowerbound of the prototype would scale to small investigation type projects. I guess I'm not clear on why any project would skip any sections. Clearly a description, plan, requirements and notes would be necessary even for an investigation, although the notions of architecture, detailed design, and development might not fit well. Of course, when I asked about this in the meeting, I was assured that architecture was necessary even for a one-line bug fix, so I'm a bit confused by the objection. If the sections don't apply, I would expect to simply fill them with a piece of paper saying "this section does not apply"--and if the reviewers object, I would have to provide reasons for skipping that part. As for upper bounds--since the idea of a project notebook with sections corresponding to critical parts of the project was taken from a navy standard mostly dealing with multiple year large projects, I think it scales up nicely. admittedly, in the longer and larger projects the "notebook" may have grown into several volumes with subdivisions, but we can add that refinement when we need it. Can you recommend a way to improve the prototype or another prototype that will scale more easily? Thank you for the comments. mike