Layered Athena Project Plan


1. Scope statement

Why - to make ports and building releases easier and to make Athena
available to more labs and departments, we need to define a clean and
seperable layering of Athena software on the vendor operating system.

What - we need a way of organizaing the source tree, building
releases, packaging the releases, doing updates and installs of
workstations to support layered Athena.

Success Factors - an example port such as Ultrix 4.3 that uses these
ideas with tools for installation and update.

2. Major milestones

As this project is going through the DCNS Orange Process, some of the
milestones are from that.  As we move on to development, testing, and
debugging, there are milestones as major pieces are completed.
Finally, there are the additional phases of the project.  The first
phase is to produce a sample Layered Athena release based on Ultrix
4.3 which shows that we can do this, without necessarily having all of
the flexibility we want in the long run.  Once that first phase is
done we will decide the specifics of the next phase.  That will
probably be the HP port and other platforms at the same functionality
as the first phase, although we may decide to immediately expand the
functionality instead.

    1. Requirements complete and approved
    2. Design complete and approved
    3. Subsets created for DECstation/Ultrix 4.3
    4. User interface client complete
    5. System complete and integrated
    6. System ready to release

2.1 Requirements.  The first milestone is to come up with a set of
requirements, have public discussion about them, and get them
approved.  These requirements should identify both basic requirements
for the first phase of this project, and long-term "wish list" type
requirements for later refinements.  As of 24 Feb 93, this is nearly
done, except for the public review.

2.2 Design.  The next milestone is to come up with a detailed design
for implementing Layered Athena.  For now the design should
concentrate on the first phase of the project, but consideration
should be made for more flexibility in the future.

2.3 Sample implementation.  The first phase will only address Ultrix
4.3 on the DECstation.  This implementation will include:
	1. building and packaging up all of the appropriate binaries
	   and other files
	2. A tool with a reasonable user interface for installing and
	   deinstalling various subsets of Layered Athena
	3. Tools for working with the central database of what has
	   been installed where
	4. A user's manual oriented towards the private workstation owner
	5. An administrator's manual oriented towards Athena support staff

3. Problems

3.1 Critical risks.  There are a number of risks in this project:
	1. Bounding the problem.  There has already been a lot of
misunderstanding among I/S staff as to just what this project is: what
problem are we trying to solve, how far are we going in that solution.
If we are going to reach any consensus on the requirements and design,
we have to agree on the problem first.  I have attempted to deal with
this by expounding on the problem in the introduction in the
requirements document.
	2. Timing conflicts in source tree with summer release.  Some
source changes are necessary to support subnetting.  If we do a summer
release, we may want to make some of these changes while the source
tree is frozen for that release.  I would suggest that if and when a
summer release is scheduled, we look at this and decide then to either
do the source tree work first, before freezing the release, or stretch
out the Layered Athena schedule.
	3. User interface rat-hole.  Ideally, we would like a nice
motif interface.  However, this can take forever to code.  The
approach I will take is to write a simple command-line interface with
full functionality, and then put a motif front-end on it for as much
as we have time for.

3.2 Reserves and contingencies

I did not build any slop time into the schedule below, although the
implementation time estimates are generous.

3.3 Pending issues/decisions

Are we doing Ultrix 4.3 for the summer release?  This affects the
difficulty of building this stuff and scheduling getting it done.

How many people will be working on the implementation?  Some of
Richard's or Craig's time would be useful.  There are also parts for
someone without release engineering experience.


4. Scheduling

4.1 Work Breakdown

Time estimates in weeks

Requirements				2.5
 write				*
 public review			1
 re-write			.5
 managment approval		1

Design					5
 write				1
 consult with key developers	1
 re-write			.5
 public review			1
 re-write			.5
 TRB approval			1

Implementation				11
 fix software for subsetting	2
  kerberos		.3
  zephyr		.1
  hesiod		.6
  AFS			.8
 create subsets			1
 write UI			3
 write central database		1
 integrate			2
 testing/debugging		2

Documentation				2
 Administrator's Manual		1
 User's Manual			1

Ready for beta test


4.2.  Tasks/Scheduling

If only one person works on this (i.e. me), beta test will be ready in
mid-summer.  A second person could take 4-5 weeks off of the
implementation time, having it ready at the beginning of the summer.
We could even have three developers work on different parts of the
implmentation (UI, subsetting, central DB) to shave a little more off
the elapsed time.  We could also use help on the manuals.  There is a
lot of slack time during the requirements and design phases, whereas
the implementation phase assumes most of a developer's time (less
overhead doing operations support and other necessary tasks).