Subject: Hephaestus Implementation Plan--Prototype 1.0
From: Mike Barker <mbarker@MIT.EDU>
To: orange@MIT.EDU
Cc: mbarker@MIT.EDU, owens@MIT.EDU
Date: Fri, 21 Apr 1995 18:57:25 EDT


The Hephaestus Implementation Plan--A plan for the implementation,
maintenance, and user support of the process, including a description
of the foundations required for its proper function and a list of
other processes that will need to be defined to round out support for
the entire product lifecycle.

So the major sections of this plan might be:

1.  Overview
2.  Implementation Steps

Perhaps...
	a.  Prototypes of Hephaestus User Plan (HUP) and Hephaestus
	    Implementation Plan (HIP) expanded to the point where orange
	    team agrees they are ready for review.
	b.  Prototypes of Hephaestus User Plan (HUP) and Hephaestus
	    Implementation Plan (HIP) reviewed by DCNS-dev.
	c.  Modifications and additions if needed.
	d.  Working versions of both documents reviewed and agreed to
	    by DCNS-dev and other management
	e.  Internal training on HUP methods where needed.
	f.  Trial use of HUP on at least three DCNS projects (which
	    also is trial use of HIP)
	g.  Review, modification, and additions to HUP and HIP where needed
	h.  Continue incremental application of HUP to DCNS projects

3.  Maintenance steps

	a.  During early use of HUP, a Post Mortem review of the
	    process (as opposed to the product and product documents)
	    involving all developers working on the project, and at
	    least:
		 one developer not working on the project 
		 one manager
		 one customer
	    will be held.

	b.  after at least a year of such reviews for each project,
	    DCNS-dev will determine whether or not to continue
	    holding such a post mortem of the process on each
	    project.

It seems clear that the Post Mortem Phase described in the
requirements document is part of the Maintenance steps.  Specifically,
"the sixth evaluates the effectiveness of Hephaestus as a development
process."

4.  User Support required for the Hephaestus process

	a.  all developers must willingly participate

5.  Foundation Requirements

	a.  the process must be capable of being added to and
	    expanded as experience with it is gained.
	b.  Standard Tools, Processes and Standards 

      Wherever practical, standard tools and processes should be defined and
      provided to be used in the process to help supply: 

         Interoperability 

         Efficient Resource Usage - for things done perhaps only once,
         but over and over counted across projects 

         Reproducibility - avoiding hand procedures that can be
         automated 

         Maintainability - using portability standards and tools as
         appropriate 

         Sanity Checking - ensuring the right things are done in the right
         ways, and appropriate input is gathered

6.  Other processes expected

	a.  a "management" process
	b.  a "systems analysis" process which will produce well-defined
	    statements of scope for each Hephaestus project
	c.  an "operations" process which will accept responsibility for
	    the products of Hephaestus projects
	d.  a "documentation" process which will produce user documentation
	    for Hephaestus projects
	e.  a "user support" process which will support the products of
	    the Hephaestus projects
	f.  an "end user" process which consumes Hephaestus products