Modification history:

Team Members:

• Jeff Goodman (Jeff2379@aol.com)
• Jeff Miller (J_Miller68@hotmail.com)
• Michael Wales (Mag7Rule@aol.com)

Contents of this Document

Project 0verview

Reference Documents

Applicable Standards

Project Team Organization

Deliverables

Software Life Cycle Process

Tools and Computing Environment

Configuration Management

Quality Assurance

Risk Management

Table of Work Packages, Time Estimates, and Assignments

PERT Chart

Technical Progress Metrics

Plan for tracking, control, and reporting of progress

There are a few different key components to our project, and there a few optional components that we are hoping to implement before the project is finished.

Mandatory components:

• Robot Controller API: This is the API that will communicate with either a SAF simulation or the manual controler program. This module will then establish a communication link between itself and the robot's interface.
• Manual Controller Program: This will be a program that interacts with the a human user to provide direct control over the robot (no need for a SAF simulation). The program will either be implemented with Java (and communicate to the Robot Controller API process through sockets), or be a C++ program with an instance of the Robot Controller API. This program will allow the user to control the robot by either mouse or joystick (whichever we decide to implement).
• Robot Surrogate Program: This will be a program that is designed to emulate a robot interface, without the developers actually needing to have a robot onhand. It will provide user's information as to what the robot should currently be doing from past commands, and a list of the commands as they come in.

Optional components:

• Implementation of system to control a robot from IST: We are going to put lots of effort into reaching the goal of having this system working enough to allow for direct human control of a real robot. We will have to create or adapt our robot interface to interact with an actual robot. This will allow us to really demonstrate some possible long-term uses for this interface.
• Implementation of the API within a SAF: If our project progresses fast enough, we will also like to add the API to an existing SAF simulation. When you couple this with the previous optional component, we would have a real robot being controlled entirely by a simulation.

Our overall plan is to complete the system design of the mandatory components by April 20, 2001. These documents will be presented as our Senior Design I documentation. Beginning on April 30, 2001 we will start implementing our design into code. After we finish implementing and testing the mandatory components, we will work on designing and implementing some of the optional components. We hope to demonstrate the system with atleast the first optional component completed when we present this at the end of Senior Design II at the end of July 2001.

• Our project proposal for Senior Design I
• Concept of Operations
• Software Requirements Specification

• Coding Standard: Our code will be well documented at the head of the file and throughout each file. Each version of the code will have it's date with it and version number. Code will have generous white space and all code blocks will be indented to provide for easier code reading. We will adopt a naming convention similar to the naming convention of the Java programming language. All classes will start with capitol letters, while functions will start with lower case letters. All classes will be in seperate files, and have documentation on the other classes (and the other class' version number) that they are compatible with.
• Document Standard: All our non-code documents will be in the HTML format. The font size will be the default font size, with headings in boldface, and major headings in enlarged fonts. We will use Microsoft Word to perform grammer and spell checking on our documents before their final submission. The user manual will definitely be checked because it is a deliverable to the customer. All sizeable documents will have a table of contents and a modification history.
• Artifact Size Metric Standard: Our metric for measuring the size of our code and progress will be to measure the size of the source code files in bytes. This metric will lessen the effects of whitespace (where as "lines of code would" increase) on our progress. This metric will not convey the complexity of the code, but it is quick, easy, and will fit our purposes.

We have three team members. Each member is responsible for contributing to the deliverables. Each team member should continuously update their personal webpage with their weekly contributions and activities. In addition to everyone doing those tasks, each member should do these following unique tasks:

• Jeff Goodman: Will create the weekly report for every other week (the week Jeff Miller isn't doing it.)
• Jeff Miller: Will create the weekly report for every other week (the week Jeff Goodman isn't doing it.)
• Michael Wales: Will be a project leader and divide tasks between himself and the other group members. Will be responsible for proofreading, editting, and uploading all code and documentation to the team webpage. Michael will also be responsible for any communication with Dr. Franceschini that only requires 1 team member to meet him in person or attend IST/STRICOM meetings. This responsibility is delegated to Michael because it is simply more convinient since he works at STRICOM.

Deliverables

We will complete the entire system design for all the mandatory component before the end of Senior Design I. The implementation of all code will occur in Senior Design II. Below is tentative flowchart of development activities:

1. Project analysis
2. Requirement ellicitation
3. Project planning
4. High-level design
5. Detailed design
6. Implementation of Robot Controller API module and Robot Surrogate module
7. Testing of Robot Controller API and Robot Surrogate functionality and connectivity.
8. Iterate steps 6-7 until those two modules appear to be quality.
9. Implementation of the Manual Controller program.
10. Testing of the Manual Controller program.
11. Iterate steps 9-10 until Manual Controller program appears to be quality.
12. Testing of all mandatory system components.
13. Iterate steps 6-12 unitil entire system is quality.
14. Complete all documentation and deliver.

We will using two different development environments. We will use Windows environments alot because they are easier to access and use than UNIX/Linux environments. Code can be generate on Windows machines, FTPed to UNIX/Linux machines, and then compiled. UNIX/Linux could also be used solely to generate all code and documenation. These decesions are made by each particular team member based on their personal preferences. Some of the possible destination environments will be SGIs running Irix, Sun workstation running Solaris, or PC's running Linux (probably RedHat).

Development tools

• Code Edit: A freeware text editor available online with better functionality than Windows notepad.
• GCC / G++: The UNIX C/C++ compiler that comes for free with UNIX machines.
• Java 2 V1.3 SDK: We are considering using Java for our GUI programming because we are so familiar with it.
• Microsoft Internet Explorer: We will use this web browser the most for viewing webpages (mostly because it loads about 5 times as fast as Netscape).
• Microsoft Word: Will be used for spell checking and for creating our final documentation packages.
• Microsoft PowerPoint: Will be used for creating any presentations.
• Netscape Navigator: Will be used for viewing webpages when IE isn't available to use.
• SnagIt: We will use this video capture tool to make .avi files for use in our presentations of our system at work.
• Visio 5.0 Pro: We will use Visio to create most of our UML diagrams.
• WS FTP: A shareware FTP client that is very easy to use.

There aren't many differen't modules in this project, so our configuration management will not require much effort. Code should be transmitted between team members in one large zip file with a 6 to 8 digit date indicating when the code was created. We don't anticipate any alternative versions of our code besides the final version (as opposed to a version that supports x, and one that supports y). All version of the code will be kept on the website for reference.

Our group will perform quality assurance by following our coding standards, checking and performing all prescribed test cases. Following our coding standards should allow any member of the group to understand the code of the other members, thus reducing the chance of error. Performing the test cases will show if our product has meet the requirements and it will also show if the program is stable.

Time:
To make sure we don't fail to deliver on time, we must be careful to manage our time very wisely. Michael, as the team leader, will make sure we keep up with our timeline to ensure we don't fall behind schedule. We will also schedule ourselves to finish the mandatory components atleast a month in advance to give us time to complete the optional stuff, and some extra time to finish the mandatory stuff incase something goes horribly wrong.

Experience:
We hope to overcome our lack of experience by doing research in unfamiliar areas, requesting assistance and guidance from our mentor Dr. Franceschini, and by "practicing" unfamiliar code. "Practicing" would probably involve creating a short seperate program so that the developers can learn how to do something, without the overhead of including it in the overall system at first.

Computer Availability:
It doesn't appear right now that we will have many problems getting access to the computer environments we need. Possible sources include Linux PCs that we create ourselves, some of Dr. Franceschini's Sun workstations, Bruce Sun workstations, or possibly even some of STRICOM's workstations.

Work package	Estimated Time	Responsiblity
Pre-Implemenation Documentation	25 hours	Everyone
Design	20 hours	Everyone
Implementation	150 hours	Everyone
Final Documentation	30 hours	Everyone

• Requirements Phase: Number of requirements
• Object design: Number of UML diagrams created
• Detailed design: Number of classes, and number of methods
• Implementation: Size of the source code in KB
• Testing: Number of errors
• Documentation: Number of pages of documentation

Plan for tracking, control, and reporting of progress

At a minimum, each team member will post the following information weekly: individual time and activity log, individual status information, and individual issues and problems

Each week the Project Management Report will be evaluated by all team members. The team members will then decide together how the pace of the project should be altered.

This page last modified by Mihcael Wales (Mag7Rule@aol.com) on April 7, 2001