Subject: Orange Process--Prototype 1.1
From: Mike Barker <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 20 Apr 1995 19:30:03 EDT

[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