Guidelines for: Software for Search & Rescue
3rd Year Project--March-June 2001--Charles Twardy
Office hours (63/G09): Tu 4-5, Thur 12:30-1:30
ctwardy@csse.monash.edu.au
www.csse.monash.edu.au/~ctwardy/3yp.php
March 8, 2001

In addition to these guidelines, you should be familiar with the departmental notes on the 3rd-year project available from
www.csse.monash.edu.au/~sid/admin/csc3000.htm
and related web pages which describe the overall guidelines for developing and reporting on any project.

The goal of the project is for students to implement practical software for managing a search for a missing person. The project will be done in 3 stages:

• Software will properly initialize the POA (probability of area) for each area being searched, and properly update the POAs based on new evidence in the form of areas searched (with nothing found), given that the search team had a certain POD (probability of detection). (By Week 3)
• Software will find the best possible allocation of existing resources for the next sortie, given available computing time. ``Best'' means that allocation which minimizes the expected time-to-find (for now, number of sorties). The correctness score will be $1/c$, if $c$ is the factor by which your program exceeds $t_{min}$. The functionality score will be a transform of the run time (must be reported by the program) on the computationally-intensive step, relative to a benchmark.(By Week 7)
• Chosen enhancement: Extend the existing software with 5 points of the following enhancements: provide sound methods for eliciting the initial POA and POD assessments from users (2), incorporate the geometry and topology of the search areas (2), account for clues found (1), account for direction of travel (1), account for subject profile information discovered at any stage of the search (2), incorporate detection and speed characteristics of search teams (2), or provide a GUI interface which at minimum displays an interactive map of the areas with some representation of current POAs (2). Whichever enhancements you undertake, you must work out a specification plan with the user (me), and implement that plan. [I may revise this list somewhat before the specs stage.] (By Week 12)

Grading is based on the final product and writeup. However, I will not approve a specs paper for, nor grade, the final project until you have demonstrably passed the first two stages. The software will be written in C or C++. (If you are committed to doing the GUI extension, and can justify it, you may implement your final project in Java.)

Extra credit: The product is expected to meet the specs agreed to, and to work as documented, and as a real user would expect (i.e., it must be robustly error-tolerant!) Of course, it is to be documented as well. A project which does all of these things well will receive about a 90. Extra functionality including good help text, exceptional error-handling, superior performance, superb documentation, or the like, will help counter deficiencies in other areas, or raise the score up towards 100.

General Functional Requirements

During the first two stages, some of the following will be relaxed. The final program must be able to read resource information in a portable format. I will supply the default resource specs which the program should load upon initialization. The program must allow at least these basic functions: specify number of areas, specify initial POA, view POAs, add-delete-view-modify-load resources, advise resource allocation, specify resource allocation for sortie, update evidence (teams return from sortie). The program should accept as evidence that the subject was found, and report the number of sorties and the person-hours used.

The output should be appropriate. The program should guide the user if extra options are available, such as splitting search areas, adding new search areas, optimizing for different goals, etc.

Implementation

You may code the project from scratch, in which case you will need to propagate the probabilities appropriately. Alternately, you may use the Netica API, for which Monash has a site license, and implement your project as a Decision Net. I think Netica will make the early stages of the project easier, although I have not given much thought to how to do successive updates, particularly incorporating geographic layout of the areas.

Grading

The source is due by noon on Friday, June 1st, 2001, via email to me in a tar archive. The report is due in my box (building 63) at the same time.

Code

The program will be graded on the following criteria (in order of importance): correctness, functionality, internal documentation, modularity and general code quality (including style; you may wish to use theStyle, which may be available from the department, and is currently in the bookstore for $5.00, although probably there for another class(?)).

The source code must be capable of compilation on my Linux box using the gcc or g++ compilers. If your program requires any special options to compile, you must make sure I know its precise requirements in advance. If your code does not compile, you will be given an opportunity to get it to compile if you contact me. It is your responsibility to verify that the source code has compiled properly. So check with me after submitting your program until I tell you it compiled, or ask you to come in and fix a problem. If your program cannot be made to compile, you will receive zero credit for correctness and functionality.

After compiling, I will run the program through several cases of my own design. I will run a standard set of base cases through all programs, and then cases designed to test each project's own specs.

There will be both legal and illegal input: users may specify impossible values, or ask for computations for which they have not supplied enough information, or anything else I can think of, from simple typos to semantic errors. Your program must respond appropriately to any input. Correctness will be assessed according to the accuracy of the updating, and the optimality of the recommended resource allocation. The benchmark on large problems will be a program already used by search managers. The test will involve search scenarios where the subject is present and where the subject is absent. The program will be run until either the subject is found, or until the probability that the subject is not in the search area is $\ge 95\%$. I will inform you by Week 7 exactly what weighting function I will use for the evaluation.

Report

Your project report should conform to the standards laid out in the departmental notes. The report will be graded interms of clarity, accuracy, completeness, grammar, usability, etc. The User Interface section should explain each function, and describe how a user would use the program to manage a small search.

The Theory section should explain how the program works, what it does, and provide a justification for the approach taken. For this section, assume the user knows what a POA and a POD are, but not how to use them to maximize search efficiency.

The Testing section should report the testing you have done on the program. This should provide a short test plan, describing what kinds of tests were developed and used in preparing your program. The results of tests should also be presented in summary form in the report, and with detailed output recording how your program performed in specific tests in an appendix. Your test plan should include both legal and illegal problems. The adequacy and thoroughness of your test plan and its execution will be a significant factor in your grade. Remember that errors you catch and fix will both help you here, and avoid hurting you when I find them!

The Overview section should report on the agreed specifications and state how the program met them, exceeded them or (as a last resort), where it fell short and why. (Falling short will always hurt your grade. Falling short without saying so will hurt more.) You should include the specifications agreement as an appendix.

Demonstration

You will be expected to demonstrate the object code to the class during exam week. Your presentations will be graded and count for 5% of your grade.

Group Organization

The project is designed to be done in groups of 4-6 people. I do not recommend doing it alone, and have been strongly advised by faculty who have worked in industry to require you to work in groups, for your own (future, if not present) good. If you feel that a group will hold you back, I suggest you take up the position of project leader, which carries potential rewards. However, if there are at most one or two individuals who can make a strong case for why they should work alone, I will consider that possibility up until noon, Friday 9 March.

Groups may self organize. They must select a Project Leader, a Tech-writing Leader, and a Testing Leader. The project leader will receive bonus credit if the project does well, and suffer penalty credit if the project goes poorly. Likewise, the testing and tech-writing leaders will receive incentive credit for the quality of their portions of the project. Everyone is expected to contribute to the basic design and development, and testing of their own functions. However, the group may but need not put everyone into both global testing and tech writing.

References

Recommendations for software engineering and reliability testing are available in Glenford J. Myers, Software reliability: principles & practices, and Ian Sommerville, Software Engineering, as well as many other texts.

Information about Search Probability Theory and search planning are available in various works by William Syrotuck and J.R. Frost. Several articles have been published in Response, the journal for the (U.S.) National Association for Search and Rescue. Many links are available from the course website. I will hand out some material in class.

Finally

I will develop more specific requirements for each stage as we go, and give them to you in writing ahead of time in class. I will cover search probability theory and related topics in class. You are encouraged to come see me during office hours, or to schedule an appointment. If my door is open, you may also drop by. By around mid-April, I will probably work at home on Wednesdays. I will endeavor to keep a website for the course up to date with suggestions, references, and the like.

About this document ...

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.49)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -local_icons guidelines.tex

The translation was initiated by Charles Twardy on 2001-03-08