head	1.1;
access;
symbols;
locks; strict;
comment	@% @;


1.1
date	92.10.17.20.34.18;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.1
log
@Initial revision
@
text
@\documentstyle[titlepage,psfig,fullpage]{article}

%%
%% Definition of commands that we will use in the document
%%

% screen names
\newcommand{\tiscreen}{{\em task information screen}}
\newcommand{\pscreen}{{\em project screen}}
\newcommand{\pcscreen}{{\em PERT chart screen}}
\newcommand{\gcscreen}{{\em Gantt chart screen}}
\newcommand{\poscreen}{{\em export options screen}}
\newcommand{\flsscreen}{{\em file load-store screen}}

% the name of our tool
\newcommand{\xplan}{{\em xplan}}

%%
%% Document title and authors
%%
\title{Preliminary Design Document\\[.25in]Project Planning Tool}

\author{Project Coordinator: Brian Gaubert \\
	Documentation Manager: Mark M. Lacey \\
	Configuration Manager: Richard Malingkas \\
	Project Manager: Mike Marlow
}

\begin{document}

\maketitle

\pagenumbering{roman} % number table of contents and list of figures
		      % with roman numerals

\tableofcontents      % make a table of contents for the document
\newpage              % begin a new page

\listoffigures        % list of figures used in the document
\newpage              % begin a new page

\pagenumbering{arabic} % start numbering pages with arabic numerals

\date{Due October 16, 1992}

\maketitle
%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR SCOPE
%
% Much of the information from the system specification described in the
% requirements document and other software definition documents will
% be used here.  Specific references to supporting documents are made
% in the next major section
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Scope}

This document serves as the preliminary design of our project planning
tool, \xplan. The purpose of \xplan\/ is to facilitate the planning of
projects by providing storage and retrieval of information related to
tasks that are a part of the project being planned.  Project
information can be stored to a file, thereby saving it for later
retrieval.  The tool will allow one project file to be loaded and
manipulated at a given time.  Project planning is further facilitated
by the automatic generation of both PERT and Gantt charts based on the
task dependency information in the task database.  The charts can be
viewed via the graphical user interface (GUI) of \xplan, or can be
exported to a text file in \LaTeX\ {\tt picture} environment format.
Direct generation of \LaTeX\ representations of the task information
(in the form of a task sheet), along with both PERT and Gantt charts,
provides the user with an easy mechanism for incorporating the output
of the tool into project planning documents.

The tool will include a GUI built using the Sun OpenWindows
Developer's Guide.  This restricts the platforms that the tool will
run on to Unix\footnote{Unix is a trademark of AT\&T Bell Labs.}
machines running the X Windows system and having the XView libraries.
Since X Windows and the XView libraries are both distributed
freely\footnote{A nominal distribution fee is charged if the libraries
are distributed on tape.}, and free implementations of Unix exist
(386BSD, linux) which are powerful enough to run X Windows, the
restrictions are minimal.

At the heart of the graphical user interface is the \pscreen\/ (see
Figure~\ref{project-screen} on page~\pageref{project-screen}) which
contains a scrollable list of tasks, along with pull-down menus that
perform functions such as file loading and saving, PERT and Gantt
chart display, date calculations, and \LaTeX\ file generation.  By
double-clicking on a task in the task list, the user will be able to
bring up the \tiscreen\/ for that task.  The user can then modify
information about the task, and save the changes into the task
database.  These two screens are used throughout the process of
building a task list, which can then later be displayed graphically as
a PERT or Gantt chart.

\begin{figure}
\centering
\centerline{\psfig{figure=project-screen.ps,height=3in}}
\caption[Project Screen]{\label{project-screen} The \pscreen\/
with example task list.}
\end{figure}

The \tiscreen\/ (see Figure~\ref{task-info-screen} on
page~\pageref{task-info-screen}) is the means by which the user enters
and views specific information about each task that is a part of the
project they are planning.  That information includes task name; task
description; task duration; planned, actual, forecast, earliest, and
latest start and end dates; float time; resource list; sub-task list;
dependency list; and flags which indicate if completion of this task
is a milestone, and if completion of this task yields a deliverable.
Some items, like the earliest and latest start and end dates, cannot
be modified by the user, but are rather filled in by selecting the
{\em Date Calculation}\/ item in the {\em Analyze}\/ menu of the
\pscreen.  The resource, sub-task, and dependency lists are accessed
by selecting the appropriate button on the \tiscreen.  Once the user
is satisfied with the information entered for the task, he/she can
select the {\em Apply}\/ button to save the information for the given
task into the task database.  If at any point before selecting {\em
Apply}\/ the user decides he/she would like to revert to what was
previously stored in the database, the {\em Reset}\/ option can be
chosen.

\begin{figure}
\centering
\centerline{\psfig{figure=task-info-screen.ps,height=4in}}
\caption[Task Information Screen]{\label{task-info-screen} The
\tiscreen\/ with detailed task information.}
\end{figure}

The \pcscreen\/ is for the graphical display of PERT charts which
correspond to the task list created by the user.  The chart is
generated automatically based upon the tasks and their dependency
lists.  Each box on the chart will be the same size, and will contain
the task name, planned start date and end date for the task, task
number, and task duration.  Task dependency will be indicated by
placing the tasks that have to be completed first on the left end of
the chart and drawing lines to those tasks that can be started once
the task is complete.  If the task is part of the critical path, then
the line from that task to the next task on the critical path will be
drawn thicker than other lines, to give a good graphical
representation of its importance.  By double-clicking on a task box,
the user will cause the \tiscreen\/ to be displayed with the details
of that task.

The \gcscreen\/ is for the graphical display of Gantt charts, which
like the PERT charts will be generated based on the information in the
task list created by the user.  The user will have the ability to
select a task from the Gantt chart which will cause the \tiscreen\/ to
be displayed with information on that task.

In addition to those main screens, a \flsscreen\/ along with an
\poscreen\/ are provided so that the user can control the destination
of the project file when saved, and the destination of the \LaTeX\
output that the program produces.

The \flsscreen\/ includes a field with the path to the current
directory displayed in it, along with a list of files in the current
directory, and a field in which the user can enter a directory that
they would like to move to or the name of a file they would like to
load.

The \poscreen\/ contains fields for the user to enter directory and
file names for the generated \LaTeX\ code to be stored in.  Direct
printing of the \LaTeX\ files from within the application will not be
provided since the main purpose of using a \LaTeX\ format for the
output is to allow a user to incorporate generated task sheets, along
with PERT and Gantt charts, into his/her own document for later
printing.  If the user chooses to print the generated files directly
rather than incorporating them into another document, the normal {\tt
latex}, {\tt dvips}, and {\tt lpr} commands can be used from a command
shell.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR INTERFACES
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Hardware, Software, and Human Interfaces}

Our project planning tool requires the use of a 3-button mouse and a
graphical display.  The display can be either black-and-white, or
color.  No explicit software interface is present (i.e.\ no other
programs are executed by the tool), but some form of the X Windows
system is assumed to be present on the machine that the tool is
executing on.  The tool is interactive, and a user is required at all
stages of using the tool.  All actions taken by the software are
based upon the user's actions.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR EXTERNALLY DEFINED DATABASE
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Externally Defined Database}

The project planning tool has no permanent externally defined database
that is needed for its operation.  It operates only on its own project
files, which are in a very specific project file format.  This is
discussed in detail in section \ref{sec:file} of this document.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR MAJOR DESIGN CONSTRAINTS AND LIMITATIONS
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Major Design Constraints and Limitations}

One major limitation of our tool is that only one project database can
be open at a time.  This limitation is not a major drawback since
under a windowing environment such as the one \xplan\/ runs on,
multiple versions of the tool could be loaded and running at a given
time.  

Due to the fact that there are inherent limitations on the
size of a drawing space in X Windows, our software will have to
enforce a limit on the number of tasks that can be displayed on a
single PERT or Gantt chart.  The limitation will mean there can be at
most 300 tasks ``in a row'' horizontally on a PERT chart, and at most
200 tasks ``in a column'' vertically.  In other words, given the size
of the PERT boxes, and the maximum size for a drawing space, we will
be limited in the number of boxes we can place in each direction.
Similar limitations exist for Gantt charts, with at most 1,800 tasks
listed on the chart, and a time-line limited to at most 5 years worth
of data.  Note, however, that these limitations are only for visual
interactive display, and play no bearing on the number of tasks that
can be stored in the system, or the number that can be produced on
hard-copy output.  Also, since each task can have sub-tasks, and each
list of sub-tasks for a task will be represented by its own PERT
chart, the limitations regarding the PERT charts apply not to the
total number of tasks, but to the number of tasks in any given list
(the list of main tasks, a list of subtasks, etc.).

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR REFERENCE DOCUMENTS
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Reference Documents}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR EXISTING SOFTWARE DOCUMENTATION
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Existing Software Documentation}

For more information on the project planning tool that we are
presenting, refer to \cite{prj-desc}, \cite{prj-plan}, and
\cite{req-spec} in Appendix \ref{sec-ref}.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR SYSTEM DOCUMENTATION
%%---------------------------------------------------------------------------
%%===========================================================================
%%\subsection{System Documentation}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR VENDOR DOCUMENTS
%%---------------------------------------------------------------------------
%%===========================================================================
%%\subsection{Vendor Documents}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR TECHNICAL REFERENCES
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Technical References}

For more information on PERT and Gantt charts, and critical path
analysis in particular, see \cite{cpa}.  The definitive reference for
\LaTeX\ is \cite{latex-manual}.  A good source for general information
on XView along with details of implementing XView programs is
\cite{xview-manual}.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR DESIGN DESCRIPTION
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Design Description}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR DATA DESCRIPTION
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Data Description}

The data managed by \xplan\/ is primarily made up of task information
for a project.  A list of tasks is maintained, and each task in turn
can have a list of sub-tasks that make up the task.  The information
stored for each task includes: task name; task description; task
duration; planned, actual, forecast, earliest, and latest start and
end dates; float time; resource list; sub-task list; dependency list;
and flags which indicate if completion of this task is a milestone,
and if completion of this task yields a deliverable.

%%%---------------------------------------------------------------------------
%%% SUBSUBSECTION FOR REVIEW OF DATA FLOW
%%%
%%% The following subsection describe the data flow and
%%% structure from refined DFD and decomposition of tasks
%%%---------------------------------------------------------------------------
\subsubsection{Review of Data Flow}

Referring to Figures \ref{l0dfd} and \ref{l1dfd}, it can be seen that
the database subsystem is at the heart of the project planning tool.
All information that is stored or retrieved goes through the database
subsystem.  Data flows from the user and from files into the database.
From the database comes structured task information that can be used
in displaying PERT and Gantt charts on the screen, or dumping them out
to a \LaTeX\ file.

\begin{figure}
\centering
\centerline{\psfig{figure=l0dfd.ps,height=3in}}
\caption[Level 0 Data Flow Diagram]{Level 0 data flow diagram of system}
\label{l0dfd}
\end{figure}

\begin{figure}
\centering
\centerline{\psfig{figure=l1dfd.ps,height=5in}}
\caption[Level 1 Data Flow Diagram]{Level 1 data flow diagram of system}
\label{l1dfd}
\end{figure}

%%%---------------------------------------------------------------------------
%%% SUBSUBSECTION FOR REVIEW OF DATA STRUCTURE
%%%---------------------------------------------------------------------------
\subsubsection{Review of Data Structure}
\label{dsreview}

The main data structure that the tool uses is a task list.  The task
list is a linear structure of linked task nodes.  Each task node has
the corresponding information for a single task.  Included in that
information is a dependency list.  The dependency list is a list of
tasks that the current task depends on.  Looking at it from another
perspective, the task list could be seen as an adjacency list, with
each task node having a list of tasks off of it that it depends on.
Adjacency lists are often used in place of matrices for storing graph
information, since they can store information for a sparse graph in a
much more compact fashion.

The tasks in the task list are in the order that the user places them.
The user will have the ability to add tasks at the beginning and end
of the list, along with inserting a new task at any point within the
list.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR DERIVED PROGRAM STRUCTURE
%%
%% Given the tasks and subtasks identified in Requirements
%% document, identify program structure (modules).
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Derived Program Structure}

The program structure will ultimately start out with the files
generated by the Sun OpenWindows Developer's Guide user interface
tool, along with those files generated by {\em flex\footnote{The
program {\tt flex} is a derivative of {\tt lex}, and is used to
generate lexical analyzers.}}\/ and {\em bison\footnote{The program
{\tt bison} is a derivative of {\tt yacc}, and is used to generate
parsers.}}.  Most of the user interface code will be contained within
the files generated by Guide.  Various Xlib functions will be needed
to implement graphical display of PERT and Gantt charts.

The heart of the project planning tool, the database subsystem, is the
next module.  This module is a logical entity of its own with the
expressed purpose of managing the database.  All database access will
have to be done through the use of calls to the database module.
Functions will be created to add, retrieve, delete, modify, and search
for information within the database.

The calculations module will consist of a set of functions used in
finding the critical path, calculating the earliest and latest start
and end dates for a task, and checking dependency information for
dependency loops.  The calculations module will also need functions
that calculate the placement of information on the PERT and Gantt
charts generated by the system.

The file read/write module consists of a set of functions related to
storing information from the internal database to a file, or
retrieving information from a file and storing it into the internal
database.

The \LaTeX\ generation module will use the information generated by
the calculations module to generate \LaTeX\ commands corresponding to
the type of output the user asked for (task sheet, PERT chart, or
Gantt chart).  The \LaTeX\ module itself, however, is responsible for
breaking the output into separate pages.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR INTERFACES WITHIN STRUCTURE
%%
%% How do the modules fit together?
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Interfaces Within Structure}

This section will explain the integration and how each major module
will be integrated with one another. First the user interface will
only have write access to the database using the store functions of
the database. The user interface will be able to receive information
from the database and the calculations modules only. The information
received from the database consist of the task information from the
database to the screen, depending on what screen the user is on. The
information received from the calculations will consist of a formatted
structure that will contain information for the viewing of the Gantt
and PERT charts. The file read/write will only access information from
the database and will put information to the file. The calculations
section will receive data from the database to do its calculations and
output data to either the database (calculation of begin, end dates),
the user interface (formatted data for the PERT and Gantt charts for
the screen), or the \LaTeX\ generator (formatted data for the
generation of a \LaTeX\ file that will produce PERT and Gantt charts).
Lastly, the database will be accessed when the user types some
information on the screen (Information is stored to the database), the
database is updating the screen, the database is called by the
calculations, the calculations update the database, the read file is
called by the read function which is called by the database function
to read the information from the file, and the database calls the
write function to write the information stored within the database to
the file.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR MODULES
%
% For each of module (functions or procedures) identified above,
% provide the following information 
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Modules}

\input{guiss.tex}

\input{filess.tex}

\input{calcss.tex}

\input{latexss.tex}

\input{dbss.tex}

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR FILE STRUCTURE AND GLOBAL DATA
%
% Explain how file structures are to be maintained, assign global
% data, establish cross reference between individual modules to
% files or global data.
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{File Structure and Global Data}
\label{sec:file}

There are two types of files that can be created by \xplan.  The first
is the project file, which can also be retrieved by \xplan\/ from
disk.  This file contains project information --- specifically a task
list. The second type of file that can be created by \xplan\/ is a
\LaTeX\ file corresponding to project planning documentation.

The only global data used within \xplan\/ is the task list, which will
be used by all of the program modules.  The list itself will be
primarily managed by the database module, although items within the
list can be accessed by other modules of the system.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR EXTERNAL FILE STRUCTURE
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{External File Structure}

The two external file formats created and used by \xplan\/ include
project files, and generated \LaTeX\ files.  The project files can be
written and read, and can come from a source other than \xplan\/ as
long as they follow the syntax and lexical conventions of the \xplan\/
project file format.

The generated \LaTeX\ files cannot be read back into \xplan\/ and are
intended to be incorporated into project planning documents written by
the user of \xplan.

%%%---------------------------------------------------------------------------
%%% SUBSUBSECTION FOR LOGICAL STRUCTURE
%%%---------------------------------------------------------------------------
\subsubsection{Logical Structure}

The structure of the files generated using the \LaTeX\ generator will
be in the form of a complete \LaTeX\ document using the \verb+article+
style.  In the case of PERT and Gantt charts, the majority of the
generated \LaTeX\ file will be a \verb+picture+ environment with
\verb+\put+ commands to place objects onto the page.  In the case of
the task sheet, the generated \LaTeX\ file will consist of a
\verb+tabular+ environment, with the task information in it.

The project files are made up of a list of tasks.  Subtasks of a task
will be in the same format as task.  There is no particular ordering
that the task information must be in.  For more information on what a
single task entry in the file looks like, refer to section
\ref{sec:record}.  The Free Software Foundation utilities {\em flex}\/
and {\em bison}\/ will be used in the creation of the file reader.
Refer to \cite{lexyacc} for more information on how {\em flex} and
{\em bison} work.

%%%---------------------------------------------------------------------------
%%% SUBSUBSECTION FOR LOGICAL RECORD DESCRIPTION
%%%---------------------------------------------------------------------------
\subsubsection{Logical Record Description}
\label{sec:record}

Generated \LaTeX\ files will begin with a
\verb+\documentstyle{article}+ command followed by a
\verb+\begin{document}+, and ending with an \verb+\end{document}+.
Between the \verb+\begin{document}+ and \verb+\end{document}+ will go
the body of the generated file.  Depending on the type of document
generated (PERT chart, Gantt chart, task sheet), the body will either
consist of a \verb+picture+ environment with \verb+\put+ commands to
place objects, or a \verb+tabular+ environment with task information.
In essence, there is no basic ``record'' for the generated \LaTeX\
files.

On the other hand project files created with \xplan\/ have a very
well-defined structure (see Appendix~\ref{grammar-appendix}), with
each record looking similar to Figure~\ref{file-rec}.  The task name
and description are in the form of a string, the dates are stored in
Julian format as integers, the duration and float are stored in terms
of days, milestone and deliverable are stored as boolean variables,
and the dependency, sub-task and resource lists are stored as lists of
strings.

\begin{figure}
\centering
\begin{verbatim}
task = {
        name = "Refine statement of scope for software",
        description = "Refine the statement of scope presented in the
project plan so that it is concise and includes only those items that
we will commit to implementing.",
        planned_start = 40923,
        actual_start = 40923,
        planned_end = 40925,
        planned_end = 40925,
        duration = 3,
        float = 2,
        milestone = true,
        deliverable = false,
        dependencies = "Review project plan"
}
\end{verbatim}
\caption[Sample File Record]{A sample of what a file record will look like.}
\label{file-rec}
\end{figure}

%%%---------------------------------------------------------------------------
%%% SUBSUBSECTION FOR ACCESS METHOD
%%%---------------------------------------------------------------------------
\subsubsection{Access Method}

The \LaTeX\ files will be generated by using the basic file writing
functions provided by the system library.

Project files, on the other hand, will use code produced by {\em flex}
and {\em bison} to recognize the breakdown of task information within
the project file.  Each action associated with a production in the
project file grammar will either store data within a task structure,
or store a task structure within the task database.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR GLOBAL DATA
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Global Data}

The global data used in the program consists of the task list, and
those global items generated by {\em flex} and {\em bison}.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR FILE AND DATA CROSS REFERENCE
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{File and Data Cross Reference}

The data within the program file will come from the data that is made
by the program from the database and the file write routines. The user
must type in the data through the interface or by hand. If the file is
typed out by hand or another method other than the program then the
file must be formatted to the specifications in order for the program
to read it correctly.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR REQUIREMENTS CROSS REFERENCE
%
% Refer to figure 10.25 in the textbook  for example of
% requirements cross reference. In general, provide a table to
% associate paragraph description within requirements document to
% specific modules. This technique will help ensure that all necessary
% requirements are satisfied and identify which modules are critical
% to the implementation of the specific requirements.
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Requirements Cross Reference}

Refer to Figure~\ref{cross-ref} for a table of sections in the
requirements document and the associated subsystem which they refer
to.  It is intended to be used as a cross-referencing mechanism to
verify that all project requirements have been met.

\begin{figure}
\centering
\begin{tabular}{||c|c||} \hline
Subsystem & Sections of Requirements Document \\ \hline
Graphical User Interface Subsystem & 1.2, 3.3, 4.2, 4.7, 5, 6.2  \\
File Subsystem & 3.3, 4.3 \\
Calculation Subsystem  & 3.3, 4.4, 5, 6.2 \\
\LaTeX\ Generation Subsystem & 1.2, 1.3, 3.3, 4.5, 5, 6.2 \\
Database Subsystem & 1.3, 3.1, 3.2, 3.3, 4.6, 6.2 \\ \hline
\end{tabular}
\caption[Cross Reference of Subsystem and Requirements Document]{A
cross reference of the major subsystems and where they appear in the
requirements document.}
\label{cross-ref}
\end{figure}

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR TEST PROVISIONS
%
% The following section is the first stage of the testing procedure.
% Give guidelines for testing individual modules and describe how to
% integrate the entire package. Make note of any special circumstances
% that must be addressed either in the testing or the integration phases.
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Test Provisions}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR TEST GUIDELINES
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Test Guidelines}

Unit tests must be done on each of the modules. The objective is to
simplify the error domain to one module. Two test cases will be
associated with each module:

\begin{itemize}
	\item Black box testing \\
Each module is tested based on operations of the functions within that
module, whether the input data are correctly processed and output are
correctly produced. This also involves checking the integrity of
external information such as data files.

	\item White box testing \\ 
This will use the control structure of the procedural design to derive
all test cases. All independent paths within a given module must be
executed at least once (i.e.\ all logical decisions are tested on both {\em
true} and {\em false} path and  all loop constructs must be checked for
boundary conditions).

\end{itemize}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR INTEGRATION STRATEGY
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Integration Strategy}

Testing will begin at the module level, and move upward toward the
integration testing for the whole program. All modules within a
subsystem should be tested together as well before the final
integration. This bottom-up approach will eliminate the need for
creating stubs. Since the program control is mainly event-driven,
top-down integration will also be used for some of the subsystems.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR SPECIAL CONSIDERATIONS
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Special Considerations}

If time permits, we may want to release a beta version before the
final testing phase. Since the other subsystems rely heavily on
database subsystem and GUI subsystem, both of these subsystems should
be tested early in the testing phase.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR PACKAGING
%
% Design constraints (e.g., physical memory limitations or special
% interfaces) may affect the requirements for packaging the software.
% This section will also be used to describe the transfer of the final
% package to the customer site.
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Packaging}

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR SPECIAL PROGRAM OVERLAY PROVISIONS
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Special Program Overlay Provisions}

A Unix computing environment such as a Sun SPARCstation 1 or
SPARCstation 2 is necessary for running our software.  In addition, X
Windows must be present in some form on the system for the software to
execute.  For compilation, an ANSI C compiler, the X Windows
libraries, and the Xview libraries are necessary. Also, since our
software will be distributed throughout the Internet in compressed tar
file format, the user will need the capability for anonymous ftp, and
the Unix utilities necessary to uncompress and extract a tar file. For
our primary customers at Michigan State University, Dr.\ Cheng
and Jerry Gannod, we will also provide printed copies of the 
\xplan\/ user manual and other written documentation which describes the
operation and use of the software.  Since that documentation will be
written using the \LaTeX\ document processing system, the \LaTeX\
files will be available for Dr.\ Cheng and Jerry too.  Any other
formats specified by Dr.\ Cheng or Jerry will also be provided for
delivery of the tool as requested.  

Our secondary customers, the Internet community at large, will need
the ability to anonymous ftp to the public access Internet addresses
at Michigan State University.  They will be provided with the program
as-is, with no implied or expressed warranty.  Documentation will be
provided in the form of \LaTeX\ files.

%%===========================================================================
%%---------------------------------------------------------------------------
%% SUBSECTION FOR TRANSFER CONSIDERATIONS
%%---------------------------------------------------------------------------
%%===========================================================================
\subsection{Transfer Considerations}

The tool will be packaged in a compressed tar file format containing
all source code, manual pages, and online documentation.  The software
will be transferred in the manner specified by our primary customers
(identified above) --- most likely this will be via copying the
compressed tar file, using ftp to transfer the file, or moving the
file to a diskette and delivering the diskette.

For our secondary customers, we will place the software on an
anonymous ftp site at Michigan State University.  Due to the fact that
{\em flex}\/ and {\em bison}\/ will be used in the implementation of
the system, the software will be released under the Free Software
Foundation's (FSF) copy-left policy\footnote{This document is
available with all Free Software Foundation distributions}.

Thousands of potential users are available, because of the popularity
and usage of X Windows application software in Unix computing
environments.  However, no service, support, upgrades, or printed
documentation will be provided by the authors for the general Internet
community.  The tool is distributed as ``free software'', so people
may use it and modify it freely.

A notice explaining that the tool is distributed in the spirit of the
FSF's copy-left policy will be included in the compressed tar file
that is available for Internet users.  The notice will identify the
authors as Michigan State University Engineering College students, and
will state that the product is provided free of charge to the Internet
community.  Final details of this notice will be specified once the
software is fully implemented, tested, and delivered to Dr.\ Cheng and
Jerry as a finished product.  The Internet community uses the Project
Planning Tool software at their own risk, and the authors assume no
liability regarding the use or performance of the product.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR SPECIAL NOTES
%
% This section allows the developer to include any supplementary
% information. Long documents should be included in the next section.
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
%\section{Special Notes}

%###########################################################################
% Algorithm descriptions, alternative
% procedures, tabular data, excerpts from other documents.
%###########################################################################
\appendix

\newpage               % start a new page for bibliography, etc.

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR REFERENCES
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{References}
\label{sec-ref}

\bibliographystyle{plain}
\bibliography{prelimin}

%***************************************************************************
%===========================================================================
%---------------------------------------------------------------------------
% SECTION FOR PROJECT FILE GRAMMAR
%---------------------------------------------------------------------------
%===========================================================================
%***************************************************************************
\section{Project File Grammar}
\label{grammar-appendix}

The all-caps entries in the grammar are tokens, and are not detailed
here.

\begin{verbatim}
project 
        : tasklist
        |
        ;

tasklist 
        : atask tasklist
        | atask
        ;

atask 
        : TASK '=' '{' alist '}'
        ;

alist 
        : assignment , alist
        | assignment
        ;

assignment
        : strassign
        | strlistassign
        | numberassign
        | booleanassign
        ;

stringassign 
        : NAME '=' STRING
        | DESCRIPTION '=' STRING
        ;

stringlistassign 
        : DEPENDENCIES '=' stringlist
        | SUBTASKS '=' stringlist
        | RESOURCES '=' stringlist
        ;

stringlist 
        : STRING ',' stringlist
        | STRING
        ;

numberassign 
        : DURATION '=' INT
        | FLOAT '=' INT
        | PLANNEDSTART '=' INT
        | ACTUALSTART '=' INT
        | FORECASTSTART '=' INT
        | EARLIESTSTART '=' INT
        | LATESTSTART '=' INT
        | PLANNEDEND '=' INT
        | ACTUALEND '=' INT
        | FORECASTEND '=' INT
        | EARLIESTEND '=' INT
        | LATESTEND '=' INT        
        ;

booleanassign 
        : MILESTONE '=' BOOL
        | DELIVERABLE '=' BOOL
        ;

\end{verbatim}

\end{document}

@
