|
|
|---|---|
|
|
|
The requirements
of the user interface can be described in terms of the types of displays
that it must be able to perform on and the user devices that it must be
able to support.
The system will
be using the Java Look and Feel (JLF) formally known as Metal for
the interface.
Allow users
of the vast majority of systems to be able to use Java applications.
It would be
safe to assume that users of this system will have a VGA 640 by 480 or
better screen although the JLF will support lesser screen capabilities
than this.
The system will have to support numerous devices. The keyboard will be used as the primary input device. Keyboards have been proven to be the best device for text input, the use of non-standard keyboards such as the Dvorak or Chord Keyboard will have to be supported by the underlying operating system. In addition
to the keyboard, devices for manipulation and selection of objects will
be supported. The mouse, trackball and accupoint(on laptops)
will all be supported to fulfill this need.
Errors will be detected by
the system and delivered to the user through the use of message dialogs.
Any error encountered by
the system will generally be reported in a Message Dialog. There
are different message dialogs displayed depending of the severity of the
error. For the less severe error a warning message will be displayed
and for the more critical errors an error message.
7.3 Diagnostic Utility Software The only diagnostic utility
software that accompanies the system is an application that allows the
user to view the file in it’s raw form. This gives the user who has
knowledge of how the information is stored the opportunity to fix a corrupted
file.
In order to verify that the system meets the requirements specified in this document, a variety of tools, techniques and methods will be used. These methods implemented by both the Quality Assurance and Application Engineering teams will play a crucial role in assuring that the system meets the specified requirements. Peer reviews will be held within all Team Synergy sub-groups. This means that new code is submitted by an Application Engineer to be reviewed by another Application Engineer, who will then check it for any defects. Once this code has been reviewed it can then be submitted for review by the Quality Assurance team. Once the code is submitted to the Quality Assurance team, it is subjected to the testing procedure defined in the Project Plan (Section 5). Before any submissions to the Quality Assurance team are tested, a test script is to be written by each Quality Engineer involved (See Project Plan Section 6). These scripts are written according to the Test Script template written by the Quality Assurance team (This is available on request to the Quality Assurance Team Leader). These scripts consist of a list of proposed tests, expected results, and whether or not the submitted software passed or failed each test. The following list presents the type of test used with respect to the code type: * Code fragments (such as
single classes, a cluster of classes or non-self executing synchronised
classes) - white-box testing.
After each test is run any problems identified are listed in a test summary document. This summary document is then reviewed by the Quality Assurance Team Leader, and if accepted, passed on to the Application Engineering Team Leader. They then use this document as a reference to fix the problems listed in the Team Synergy Bug Tracking Tool. The software, once corrected, is filtered through the same process until accepted as complete by the Quality Assurance team. Tools that will be used by the Quality Assurance team when assessing software will vary. However there are some tools that have been developed explicitly for the purpose of testing code developed by Team Synergy. These tools are the strip, assert, log and debug java class files. They are used to strip code not to be tested, assert certain values to ensure that invalid values or situations do not occur, and to redirect debug information (such as exceptions) to tester-specified locations along with custom generated analytical data. These debug utilities will be available for download on the Team Synergy Web Site (http://cohesion.it.swin.edu.au/teamb) under "Downloads". Refer to the Team Synergy Project Plan Document (Section 4-6) for any further information. General design/implementation constraints include:
Although the system should run on any Java 2 compatible platform, it will only be supported on Win32 platforms. The client and server components of the system will be integrated and therefore using the system as a server will still include, but not use, the client software. Both the server and the client will need the same storage capacity as outlined below. The following physical objects have been identified to be within the scope of the deliverable system:
Both the Client/Server Computers will be expected to have the following minimum configuration:
|
|
Top | Copyright © 1999 Team Synergy. All Rights Reserved. | Contact the Webmaster for any issues regarding this site. |
|
Home |
News & Updates |
Current Projects |
Team Members |
Fun Page |
FAQ |
Downloads |
Site Map Task Management | Meetings | Documentation | Modifications Recommended viewing resolution for this Web Site is 1024 x 768 |
|||
