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


1.6
date	92.12.14.03.32.23;	author lacey;	state Exp;
branches;
next	1.5;

1.5
date	92.12.14.03.11.51;	author lacey;	state Exp;
branches;
next	1.4;

1.4
date	92.12.14.01.19.07;	author lacey;	state Exp;
branches;
next	1.3;

1.3
date	92.12.14.00.25.47;	author lacey;	state Exp;
branches;
next	1.2;

1.2
date	92.12.14.00.03.09;	author lacey;	state Exp;
branches;
next	1.1;

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


desc
@@


1.6
log
@*** empty log message ***
@
text
@\documentstyle[titlepage,fullpage,psfig]{report}

\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}}
\newcommand{\xplan}{{\em xplan}}

\title{{\LARGE\bf Final Report for the \xplan\ Project Planning Tool}
\author{{\Large\it Brian Gaubert, Mark M. Lacey, Richard Malingkas, Michael Marlow} \\
{\Large Department of Computer Science} \\
{\Large Michigan State University} \\
\vspace*{2in} 
\mbox{} \\
{\Large Software Engineering, CPS470} \\
{\Large Instructor: Dr.\ B. Cheng} \\
{\Large Teaching Assistant: G.C. Gannod} \\
\vspace*{2in}
\mbox{} \\
{\Large Fall 1992}
\date{}
}}

\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
\clearpage            % begin a new page

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

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

\input{proj-desc}
\input{techniques}
\input{conclusions}

\appendix

\input{addendums}

\input{user-manual}
\input{errors}
\input{copying}

\chapter{Bibliography}

\label{sec-ref}

\bibliographystyle{plain}
\bibliography{final-report}

\end{document}


@


1.5
log
@*** empty log message ***
@
text
@d52 1
a52 1
\section{Bibliography}
@


1.4
log
@*** empty log message ***
@
text
@d15 1
a15 1
\vspace*{2.5in} 
d20 1
a20 1
\vspace*{2.5in}
d23 1
a23 1
\date{December 13, 1992}
a46 2

\def\thesection{\arabic{section}}
@


1.3
log
@*** empty log message ***
@
text
@d51 2
@


1.2
log
@*** empty log message ***
@
text
@d52 7
@


1.1
log
@Initial revision
@
text
@d1 12
a12 7
\documentstyle[11pt,fullpage]{report}
\begin{document}
\thispagestyle{empty}
\title{{\LARGE\bf Final Report for PERT/Gantt Chart Generator Project by
 Group 7}}
\author{{\Large\it Brian Gaubert, Mark M. Lacey, Richard Malingka, 
Michael Marlow} \\
d18 1
a18 1
{\Large Instructor: Dr. B. Cheng} \\
d23 4
a26 2
\date{}
}
a27 12
\setcounter{page}{3}
\pagenumbering{roman}
\clearpage
\tableofcontents
\clearpage
\setcounter{page}{1}
\pagenumbering{arabic}
%
% Describe the project. Much of the text from the intro of the user manual
% can be used.
%
\chapter{Project Description}
d29 2
a30 9
\input{proj-desc}
%
% Describe specific techniques that were learned from the class and applied
% to the project.  Below are just a few examples of text that can
% be included in this section. Feel free to add more sections are you
% feel necessary.
%
\chapter{Techniques Learned and Applied}
\section{Methods and Processes}
d32 2
a33 5
  Many software engineering methods and processes were learned as a result of 
designing xplan for our groups CPS 470 class project.  Some of these are
software engineering methods, software engineering tools, business management
tools, technical writing and communications skills, and team engineering 
skills are explained below.
d35 2
a36 23
   In designing our project, we often used structured analysis and design
techniques to develop and communicate xplan's design and ideas for 
implementation.  For example, the numerous data flow diagrams and control flow
diagrams help us to clearly organize our thinking regarding how our project
would be designed.  Writing processing narratives describing how the diagrams
worked help us to develop the software solution.  From that information, the
program description language (PDL) was the detailed design implementation of 
our ideas.  The above methods when performed in the organized way taught in 
CPS 470, helped us to take our ideas from a vague and conceptual phase into a 
clear and organized format.  Learning how to work out details in the design 
phase is the most important skill we learned for software engineering.  
Furthermore, the processes of thinking about testing specifications and user 
manuals as part of the design phase of software engineering helped us to 
further refine our ideas.  Basically, the various documents and the necessary 
work that went into preparing the xplan documents taught us how to get our 
software designed in a logical and detailed way before we started coding.
Once the design is good, we learned that most of the problems with 
implementation will be related to the coding, syntax, and learning the 
details of the implementation environment.  The coding phase will be much 
easier once we are professional software engineers, because we will be 
experience in all the details of the hardware and software tools used to 
implement a detailed design.  Since we are students, we are still learning 
those things and gaining experience.
d38 1
a38 7
  Technical review milestones were an important thing we learned in CPS 470.
The processes of reviewing our work from a critical perspective was better
than just assuming everything we designed was correct.  The critical review 
of all of xplan's designs, and design documentation helped us to catch many 
design errors before we started coding.  Thus, we were more efficient in the 
implementation phase of engineering xplan because several critical problems
were worked out early in the design phase.  
d40 3
a42 16
  In CPS 470, we also learned many valuable practical business skills.  The 
documentation requirements for xplan improved our technical writing and
communications skills.  Furthermore, we learned a lot about how to work in a 
team environment, and how to communicate complex technical ideas to our peers.
The team work required us to refine our skills because other people would be
reviewing and using our work and they evaluated it from a different
perspective than we do when something is done individually.  They many 
different perspectives helped to contribute lots of good ideas for designing
and implementing our project.  That was important because the selection, 
evaluation, and implementation  of different
complex ideas is what the professional software engineer does on a daily basis.
Finally, the emphasis on software quality assurance was an important part of
the skills we learned while designing and implementing xplan.  The process of 
building quality into a design before implementing it is important, because it
makes us more productive software engineers who design better software that 
is maintainable.
a43 186
   Finally, the object oriented analysis and design techniques were useful 
skills we learned.  Although we did not use an object oriented language like 
C++, the object oriented analysis techniques helped us to think about certain 
aspects of the xplan project such as the database portion.  If a user wanted 
to extend xplan, the database and graphical user interface are highly coupled.
Thus, more advanced features using object oriented methods could be designed
and then added to xplan by modifying the graphical user interface and call
back functions. The object oriented methods we learned in CPS 470 taught us
how to design software in a modular way so that it's code can be reused and 
the addition of future enhancements can be accommodated.

\section{Tools}

  In the course of designing and implementing xplan,  we learned how to use 
several tools that are useful for software development.  For example, our 
programming skills utilizing C and Unix improved, because the xplan project 
was a large piece of software.  The processes of configuration management 
using RCS was a good experience because it kept track of various stages of 
design development in the group in a consistent way.  The OpenWindows 
Developer Guide 3.0 was a good CASE tool to learn, because many useful 
applications utilizing C, Unix, and X Windows can have useful and complex 
Graphical User Interfaces developed quickly and efficiently.  LaTeX was a good
document processing system to use, because it facilitated writing large
documents in which several different people contribute, text, tables,
equations, postscript figures, GUI screen dumps, and diagrams.  Flex and Bison
were used for inputing files to xplan. We also used several other useful tools
such as the emacs editor, vi, xfig, the dbx debugger, etc... Furthermore, on 
important tool we learned and worked with was MS Project.  In addition to
learning how to use MS Project for business applications, we learned the 
process of critically evaluating a competitors piece of software and designing
a different piece of software to perform the same function, but provide the 
user better features.  That is a good academic simulation of a real industry
experience.  Finally, it was a good experience designing and implementing 
xplan with the tools available to us in CPS470 because they are the same tools
that are used in industry.

%
% conclusions and future work
%
\chapter{Conclusions and Future Investigations}

  What does Dr. Cheng expect for this?

%
% Describe functionality that does not work completely in your system.
% Explain why you were not able to completely implement the respective
% features. You may include shortcomings of the system as you have
% determined from testing.
%
\section{Functionality Limitations}
%
% What are the limitations of the system? (Why do they exist?)
%
\subsection{System Limitations}

  The xplan software is limited in the number of PERT/Gantt charts which can
be displayed to the graphics display terminal of the SPARCstation. That is
because of the physical number of points allowed to be drawn on an X Windows 
canvas. Furthermore, the amount of memory available will limit xplan in
regards to how much information can be supplied to it regarding a project.
For example, memory space is created and freed dynamically as necessary in
xplan.  If every project task has millions of resources, the total memory 
available to xplan is limited by the system xplan is installed on. xplan was 
designed to expect valid input data. xplan was not designed to prevent a user 
from intentionally inputing faulty data with the intent of crashing the
software.  Finally, the size of the amount of a PERT/Gantt chart which can be
viewed at the same time is limited by the size of the graphics display 
terminal.  However, vertical and horizontal scroll bars are provided for the 
user when the PERT/Gantt chart is large than the viewable area on the display
terminal.

  The user must input correct data at all times for xplan to function 
correctly.  For example, To correctly calculate the dates of a project's
PERT/Gantt charts, it is necessary that all tasks between the very first
and the very last have dependencies, and be a dependency of at least one
other task.  That is because there is only one starting point, and one ending
point on the critical path.  The PERT chart display of xplan will show
dangling tasks, but the calculated dates will not be correct. The vertical
display of task boxes on the canvas window for the PERT chart is about 200
tasks. The horizontal display of task boxes on the canvas window for the PERT
chart is also about 200.  Note that if a large number of tasks are entered, such
as 150 or more, scrolling through the canvas displays will be slower because
of there are more graphics items displayed.  However, that also depends on 
the system load of the machine running xplan too.  Generally, a Sun 
SPARCstation 2 is recommended.  The Gantt chart task time box calculations
depends on the planed start and end dates of the task.  If the user does not
specify planned start and end dates for a task, the calculate dates function
of xplan's main window will fill in the planned start and end date fields.
However, this is dependent on correct user input.  For example, the total
task path time dependency must not be more than the time allowed for the
project as specified by the planned start date of the first project task, and
the planned end date of the last project task.  Basically, the user must 
input correct time durations for tasks to avoid faulty calculations.

%
% What are the properties of the system that make it
% usable?
%
\subsection{Properties Facilitating System Use}

  xplan is a very usable tool because of the design of its graphical user 
interface.  The menus and control buttons are layed out in a self explanatory
style.  Furthermore, the online help facility can be called at anytime by 
clicking the help key on the SPARCstations keyboard and using the mouse to 
click on the GUI item the user wants an explanation of.  Furthermore, xplan
can be a valuable tool when incorporated with the LaTeX document processing 
system.  The PERT/Gantt chart information generated by xplan can then be
incorporated in documents produced with LaTeX and then laser printed paper 
and overhead slide hardcopies can be made. Also, LaTeX could put a document
with PERT/Gantt chart information into Postscript file format so that project
reports could be distributed electronically over a computer network like an 
office LAN or the Internet.  Finally, xplan is provided as freeware according 
to the Free Software Foundations policies, so the budget 
conscious user can have a powerful project management and project document
processing system since LaTeX is also free software. 

%
% If you had it to do all over again, what would you do differently?
%
\section{Reflections of Project}

  The design of xplan was a tedious process because our group was learning the 
methods, tools, and techniques of software engineering.  Also, much time was 
spent learning and using the implementation environment.  For example, since
we are students, more time is spent on detecting and fixing logical errors,
syntax errors, learning tools, etc... If we were to do another design project,
we would be much more efficient in this area.  Furthermore, if we did another
design project and had more CASE tools such for things like data flow 
dictionaries, data flow diagrams, and control flow diagrams, we could produce
documentation faster because those items would have a tool for consistently
creating them and putting them into a LaTeX format. 

    In terms of designing a better xplan software solution to the PERT/Gantt 
chart generator application, an object oriented design and implementation could
be tried.  For example, the ideas discussed in the Future Investigations
 portion 
of this document could be implemented easier in an object oriented design 
and implementation environment.  The concepts of class hierarchies, and object
libraries could be applied to specifically design a piece of software with the
intent of being modified for future feature enhancements and modifications.
For example, objects describing particular types of tasks in a format specific
to them could be created, and then selected by the user when using xplan.
For instance, if a task like ``test circuit design'' has a different set of 
steps than a task like ``audit project budget'', different object could be
placed in the object library as xplan was applied to organizations which had
different ways of doing tasks.  Thus, the object oriented implementation of
software facilitates future modification of it.

   If xplan were to be redesigned, a better graphical display of PERT charts
could be developed.  Currently, they are large simple boxes whose aesthetics 
could be improved.  Also, xplan could be modified to allow the user to click
on a box in the PERT chart to see the Task Information window popup.  That
would be helpful for viewing very large charts with lots of tasks, instead
of having to look at the main xplan window to be able to click on a task 
name and have its information displayed.  Furthermore, a tool such as ispell
could be integrated with xplan to allow the user to check the spelling of 
task descriptions which may be quite long.


%
%
%
% Describe extensions to your project that you might have incorporated
% into your system if given enough time. 
%
\section{Future Investigations}
   The xplan user could extend the software in several ways.  First, the 
original design called for the calculation of PERT/Gantt chart information for
subtasks of a task, so large tasks could be managed with xplan the same way
the project is managed.  That way, more information could be stored in one
project file, instead of the current method of needing separate project.
Furthermore, additional features and data items could be added to xplan and 
it's graphical user interface.  For instance, the Task Windows could be
revised to store information specifically regarding personnel working on a
task, and contact information about them such as office location, phone
number, etc...  Currently, we just have a single list of resources which is 
not stored in any particular order.  The resources list could be modified into
an entire extension to the xplan software to classify resources in terms of 
hardware, software, tools, budget accounting, etc... The way xplan is 
implemented with the graphical user interface built with OpenWindows
Developers Guide 3.0 tool, further add  ons to xplan is possible by a
knowledgeable developer.  Finally, the xplan user could use the OpenWindow's
Developer Guide 3.0 tool to translate the English language labeling of 
xplan's GUI items into another language which can be written with the ASCII
character set, so xplan could be made available in foreign countries.

a44 12
\chapter{Changes and Addendums to Deliverables}
%
% Use whichever sections apply to your project. Make sure that you make 
% references to specific section and page numbers in this part of the text. 
% (Remember, the scenario is if you were given your project as a maintenance
% project next term, what information and how much detail would
% you need to modify the project.)
%
%
\section{Software Project Plan}
   The subtasks feature for a project task was not implemented in the final
version of xplan.
d46 1
a46 3
\section{Requirements Analysis}
   The subtasks feature for a project task was not implemented in the final 
version of xplan.
a47 14
   xplan can display 200 by 200 project box tasks to the X Windows canvas
for the PERT chart.

\section{Preliminary Design}
   The subtasks feature for a project task was not implemented in the final
version of xplan.
\section{Detailed Design}
   The subtasks feature for a project task was not implemented in the final
version of xplan.
\section{Testing Specifications}
   The subtasks feature for a project task was not implemented in the final
version of xplan.
%
%
a48 15
\chapter{User Manual}
%
% NOTE: Make sure that you incorporate all the changes that were
% made to the first draft of the user manual.
%
% Purpose of tool, scope.  Also, describe any assumptions
% you may be making about the abilities of the user.
% (i.e. Does the user need a Ph.D. in Astrophysics
% with a Masters in Quantum Mechanics to run your
% tool or can a regular bum that thinks computers
% are evil use it?)
%
%
\section{Introduction}
\subsection{Hardware Requirements}
d50 1
a50 21
The development team of Michigan State University students who created
xplan designed the software to be run in a Unix and X Windows
environment on Sun SPARC 1 and 2 machines.  A graphics display
terminal is necessary for drawing the PERT/ Gantt charts in xplan's
GUI.  Since no special meaning is attached to color, either a color or
black and white graphics display terminal will work for xplan.
Furthermore, a 3 button mouse and a keyboard are necessary for
interacting with xplan's GUI.  Sun SPARC 2 machines are the preferred
platform because the increased hardware power will allow xplan to run
faster.  The difference in performance will most likely be observed
for projects which push the performance limits of xplan by having a
large number of tasks spread over a five year period. Other hardware
platforms that support a Unix and X Windows environment may also run
xplan.  For example, xplan could be installed to run on other
workstations like various Sun models, NeXT, Hewlett Packard, or
Apollo.  However, the authors provide no support for other hardware
platforms. Furthermore, customers who are part of the Internet
community will need the necessary network hardware and software
connections for anonymous ftp to the public access site at Michigan
State University for obtaining copies of the xplan source code and
documentation.
a51 80

\subsection{Software Requirements}


The software requirements for compiling and running xplan are the
following.  xplan was written to run in a Unix and X Windows
environment. The user will need to have a gcc ANSI C compiler, X
Windows, and X Libraries for compiling the xplan software.
Furthermore, since xplan was specifically designed to produce results
which may be incorporated into other documents, the LaTeX document
processing software is necessary for obtaining LaTeX file formatted
output of PERT/Gantt charts.  The user may then use LaTeX to
incorporate these charts in the documents they prepare and process
with LaTeX.  Those documents may then be printed to hard copies of
paper or overhead slides for reports and presentations.  Also, ASCII
text files may be used to save and input PERT/Gantt chart information.
If the user wanted to translate the language of xplan's GUI into
another language which may be represented by the ASCII character set,
the OpenWindows Developer's Guide version 3.0 will be necessary for
modifying xplan's GUI.  For instance, a user may obtain xplan via
anonymous ftp from Michigan State, and decide to translate the GUI
language into French so users in France may use xplan for project
planning.


%
% Include Online help facilities.  Describe what each
% feature of the system is.  Describe fully what
% different options/selections will provide to the user.
% For instance, describe what each button allows the
% user to do.  btw, you can change the name of the section
% if you like.  If there are special languages that the
% user must know for input into the system, include 
% the description of that language here.
%
\section{Functionality Description}

   The subtasks feature of a projects task was not implemented in the
final version of xplan.

%\input{functional}

%
% Provide a simple tutorial that includes a
% generic scenario for using the system.  Provide
% screen dumps, etc.  Make sure that this tutorial
% is representative of the types of operations found in
% a typical session.  As with the previous section,
% you can change the name if you find another more
% appropriate.
%
\section{User Scenarios}
%\input{scenarios}

%
% Provide a description of the steps needed to 
% install the system.  This should include any
% details not mentioned in the introduction (i.e.
% environment setup, etc.)
%
\section{Installation Procedure}

%\input{installation}
%
% You know the drill
%
\section{References}


%
% HINT!!!!:  Think about the worst user manual you've
% ever encountered.  Consider what you didn't like
% about it; was it missing something, was it redundant,
% was it incorrect?  After you've thought about these
% characteristics that you found unappealing, write
% the document with the intent of not emulating the
% worst manual you've ever seen.  ^^^  
%
% 
%
@
