Table of Contents

1.1 Purpose of this Document
1.2 Scope of the Development Project
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview of Document

4.1 Summary of component test
4.2 Summary of integration test / testing product as a whole

5.1 Evaluation of test cases
5.2 Results from defect tracker
5.3 Lessons learned

1. Introduction and overview

1.1 Purpose of this Document

The Verification and Validation Results document describes the out come of the various activities described in the Verification and Valication Plan documents. This document provided a detailed description of how we tested the product more of initial VVR and how the team will check for quality assurance.

1.2 Scope of the Development Project

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.3 Definitions, Acronyms, and Abbreviations

HTMB: out team name.
DesignJug: Sponsor company.
GPS: Global Positioning System.
GPS receiver: To receive GPS data from satellites.
JPEG: compression technique for colour images and photographs that balances compression against loss of detail in the image.
GUI: a User Interface based on Graphics
Longitude: Angular distance on the earth's surface, measured east or west from the prime meridian at Greenwich, England, to the meridian passing through a position, expressed in degrees (or hours), minutes, and seconds.
Latitude: The angular distance north or south of the earth's equator, measured in degrees along a meridian, as on a map or globe.
Altitude: The height of a thing above a reference level, especially above sea level or above the earth's surface.

1.4 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.5 Overview of Document

Section 1 : describes Introduction and Overview of this document.
Section 2 : describes summary of testing results.
Section 3 : describes results from review, walkthroughs, inspections, and audits.
Section 4 : describes detailed results for testing.
Section 5 : describes evaluation of process - evaluation of test cases, results from defect tracker, lessons learned
Section 6 : describes outcome of acceptance test and delivery
Section 7 : describes summary of open issues.
Section 8 : addtional information.

2. Summary of Results

First, we made a connection with GUI and GPS hardware to get the correct GPS data. After connecting with GPS hardware, we tested the capture and drawing line on the images. And we focused on testing the exact distance, longitude, latitude, and altitude values. To calculate those values, we'd used distance from a control object to the camera, and the height of the camera.But the values had big differences between real distance and the measured distance. We changed the way to compute with the field of view of camera. With using the field of view of camera, the difference is now trivial. The values of longitude, latitude, altitude is using a radius of Earth, and the angle between two points, and the distance.Second, we got a GPS data file from sponsor, and needed to make a image based on a the data file. We parsed the date file, picked the GPS values, and tried to draw those values in image box, but still has errors.

3.0 Results from reviews, walkthroughs, inspections, and audits

We've been working for testing, features remaining of the project. The review process performed by a discussion and each team member added features remaining into the project. Whenever it is needed, all the members reviewed the remaining features and discussed. Also, all members reviewed initial versions of the reports for any changes in meeting or by email. The walkthroughs was performed in meeting or by email. All team members managed the inspections. Every team members had discussions for completing the codes, and tested a project with sponsor.

4.0 Results from testing

4.1 Summary of component test

All components were tested on Windows XP. Each component is tested throughly.

4.1.1 Start Button

Test Subject	Start button
Expected Result	Receive GPS data from the satellites
Pass/Fail	Pass

4.1.2 Camera On

Test Subject	Camera On
Expected Result	Start the Camera, feed the image to image box.
Pass/Fail	Pass

4.1.3 Camera Off

Test Subject	Camera Off
Expected Result	Stop the Camera
Pass/Fail	Pass

4.1.4 Capture

Test Subject	Capture
Expected Result	Capture the image from image box, and copy to picture box
Pass/Fail	Pass

4.1.5 Process

Test Subject	Process
Expected Result	1. Process GPS coordinate according to x, y coordinates from the Picture box 2. Calculate correct X, Y distance from the captured image.
Pass/Fail	1. Pass 2. Fail

4.1.6 Clear

Test Subject	Clear
Expected Result	Clear the line in picture box
Pass/Fail	Pass

4.1.7 Draw

Test Subject	Draw
Expected Result	Draw the path based on RDDF file
Pass/Fail	Fail

4.2 Summary of integration test / testing product as a whole

Based on these tests, we are confident that our GUI will meet all of sponsor's needs. All components passed correctly ( except one thing we just started ) with what they are associated with. But one thing about image based on the RDDF file we're going to test more and get some ideas from sponsor, and finish by this weekend.

5.0 Evaluation of the process

5.1 Evaluation of test cases

.

Our test cases are focused on checking our product's accuracy, usability, and functionality. We tested our product according to the guidelines laid out in the VVP. The testing of our product is very important since it will be attached in the vehicle system. Since our test cases are mostly checking the exact values of outputs, there is not much that we would change. We changed our algorithm to calculate the outputs little bit.

5.2 Results from defect tracker

We chose no the utilize the defect tracker. If a team member found defect, the team member sent email to all members to be more appropriate. This allowed for issues to be known immiediatly to all team members.

5.3 Lessons learned

Testing the product was generally somewhat simple but it made us to think more about accuracy of our product and correctness of the product, since we are going to install our product in the vehicle systems. One of the first lessons our team learned in this process is how difficult it is to maintain accurate software. We believed there are probably something to do more for our product during test. So We will make final determination that what we're going to add to the product. And also we will make our product more accuracy and has less difference between our calculated output and the real value.

6. Outcome of acceptance test and delivery

As we mentioned in the VVP acceptance test, first test will be conducted on the basic correctness of the GPS coordinate list. We've done this test already. Some bugs were found during the process of the test. Those problems got fixed immediately. Moving on to the test of the accuracy of the GPS coordinate list. We still have some problems with the accuracy of the GPS coordinate list. We are working on it right now. Accuracy of the GPS coordinate list is really a long term process. We'll get the accuracy level to the point of acceptable for client.  Testing on the vehicle is still in process. Depending on the calculation we use and also the completion of the client vehicle.

7. Summary of open issues

Not Applicable

Change log

Back to cs4500
Back to Home
Back to Top


Maintained by
       Taeho Kim