The testing process will include a scripting process that will test all supported method calls
of the tested item. This includes a log file as output and can have the potential of being run
interactively. Also, it should be noted that as new test areas are uncovered the testing
process will be updated to include methods for these areas.
MClass - Testing will include a comprehensive test for each aspect of the supporting base
classes. This should be primarily an automated process that can be run from either the DOS
prompt or from a shell written in Java.
Control Panel - Similar to the MClass testing methods this testing will also include
parameter to check both the visual aspects and the supporting classes.
Translator - This area will check to insure that a potential Java support class is parsed
correctly. This will include checks for instances of calls to Java classes that have been
modified to MClass(es).
Software testing must insure that the derived classes, both "Look and Feel" and
"Internationalization", are designed with the supported methods of the base classes. If new
methods are needed that are not included within the parent classes then new classes must be
designed to implement those methods.
The Mclass should support loose coupling between the existing classes in JDK and those
classes or methods that are designed for it at later stages of product development. Thus the
Mclass should support new classes built from existing JDK classes.
Inferred from the OOD above, software testing will be designed to first test the methods
supported within the base classes and their derived classes of the superclass MClass.
Relying on the current tools and classes available in JDK 1.0.2 a couple of assumptions can
be made:
a) All related classes in JDK are compatible with one another.
b) Any derived classes don’t need special support classes for platform interdependence.
c) Any new methods developed should be derived from the base classes.
Thus software testing should:
Start with the derived classes
Insure that each derived class is tested completely through each aspect of the supporting
class(es)
In the case that new classes are needed:
a) They must be supported by all prior classes to which they’re related.
b) Should be designed with existing classes, if possible. The Mclass should support loose
coupling between the existing classes in JDK and those classes or methods that are
designed for it at later stages of product development.
c) The Mclass should support new classes built from existing JDK classes.
TOOLS & ENVIRONMENTSDevelopment Platform
Our code will be developed on the SUN Solaris workstations.
Design Method
Since Java is an Object-Oriented Programming Language we will be using the Object-
Oriented Design Method with an Incremental Development Model. Our selection of the
incremental model was based on the reusable resources supplied by the Java Development
Kit. Our code will be an enhancement to some GUI features which will require trial and error
type programming that generates throwaway code. Another deciding factor is that we must
first learn the Java programming environment.
Development Software
Java Development Kit (JDK) 1.0.2
Java Programming Language
Java Compiler on Solaris
Java Debugger on Solaris
Software through pictures with Object Modeling Technique (OMT)
Test Software
The majority of our code will be tested on AppletViewer and our deliverable code will be
accessed via Netscape in a password protected area.
Project Management Software
Team Motorola has elected to use the Revision Control System (RCS) -to track multiple file
versions.
Documentation Software
Our paper documents will be presented in Microsoft Word and Microsoft Project. Our
source code will be documented by JavadoC.
Presentation Software
Our final design presentation will be presented using Microsoft PowerPoint and our official
design will be implemented and presented on the NAU-Motorola Group Homepage on the
world wide web.
Interactive Development Environment
Interaction between the team and customer will be through email, telephone and in person.
Testing and updates will be done through the NAU-Motorola Group Homepage via the WWW.
UPDATING PROJECT STATUSWeekly Status Reporting
A weekly team status report will be emailed to the motorola group which will include
meeting summaries, team progress, problems encountered, new tasks, and individual status
reports.
Reviews
Code and Design reviews will be done with client. An internal review will be done prior to
this meeting. There will be several of these meetings throughout the course of our
evelopment cycle. See Master schedule for dates.
Website
A Homepage will be maintained to reflect the current state of the project. This page will
include a password protected area which will contain code and official documentation
accessible to the group.