@device(PostScript)
@make(Plan)
@planhead(versiondate="17 November 1986",
          plansection="Section A",
          copyrightdate="1985, 1986",
          title="Introduction to the Athena Technical Plan",
          footingtitle="Introduction",
          author="by J. H. Saltzer")

@Majorheading(Overview)

The hardware, software, and communication systems that support
Project Athena are composed partly using using off-the-shelf
subsystems from primary and third-party vendors, partly with locally
modified versions of off-the-shelf subsystems, and partly with new
components developed by Project Athena.

This technical plan captures in a loose-leaf notebook the overall
architecture of the support system for Project Athena.  It has
several purposes:
@itemize{
Communication within Project Athena.

Communication with M.I.T@. faculty developers.

Communication with interested people outside M.I.T.

Checking consistency of different subplans.

Providing traceability from tasks back to requirements.

Providing a mechanism for review and agreement among developers
and between developers and other project participants.
}

Section B of the Athena Technical Plan provides an overview of the
objectives of Project Athena and develops a high-level list of
requirements that the Athena system must meet.  Sections C and D
describe the envisioned Athena computation environment and the
evolution scenario by which Athena will reach that environment.
Sections E through G of the plan specify detailed plans for all those
areas that require development or extensive modification of available
subsystems.  Section H contains miscellaneous related plans, and
Section J contains a list of standards, specifications, and
references to other documentation.

Not included in the scope of the Athena Technical Plan are several
other related activities of Project Athena: deployment plans,
operation plans, user service plans, administration plans, funding
plans, and faculty development plans.

@majorheading(The Planning Process)
This document is dynamic: it begins as nothing but a table of
contents of hoped-for documents, in a loose-leaf binder.  As time
progresses, the actual plans are laid, and the documents begin to
appear.  As necessary, the table of contents changes to reflect
better understanding of the components of the plan, and the plans
themselves may change in response to discovery of better ideas.
Periodic updates consisting of new or replaced plan sections thus
will fill out the loose-leaf binder. 

Each plan section is commissioned, and the result is a document with
an identified author or authors, whose name appears on the first page
of the plan section.  The table of contents contains one entry for
each section that currently appears to be needed for plan
completeness.  Those sections that have been commissioned or are
being circulated in draft form are listed in the table of contents as
"in progress".  A date next to a table of contents entry means that
that section has been distributed to holders of record of the
technical plan notebook.

It is a fundamental principle that implementation of a plan 
@i(follows) its writing.  Violations of this principle require both
an emergency and agreement of the technical director.


@majorheading(Contents of a Plan)

Every detailed plan should explain which of the requirements listed
in Section B it addresses.  The technical description of what is
planned should concentrate on the design rationale, so that a later
reader can understand not just what is planned, but why.
Implementation details and interface specifications should be cited
rather than included in the plan.  The resources and time required to
carry out the plan are an important component, and dependencies on
other plans and a summary of unsolved problems should be included
(later updates may provide an opportunity to replace unsolved
problems with solutions).  Finally, every plan for development of
software should discuss the long-term support strategy that Project
Athena should expect to follow.  For software, one of two support
strategies will normally appear: the software package is temporary,
and can be discarded, or the software package is permanent, and there
is hope that vendors will include it in future product offerings.