Build and Test Plan
This part of the technical manual describes the the design we used to build
the whole system,
issues involved with porting our system to a Windows-based environment,
and how we tested
our software product.
We identified a GUI front end and a back end module-manager to be the subsystems
of our entire system. The GUI front end has all the capabilities needed
to describe a
module, its location, and its parameters and connect and disconnect
into a data-flow or a macro-module. The front end will generate a description
data-flow which will be then executed by the back end.
We parallely devloped the GUI and the back end. An existing software
us generate a framework for the user interface. We have added the data-flow
like adding new modules, getting information on a module, and running
to the GUI. The main part of generating a data-flow graph was handled
in a separate panel
in the UI. The design of our back-end was based on our own discussions
obtained from researching different topics.
Our plan has been to create a modular implementation in C++ so that
our own subsystems
were integrated easily. We have packaged the back end of our system
as a sort of library
and the GUI will generate the desciption files about the data-flow
and the modules in a
format understood by the back end.
Porting to Windows
//Describe (after discovering) porting methods to PCs. (Talk to gash if
One of the client requirements of our software was to develop our system
in a way which
will make it easily portable to Windows. At this stage we have planned
to use Visual C++
as our development platform in Windows and we have identified the issues
the porting. For example, the pathnames and command line options might
have to be changed
while porting or we might have to change the set of include files.
//Describe our testing plan (whatever that is).
Due to the graphical nature of our software, we cannot perform formal
testing on our code.
Our testing plan, hence, was more closely in the university tradition
rather than strict industrial
practices. Due to the modularity in our system testing was done most
of the time at the level of
individual modules. The major efforts in testing occured while we were
Its not very practical to automatically simulate mouse clicks and key
presses to test our GUI
front end. We manually tested the user interface by randomly clicking
and typing several times
during the development stage. We found bugs and corrected them as we
developed the windows
which contained different modules and which contained the data flow
The back end was then integrated with the user interface and the whole
system was tested by
hard coding some of the modules and their descriptions and not worrying
about the data types
of inputs and outputs of these modules. We did a systematic testing
by creating different kinds
of data flows and running the flow from the user-interface.