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.
 

Build Plan

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 these modules
into a data-flow or a macro-module. The front end will generate a description of the
data-flow which will be then executed by the back end.

We parallely devloped the GUI and the back end. An existing software product helped
us generate a framework for the user interface. We have added the data-flow operations
like adding new modules, getting information on a module, and running the data-flow
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 and knowledge
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 necess)
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 involved in
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.

Testing plan

//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 coding itself.

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 itself.

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.

Raghavendra Sunku