Project Proposal

The Proposal Document is a detailed description of the suggested solution for the product requested by the Conflict Simulation Laboratory at Lawrence Livermore. The document will be presented to the client at Lawrence Livermore, and after it is reviewed, negotiations for any changes will be conducted. Once the client and the team are mutually satisfied with the document, both parties will sign it.

This signed document will represent a written description of the final working product and a contract by the client and team to deliver it.

1.1 Description of Proposed Project

The proposed project is to design a new tool which, utilizing Lawrence Livermore’s existing Conflict Simulation Laboratory code and simulation terrain map, will determine the optimal path between chosen starting and finishing points on a terrain map. The Conflict Simulation Laboratory’s code reports a weight, or "cost", for movement between any adjacent cells on the terrain map, based upon different criteria. By placing these costs together the optimal path from start to finish can be calculated and displayed to the user.

1.2 Statement of Work to be Done

The following areas require code to be written:

• Reading in and displaying a terrain map
• Graphically selecting a starting and ending point for a proposed route
• Costing Functions provided by the client are 80% completed requiring the following:

• Research will be done to determine an accurate way of conforming all of the functions to one scale to help determine precedence and report step costs
• Add or Delete a Area Costing Function Set
• Clear all costing functions and the start and finish points
• Scaling each cost function to return a comparable value
• Implement a optimal path algorithm based on Dijkstra’s shortest path algorithm
• Display the result of the path graphically on the terrain map
• Output result optionally to a data file

2. Date of Expected Completion

Capstone Design is the Friday of the 3^rd week in April, so we will make our project deadline April 20, 1998 the previous Monday of that week.

3. Proposed Solution

Upon execution, the program will display the following sections: terrain map, costing functions, and program control items. After loading a terrain map, the user must choose the starting point, finishing point, step size, and angle of step. Once the two points are set the user can then choose to adjust the Background Costing Function Set and add new Area Costing Function Sets which will define the rules used to find the optimal path through the terrain. Then the user executes the algorithm to find the optimal path. While the path is being generated, the user will be able to cancel the route generation. When the algorithm has finished, it will display the resulting path on the terrain map. Finally, the user will be able to save the path to a file.

3.1 User Perception

The following is information about each of the sections found in the main window.

• Distance – Distance from current location to destination.
• Time – Time estimated to perform the current move.
• Viewability (Line of Sight) – Measurements amount of viewable terrain.
• General Area Token – Weight based on distance to general token. All other functions will be negated within the radius of this function.
• Concealment – Amount of concealment provided by the terrain
• Terrain Type – Boolean value based on ability to traverse different forms of terrain (roads, cities, etc.).

3.2 Functionality

We have broken up the processes into several categories.

3.3 Algorithm Applied

The algorithm being applied to provide the path from start to finishing points will be a version of Dijkstra’s shortest path algorithm. The steps of our algorithm are:

1. We start out with a set S of which initially only contains the starting node.
2. If a step was taken, and it is to the finishing node then we have found the optimal path and once it is reported, we are done.
3. A request is made for the cost of each step which can be taken from all of the nodes in our set S that do not move to a node that is currently in our set.
4. If there are no step values to choose from then there is no path to the finishing node. We must report that there is no path to the finish point and we are done.
5. From these step values we choose the lowest value as our step and add the node stepped-to to out set S.
6. We must return to step 2 and repeat the loop until steps 2 or 4 are met.

4. Risk Assessment

 

		Impact
		High	Medium	Low
Probability	High	I	II	III
	Medium	IV	V	VI
	Low	VII	VIII	IX

We foresee the following potential risks:

Category I – High Probability, High Impact

• Team annoys system administrator; system administrator deletes accounts
• To mitigate impact, we will be prepared to petition dean to recreate accounts
• Program resource requirements exceed available resources
• Due to potential hardware limitations, user guidelines will be included with finished product, recommending rules of thumb to be used when entering data

Category II – High Probability, Medium Impact

• Miscommunication between client and team
• Frequent communications between client and team, to include email when regular teleconferences or meetings are not working
• Allow client or team to restate their understanding of information provided by other party, to ensure equal understanding of information

Category III – High Probability, Low Impact

Category IV – Medium Probability, High Impact

• Failure of Lawrence Livermore to deliver necessary code
• Watch for delays in promised delivery. Remind contact of importance as needed.
• Prepare design to minimize connectivity with needed code, if code not available during design phase, to lessen code change requirements when code is delivered

Category V – Medium Probability, Medium Impact

• Member of the team does not produce a promised deliverable
• Mitigate possibility, by including frequent reviews of progress on all deliverables
• Keep current copies of all work accessible by all members of group, to allow slack to be picked up as necessary
• Compiler incompatibility between client and school systems
• Include precompiled versions of all code with source code deliverables
• Contact administrators to ensure compatible compilers are installed
• Include all source code, include files, and libraries (where possible) with deliverables

Category VI – Medium Probability, Low Impact

• Code is lost due to unexpected circumstances
• Maintain regular backups of code on multiple systems, to minimize loss
• Livermore has problem with Aasif’s citizenship
• Issue primarily with on site visits. Rest of team able to visit, and keep Aasif informed
• If problem is citizenship in general, see section on losing team member

Category VII – Low Probability, High Impact

• Not finishing project by deadline
• Track progress, and attempt negotiating smaller scale project if team falls too far behind to successfully finish initial project
• Complete individual modules within original project to minimize additional work needed to reach original objectives
• Client quits/moves to another job/gets fired
• Beyond control of team
• Maintain documentation so that any new partner (team member or contact) may be relatively easily brought up to speed with current project status
• Lawrence Livermore stops or freezes CSL project
• Beyond control of team. No mitigation or planning possible
• Team member leaves the team or becomes inactive for long period of time
• Maintain schedule so that workload may be distributed among remaining members
• Scale project so that core aspects of project can be completed with a smaller team

Category VIII – Low Probability, Medium Impact

• Product release date is requested to be pushed up by client
• Scale project to allow completion of core aspects within a shorter time scale, including additional modules to be completed on a time available basis

Category IX – Low Probability, Low Impact