Table of Contents

1.1 Project Overview
1.2 Definitions, Acronyms, Abbreviations
1.3 References
1.4 Overview of Document

2.1 Process Model
2.2 Organizational Structure
2.3 Organizational Boundaries and Interfaces
2.4 Reviews, Walkthroughs, Inspections, and Audits

3.1 Management Objectives and Priorities
3.2 Team Name
3.3 Possible Meeting Times
3.4 Team's Range of Skills and Experience

4.1 Overview of Functional Requirements
4.2 Overview of Data Requirements
4.3 General Constraints, Assumptions, Dependencies, Guidelines
4.4 Users View of Product Use

1.0 Introduction

1.1 Project Overview

This project ( Field of view Coordinate Correction ) involves reading live GPS, compass and inclination signals and then laying a coordinate system over a live video image. The live image is looking in the same direction as the compass heading and the GPS coordinate is the location of the camera. Magnetic declination must be taken into account. A flat plane in the field of view is assumed.

1.2 Definitions, Acronyms, Abbreviations

GPS: Global Positioning System
Fully autonomous: there is no human in control of the vehicle at all. No contact with the vehicle can be made once the race is underway. The vehicle must 'see' what is ahead of it and navigate appropriately.

1.3 References

• Henderson, Thomas. Professor at the University of Utah Department of Computer Sciences.
• Erickson Brandt. Teaching Assistant at the University of Utah Department of Computer Sciences.
• Takach, Troy. Project manager at DesignJug
• "Franson GpsTools"2002. Online. Internet. [21 January 2005].Available WWW:
  http://franson.biz/gpstools/reference_manual.asp?comp=view&class=&item=&platform=win32

1.4 Overview of Document

• Section 2.0 describes the project organization such as team members roles, how we plan to process to evaluate the project using walkthoughs, inspections,and audits.
• Section 3.0 describes the Team-specific aspects such as the team setup, team name, possible meeting times, and the team's range of useful skills and experience.
• Section 4.0 describes the preliminary sketch of project requirements, functional requirements, data requirements, how users will use the product, and other constraints, assumptions, dependencies, guidelines and so on.

2.0 Project Organization

2.1 Process Model

We plans to use the prototyping model in which the client and our team will work together to meet the client's expectations. By utilizing the prototyping model, we can get feedback on our work done from the client on a regular basis to ensure that we are on the right track. We will design and plan out ideas on paper and present them to the client for comments, approvals, and ideas. Once the client is satisfied, we will implement our design.

The following table outlines the schedule of project events:

Proejct Item	Date(s)
Project Plan	Jan 24
SRS v1	Jan 28
Planning Checkpoint Review	Jan 31
SDS v1	Feb 4
SDS v2	Feb 18
Code Review	Feb 20
VVP	Feb 23
Stage 1 release	Mar 4
VVR	Mar 9
User input	Mar 25
VVR v2	3/30
Stage 2 release	Apr 1
VVR v3	Apr 12
Stage 3 release	Apr 14
Formal Presentation to Industry Sponsor	Apr 15
Product Release	Apr 20
Legacy Turn-in	Apr 25
Demo	Apr 28
Final Report	Apr 29

2.2 Organizational Structure

Our team will function in a democratic manner. Every member in the group will have an equal voice and impact in the decision-making of the project. We believe this will encourage more collaboration in the team. Each member's opinion will be taken place equally and then we will make a better decision with that. However, each member will be in charge of a specific area of responsibility

Project Roles	Responsibilities
Team Leader	Responsible for overseeing progress within each of the subteams and informing the group of upcoming deadlines
Programming Leader	In charge of implementation of the client's requirements
Client Liaison	Responsible for establishing and maintaining communication with the client. Responsible for giving the client updates to the project scheduling appointments and passing any updates from the client to the team.
Techical Writers	Reponsible for creating documents required for the project
Techical Editors	Responsible for proofreading and revising any techical documents that have been written and are slated for submission.
Webmaster	Responsible for maintaining the team's website and ensuring that the directory structure complies with the S2S guidelines.
Graphic Designer	Responsible to evaluating and creating the user interface for the program that is easy to use, intuitive and within the expectations of the client.
Code Reviewer	Responsible for ensure that there are not any logic errors or other coding problems that might cause a failure in the future.

Team Member	Role
Hyoungsuk Kong	Team Leader, Techical Writers
Taeho Kim	Programming Leader, Webmaster
Mina Jeong	Graphic Designer, Techical Editors
Bo Jin	Client Liaison, Code Reviewer

2.3 Organizational Boundaries and Interfaces

Instructor will give us any questions, set deadlines for milestones, provide guidelines for our completion and periodically check the progress of the project.

The mentors will give advice on how to approach the project. They will provide feedback on milestone documents.

The client will give us specifications and requirements for the project. He will also give feedback on the project while it is under development.

2.4 Reviews, Walkthroughs, Inspections, and Audits

2.4.1 Procedures for reviews, walkthroughts, inspections, and audits

Document reviews will be held during end of team meetings.During these reviews, each member will have a copy of the documentation, then revise according to given feedback.

Once the documentation have been revised, webmaster will update the documentation on the web and submit it.

Team meetings will be held at least three times a week. We will adjust the process of project. Discussions on documentation, implementation and testing procedures will be the focus of these meetings.

Code reviews will be held to ensure the implementation has any logic error or bug might be caused in the future.

Walkthrough procedures will also involve all team members, where individuals will explain the work completed. Each team members will then offer comments and suggestions.

Inspections will occur during client meetings, in order to maintain focus on the client's expectations. Audits are conducted by the CEO to ensure that the project is following specification before entering final release.

2.4.2 Schdule of reviews, walkthroughts, inspections, and audits

Document reviews will occur every week before any submission.
Code reviews and walkthrough procedures will occur during team meetings every week.
Client inspection will occur once a week.
Audits by the CEO will occur once a week.

3.0 Team-Specific Aspects

3.1 Management Objectives and Priorities

The goals of our product are to deliver the complete product, and gain experiences. Each team member has high respect to each other, and even though there is only one team leader, everyone has same responsibility, and respect for the team, and the project. Each member of team will work hard to fulfill one's duties, and help with other's duties.

3.2 Team Name

HTMB: To create motivated teamwork, we use the abbreviations of each team member. It is also our team moto, which stands for "high technology make better future."

3.3 Possible Meeting Times

• Weekday: 3:00pm - 5:00pm
• Weekend: 12:00pm - 5:00pm

3.4 Team's Range of Skills and Experience

    Glossary: 1 = very experienced, 3 = some experience, 5 = no experience.

	AJ(Hyoungsuk Kong)	TK(Taeho Kim)	Mina Jeong	Bo Jin
C	1	2	2	1
C++	1	2	1	1
Java	1	1	2	1
HTML/XHTML	1	1	4	2
Javascript	1	1	5	2
PHP	1	1	5	3
Flash/Dreamweaver/Fireworks	1	1	5	3
Photoshop	5	2	4	3
Unix/Linux	2	3	3	2
PC/Windows	1	1	2	1
Mac	3	3	3	2
Oracle PL/SQL	1	1	3	1
MySQL	1	1	3	2

4.0 Preliminary Sketch Of Project Requirements

4.1 Overview of Functional Requirements

The product's task is analyzing vectors, pictures, and GPS coordinates. The product must analyze any obsticles from the pictures, and calculate the new coordinates.

4.2 Overview of Data Requirements

We will need to analyze from the picture from the real-time camera and the real-time GPS coordinate, and calculate the new path coordinate.

4.3 General Constraints, Assumptions, Dependencies, Guidelines

This product will require to analyze JPEG file.
This product will only work at certain location, where GPS satellite can reach.

4.4 Users View of Product Use

The product developed will significantly accelerate the real implementation of autonomous military land vehicles saving real American and Allied lives on and off the battle field. The product will analyze picture, and based on the newly drawn picture's path, it will calculate the path coordinates.

5.0 Change Control Plan

1. Contact team members by email or phone.
2. Receive positive responses from all team members.
3. Contact Sponsor, and notify changes.
4. Receive final approval from the sponsor.
5. Final discusison with all the team members.

6.0 Quality Assurance Plan

Everytime we release new version, we will throughly test it for the bug-free program. Then we will spend at least 2 weeks at the end of the semester to just testing the project to make sure that it is working properly and fix any problems that we find along the way.

7.0 Project Estimantes

GPS device - Free (Sponsor provided)
Camera - Free (Sponsor provided)
Flash memory - Free (Sponsor provided)
Dangle port(Com port to USB) - Free (Sponsor provided)
VB6 - Free (Sponsor provided)
Video licensing - Free (Sponsor provided)

Change log

Back to cs4500
Back to Home
Back to Top

Maintained by
       Taeho Kim