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


1.3
date	92.11.11.07.50.34;	author malingka;	state Exp;
branches;
next	1.2;

1.2
date	92.11.11.06.10.26;	author malingka;	state Exp;
branches;
next	1.1;

1.1
date	92.11.11.03.49.36;	author malingka;	state Exp;
branches;
next	;


desc
@general calculation module
@


1.3
log
@spell
@
text
@%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for General Calculation module} 
This module will perform tasks such as checking for dependency loop,
finding the critical path, and generating the position of each PERT box.
The first three test phases are used for analyzing the behavior and 
functionality of this module. 

\begin{description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for General Calculation module:}]  
There are three tests associated with this module. Those three tests correspond
to the three functionalities that this module will perform. 
begin{itemize} 
	\item The first test is used for checking whether the module can 
correctly detect different kind of dependency loops that might exist on the 
task network. There are two kind of dependency loops that we anticipate:
	\begin{itemize}
		\item {\em self loop} \\
	This can happen when a task depends on itself, in which the 
	dependency pointer points to itself. See Figure~\ref{self:loop}
	for an example. Since the loop can practically exists in every task
	node, several test cases will be supplied for verifying that the module
	did detect the loop.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=self-loop.ps,height=2in}}
		\caption[Self Loop]{An example of a self looping the task 
			network.}
		\label{self:loop}
		\end{figure}

		\item {\em predecessor loop} \\
	This refers to a task which depends on its predecessor(s). Given the 
	graph in Figure~\ref{self:loop}, there are many possible combination 
	of this type of loop. One such possible combination is given in
	Figure~\ref{pred:loop} 

		\begin{figure}
		\centering
		\centerline{\psfig{figure=pred-loop.ps,height=2in}}
		\caption[Predecessor Loop]{An example of a predecessor loop.}
		\label{pred:loop}
		\end{figure}

	\end{itemize}

	\item The second test is used to verify whether the module can 
identify correctly the longest path through the task network (critical path). 
The algorithm for critical path calculation will pick the first longest 
path encountered (in the case where there are more than one longest path). 
Therefore, the tests must ensure that the status of the longest path at 
any given time is not modified, unless a longer path is encountered. 

	\item The third test is used to verify that the PERT boxes are 
correctly placed into their grids. This is probably the hardest part to test
since the only procedure that we can think of is to check the result on
paper (since this test should be independent of \LaTeX\ PERT Chart 
Generation module). Output comparison with MS-Project was also considered,
but will not determine the correctness of the PERT box's location since
MS-Project output is not {\em the only} correct solution. 

end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\

A ``dummy'' database will be created to hold the different sets of test
data. The size and content of the database will be determined by the test
that will be performed on the module. When the Database subsystem has been
tested completely, the new test data will be generated by the Database
subsystem. \\
As mentioned in the description above, MS-Project output may be used as a 
comparison, but will not determine the correctness of the module's
output. Instead, it will be used to verify the validity of test data.
This is useful in a sense that we could check for bad test data. This will
ensure that if an error does come up, it is caused by the module, and not
by the test data. \\



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\
For most of the tasks in this module, a ``dummy'' database will be used.
Test case data that will be used for General Calculation module are as
follow:
\begin{enumerate}
	\item Multiple longest paths \\
	This test case is primarily used for critical path detection. The 
purpose is to create more than one {\em correct} answer for finding the
critical path.
	\item Multiple parallel paths \\
	This test case is useful for both critical path detection and PERT
box location. Since the calculations are based on depth-first-search
algorithm, the graph (or task network) is created in such a way to reflect
a breath-graph. % I don't even understand this; must rephrase.
	\item Multiple sub-paths \\
	This is probably the most important test case that will be used.
Recall that depth-first-search algorithm is based on graphs and/or trees.
In contrast, rarely the task networks will represent regular graphs and/or
trees. For example, a tree usually will have one root node and many leaf
nodes. With task network, we only have one root node (the first task) and
a few leaf nodes (the last tasks). See Figure~\ref{sub:path}.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=sub-path.ps,height=3in}}
		\caption[Multiple Sub-paths]{An example of multiple sub-paths.}
		\label{sub:path}
		\end{figure}

The module should be able to handle any number of sub-paths. 

	\item Stand-alone paths \\
	This test case is especially useful for testing the position of PERT
boxes generated. See Figure~\ref{alone:path}. The lose definition for 
stand-alone path is a path which covers more than 1 sub-paths.

		\begin{figure}
		\centering
		\centerline{\psfig{figure=alone-path.ps,height=3in}}
		\caption[Stand-alone Path]{An example of stand-alone path.}
		\label{alone:path}
		\end{figure}

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \

begin{enumerate}
\item If a task network contain a dependency loop, the routine 
traverse-task-list() should return an error message that was originally 
produced by the recursive function visit-task(). 
 \item Each node (or task) that belongs to the critical path must be clearly
marked in the database. The critical path can be found by traversing the
task list backward. 
\item Each of the PERT boxes must be correctly placed in chronological order,
and no two boxes can occupy the same grid.
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
%
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}
\end{document}
@


1.2
log
@end
@
text
@d8 1
a8 1
The first three test phases are used for analysing the behavior and 
d27 1
a27 1
	node, several test cases will be supplied for verifyng that the module
d33 1
a33 1
		\caption[Self Loop]{An example of a self loopin the task 
d159 1
a159 1
\end{document}
@


1.1
log
@Initial revision
@
text
@d16 8
a23 7
Thre are three tests associated with this module. Those three tests correspond
to the three functionalities that this module will perform. \\ 
The first test is used for checking whether the module can correctly detect
different kind of dependency loops that might exist on the task network.
There are two kind of dependency loops that we anticipate:
\begin{itemize}
\item {\em self loop} \\
d30 7
a36 6
\begin{figure}
\centering
\centerline{\psfig{figure=self-loop.ps,height=2in}}
\caption[Self Loop]{An example of a self loopin the task network.}
\label{self:loop}
\end{figure}
d38 1
a38 1
\item {\em predecessor loop} \\
d44 6
a49 6
\begin{figure}
\centering
\centerline{\psfig{figure=pred-loop.ps,height=2in}}
\caption[Predecessor Loop]{An example of a predecessor loop.}
\label{pred:loop}
\end{figure}
d51 1
a51 1
\end{itemize}
d53 6
a58 2
The second test is used to verify whether the module can identify correctly
the longest path through the task network (critical path).
d60 9
d74 11
d92 20
d113 6
d120 16
d141 9
a149 2


@
