On the Trails with Lewis and Clark

Transcription

1 On the Trails with Lewis and Clark Project Plan Project Team 20 Faculty Advisors Steve Russell/Tom Daniels Team Members Shawn Mahon Anthony Mahieu Shane Paustian Matt Hall September 17, 2004

2 -1- Table of Contents List of Figures 2 List of Tables 3 Abstract 4 Problem Statement 5 Operating Environment 5 Intended Users 5 Assumptions and Limitations 6 Expected End Product 6 Proposed Approach 7 Statement of Work 15 Estimated Resource Requirement 34 Schedule 36 Project Team Information 38 Closing Summary

3 -2- List of Figures 1. Figure 1 A reasonable technical approach 9 2. Figure 2 Gantt Chart 37

4 -3- List of Tables 1. Table 1 Rating system to be used in the project Table 2 Each milestone s importance to the project Table 3 Personnel Effort Requirements Table 4 Other Required Resources Table 5 Original Estimated Project Costs 35

5 -4- Abstract This project will incorporate geographic information system technology, 3-D visualization tools, and actual geographic data to develop an educational tool for use in museum kiosks and educational purposes. The team will develop software that integrates digital elevation data, Lewis and Clark Trail data, satellite photos, and historical documents. On the Trails with Lewis & Clark will allow students to follow the path of Lewis and Clark through realistically rendered fly-throughs of 3-D terrain. It will allow for comparison of historic documents with real measurements and possibly provide a plug-in architecture where modules can be added to allow new interactive learning experiences.

6 -5- Problem Statement General Problem Statement The project is solving several problems at once. The first problem is to capture the history of Lewis & Clark in such a way that it inspires and interests people to learn more. The project should also help preserve the rich history of the area in Idaho. These trails are mostly being covered in overgrowth today, but if hiked the old Native American trails can still be found. The problem is to take the data we have and produce something meaningful and remain true to the past. We will need to assemble and process the information into a three dimensional simulation of the area with elevations, fly-bys, and satellite images. The project must also present historical information through the simulation or web pages to allow for the historical background to be learned. General Solution Approach The team will solve the problem using a combination of resources. Satellite images may be obtained by NASA. These images will give us the textures for our terrain. A three dimensional simulation can be written using C++ and OpenGL. The problem of remaining true to the past can be solved by using the resources available such as the advisor, historical documents, videos, and other relevant data. By producing the end product of a simulation it should help to stimulate renewed interest in the area and be educational at the same time. Operating Environment Since the end-product is a simulation, the operating environment is less critical. However, there are certain aspects in which to consider. If the simulation is run in a museum or in schools it will need to maintain a certain degree of performance and robustness. Meaning if it is running on a museum kiosk for example, it should be stable enough to run for a few hours without problems. Most environment considerations are the same for running any computer. It needs sufficient space to dissipate heat, a good area for using input devices, and a display set up for the needs of its user. Intended Users The projects intended users are primarily average high school students and above. There are no expectations for gender or handicaps. Intended Uses The project is intended to be a historical and educational tool to simulate the Lewis and Clark Trail. It is not intended for young children or a photo-realistic recreation of the scene.

7 -6- Assumptions and Limitations Initial Assumptions List 1. Project will run on a high end graphics card 2. Project will have one user at a time, with possibly many viewing 3. Project will run either full-screen or in a fixed window mode 4. Project will maintain a smooth frame rate >30 frames per second 5. End user will have rights to run the program 6. End user will have access to a web browser 7. End user will have a fast computer (~3Ghz) with enough memory (>512mb) and a graphics card capable of OpenGL Initial Limitations List 1. Project size must be under 8 gigabytes 2. Elevation data resolution limited to about 10m in between every measurement 3. Satellite images may be black & white Expected End Product and Other Deliverables The end product to be delivered is a running and working simulation of the Lewis and Clark trail in Idaho. It will provide a three dimensional fly through of the trail. The simulation will include a way to integrate media in a meaningful way, whether clicking on sections of the simulation and providing a web page, or integrating it directly into the simulation. The end product will allow for adding more media and data to allow for expansion upon the original product.

8 -7- Proposed Approach Functional Requirements 1. Display three-dimensional view of landscape This requires that a 3D landscape be presented to the user of the trail explored by Lewis and Clark. 2. User Friendly Interface This is required because the target audience of the product is going to be for middle school or high school aged children. This audience varies in computer knowledge, and the final product cannot be difficult to learn or it will not be used. 3. Limited Movement by mouse throughout landscape This requires the user to control the view and position in the current area of the trail. This will allow movement throughout the entire application, to all areas of the trail being explored. 4. Smooth Graphics Graphics must be smooth or else the user could experience nausea. Also, for an overall clean and effective product, there should be no or limited skipping of the frames. 5. Clickable areas to induce various actions This requires the introduction of clickable areas within the 3D environment to allow for certain actions. For example, to bring up a web browser at a certain location and present the user with further multimedia content on that area. Constraints Considerations 1. Completed program size limited to 8 GB Due to the large nature of the data being used for the trails, data could quickly accumulate. This constraint will limit the application to no more than 2 DVDs, which is acceptable for such a detailed historical and educational application. 2. Fast computer (3 GHz or faster) With all the data being supplied to the rendering engine and presented to the user, a fast processor is going to be needed. If the processing power is not adequate, the image presented to the user will seem to jump, causing the application to lose any value it has. 3. Fast video card (256 MB, AGP 8x) Heavily detailed landscapes will require a top of the line video card from today s market to prevent frame-skipping. The better the video card, the more detailed and accurate the landscape generation can be. 4. Limiting data resolution Modern technology available to the public cannot process all the data that has been collected, therefore the resolution of data points must be limited to prevent sluggish load times and presentation of data.

9 -8-5. Programming Language The choice in language could limit the overall portability of the final product. If the language is not cross-platform, the product will have a limited audience. Technology Considerations 1. C++ Programming Language A possibility for the programming language to be used in the project is C++. This is a viable choice as OpenGL (a 3D programming extension for C++) would be excellent to do the 3D graphic manipulation. Also, Direct3D would be a viable option for the 3D programming if using C++. This language would also work well for the other parts of the application due to its data handling capabilities. 2. Java Programming Language A possible choice for the core programming language is Java. It would make a good choice due to the portability of the language. A program written in Java will work on multiple operating systems and hardware types. However, a downside to this technology is the lack of native OpenGL or Direct3D support. OpenGL and Direct3D were both designed with C++ in mind. Due to the extreme importance of 3D performance in this project, Java is likely to not be used. 3. OpenGL OpenGL is a graphic extension for C/C++. It has cross-platform capabilities, allowing it to be used on numerous operating systems. It does not require the programmer to interface directly with the video hardware. There are large amounts of documentation for OpenGL available everywhere. 4. Direct3D Direct3D is a graphic extension for C++ by Microsoft. It is not crossplatform and not as popular as OpenGL. There is only limited documentation available for Direct3D. Comparing these technologies, the group is likely to use a combination of C++ and OpenGL. Two of the group members have experience with both of these, making this choice an even better one. The other group members have experience in C++, where as only one member of the group has experience in Java. No member of the group has experience in Direct3D. Technical Approach Considerations In one approach, the overall application is going to involve some form of raw data collected from the historical trails of Lewis and Clark. This data will then need to be run through a process to be converted into useable data. Various pieces of data will need to be handled in this process. This includes satellite imagery, as well as Geographic Information System (GIS) data. Upon the completion of preparing the data, the information will then need to run through the core application logic. In this area, the prepared data will be interpreted and handled appropriately. The core application will

10 -9- need to communicate with the rendering system to create the 3D graphics as well as the graphical user interface (GUI) for interaction with the user. A command language will be used to handle communications among the main application, the rendered, and the GUI. The GUI will involve interaction with a web browser, allowing for various multimedia types to be deployed. This approach is shown in Figure 1. Another possible approach is the processing of data on-the-fly. In this methodology, the data will not be prepared up-front, but will be prepared as the current scene being displayed to the end user requires it. The use of this method is rather unlikely due to the high volume of data and extreme processing power required to perform just a task. Figure 1 A reasonable technical approach The main criteria for selecting an approach includes ease of implementation, as well as processing time and speed requirements. The implementation must not be overly complex due to the already complex nature of the individual design elements. Furthermore, a simpler design allows for more concentration on other areas and easier expansion in the future. The processing time and speed are of importance because this design must run quickly on a top of the line computer of today. Large amounts of data are going to be handled, and a slow implementation would remove all significance from the project. No user will want a slow product, which slow design elements will reflect.

11 -10- Testing Requirements Considerations The testing for this project will be mainly modular. Various components will be thoroughly tested before being migrated into the whole. For example, the data processing must be completely valid before being integrated into the core application, or else problems may arise that cannot be repaired. In terms of the data processing, equivalency class partitioning will be used, as this form of testing is most applicable to a situation of this type. For the rendering and graphical programming portion, a set of test cases will have to be created and tested thoroughly for each object type. Another set of cases will have to be developed when these objects are thrown together using the data collected and processed. Here, interface testing will be used to assure that all components interface with one another appropriately. Acceptance criteria will vary depending upon the element being tested. For data processing, all tests must pass. It must be absolutely certain that the data being fed into the core application is valid; therefore, there is no room for error. For the graphical portion of testing, objects must appear to interact appropriately. There is slight room for error. Some objects may be clipped, and due to the large amount of data, some of the landscape will be greatly reduced. A lower resolution is used in the final product than what is given in the data. This may cause some slight variances in appearance which must be dealt with. Security Considerations There are few security considerations to be taken into account in this project. The end product is for educational purposes, and therefore it is meant to be shared with the world. The end product will not have any security concerns. The data collected is property of Professor Russell of Iowa State University. If he is to decide that the data should be concealed from the end user, this will be accomplished. This could be handled easily by presenting the end product with only the processed data, and not the original collected data. The processed data will be scaled down for processing efficiency, thereby rendering it rather useless compared to the original data. Another possible security consideration is the possibility of satellite images in the product coming from NASA. As a government agency, NASA may request that these images not be made publicly available. This could be solved using some type of encryption on the data. Safety Considerations There is one main safety concern to be addressed. This application will be run on a monitor of some sort using three dimensional graphics. Although it is rare, some people cannot handle 3D graphical environments and may become nauseous. If this begins to occur, the user should immediately stop using the program. This safety issue can be addressed by presenting a warning upon the execution of the application.

12 -11- Intellectual Property Considerations The application will likely be released under an open source license. The project is educational in nature, and therefore expansion and use of it is thoroughly encouraged. Currently, the project will be considered intellectual property of the project advisors and the project group members. Commercialization Considerations This product is not to be used for profit. Variations of the product can be used by the group members for profit as they see fit. The product is not to be sold to an external entity. Possible Risks and Risk Management Numerous risks exist in a project of this sort. One such risk is losing a group member. The group is going to be split into sub groups of 2. There will be the graphical research and design group, and the documentation and general coding group. With multiple members in each group, if one group member is to leave, the other member in that sub-group will know what the parting member knew and was working on. Also, if a new member is added to the group, there will be a source to teach the new member what he or she needs to know about the project. Another risk involved in this project is the chance of coming to a point where the group lacks the expertise to perform a certain technological task. In this case, the group has various sources to look to for assistance. This is especially useful in terms of the 3D graphics, where Professor Sannier, a professor in computer graphics and modeling, has elected to assist the group in times of need. When requiring assistance with the data interpretation, Professor Russell will be an excellent resource due to his experience with the data. He was the primary collector of the data to be used. Project Evaluation Criteria and Proposed Milestones There will be several milestones for the project. Each milestone will be given a rating based upon Table 1 shown below. A milestone is considered successful if it expectations are met; therefore, a rating of 6 or higher would be considered successful. An unsuccessful milestone would be rated 4 or lower. If no attempt is made, this may or may not be a success, depending upon whether the milestone is intended for eventual implementation and was needed at the time of rating.

13 -12- Rating Basis Rating Expectations Greatly Exceeded 10 Expectations Exceeded 8 Expectations Met 6 Expectations Nearly Met 4 Expectations Not Met At All 2 No Attempt Was Made 0 Table 1 Rating system to be used in the project The following is the list of milestones for this project. This design is going to be based on a bottom-up architecture style. The milestones are arranged in a modular basis. Each module will be built separately, and then integration will be done once all modules are completed. Milestones 1. Data Processing and Formatting In this milestone, the expectations include reading in all raw data (GIS, satellite images, and any other raw data to be needed for 3D map generation) and processing this data into easy-to-use data structures for the application core. Any excess data will be discarded and never seen by the core application. 2. Command Language In this milestone, the expectations include creating a general, non-specific method of communication for use between the rendered, the application core, and the GUI. It is required that the language handle passing of data between all three sub-systems. It must act as an upper layer of the entire application, allowing for future expansion and simple use of the complete engine (application). 3. Rendering Engine In this milestone, an engine that accepts commands from the command language module will use the data it was given and perform the actions specified by the commands. These actions include those from both the core application and the GUI. The engine should create visuals based upon data supplied by the command language module. 4. Graphical User Interface This milestone will be a complete success if a GUI is available to be presented to the user. Events caused by the user will be passed back to the command language, where the events will be handled appropriately. The key importance of the GUI is to allow for user interaction with the program. Also, integration of a web browser or other multimedia software interface would go above and beyond the requirements. This interface, if implemented, should be executable in two different forms. The

14 -13- first method to execute the multimedia interface should be accessible through a menu or similar selection system presented to the user. The second executable method for the multimedia interface should be in the form of a command received from the command language. This will be used to allow for the use of multimedia to appear when certain areas are reached in the 3D realm. 5. Application Core In this milestone, success will depend upon the creation of an application core. The core must receive data that was processed in the Data Processing and Formatting module. It can be assumed that the data is accurate. The core will hold this data until it is requested by the upper-level command language, which receives this request from the Rendering Engine. Therefore, the core must also allow for the sending of data to the upper-level. 6. Application Integration I In this milestone, the integration of the Data Processing and Formatting module, the Application Core module, and the Command Language module must be complete. All communication must be valid and all functions must work properly for complete success. Data should be capable of flowing from a raw state, to a processed state where it can be accessed from the application core via the command language. It is critical that this integration is fully tested for correctness. 7. Application Integration II In this milestone, the integration from Application Integration I is furthered by adding the GUI module. The GUI is now added as it is necessary for the rendering to be displayed to the user, and for the user to communicate with the application. If all user interaction works properly and the command language can interface with the GUI properly, this milestone will be considered a success. 8. Final Application - In this milestone, the Rendering Engine module is integrated with the modules from Application Integration II. The Rendering Engine must properly accept data from both the GUI and the Application Core via the Command Language module. If all communication works properly, the application will be complete, and with the integration of the Rendering Engine module properly with all other modules, this milestone is successful. Each module has a certain amount of importance to the project. The percentage of each module with respect to how critical it is to success in the project is shown in Table 2 below. Based upon the scale given earlier, complete success in the project would require a cumulative score in the range of Anything greater than 48 would exceed the expectations.

15 -14- Milestone Percentage of Total Data Processing and Formatting 10% Command Language 10% Rendering Engine 20% Graphical User Interface 5% Application Core 15% Application Integration I 20% Application Integration II 10% Final Application 10% Table 2 Each milestone s importance to the project Project Tracking Procedures The group will use Microsoft Project to track project progress. A Gantt chart will be created, including project deliverables. The project leader will assure the group follows this schedule and completes the necessary activities on time. Project progress will be assessed each week during group weekly meetings in which all members must be present. Upon completion of major tasks, a group website will be updated to reflect the progress.

16 -15- Statement of Work Task No. 1 - Problem Definition Task Objective: To obtain a sound understanding of the basis for the project. Task Approach: The project team shall talk with the client and advisors of the project on what functionality the project should have. The project team shall find what is vital to the End Product. Also, by looking at the available input data, the constraints, the End-Users and End-Uses, as well as current research, the project team shall find what functionality is possible to implement and what may have to be left for further expansion later. Task Expected Results: The Resulting information shall present the project team with a scope of the project and potential problem areas. Subtask No. 1a - Problem Definition Completion Task Objective: To obtain a sound understanding of the basis for the project. Task Approach: The project team shall gather information from the client about what the client s problem is and what functionality the Client seeks to obtain from the End Product. Using this information with information from Project Advisors and research, the project team shall figure what potential problems will/may arise and what functionality is possible or may have to be left for further expansion later. Task Expected Results: The Resulting information shall present the project team with a scope of the project and potential problem areas. Subtask No. 1b - End-Users and End-Uses Identification Task Objective: To understand what level of computer literacy the end-users will have and how comprehensive to make the end product s functionality. Task Approach: The project team shall gather information from the client as to who the target customer or audience is for the end product. Also, the project team will gather information from potential end-users to find what would appeal to them in the project, either by similarities found in other products already available or via surveys.

17 -16- Task Expected Results: The project team shall have an understanding of what usability issues must be addressed and how the functionality will be best available in the end product. Subtask No. 1c - Constraint Identification Task Objective: To understand what functionality is possible. Task Approach: The project team will consult the client to find out what platforms or environments the end product must run on. Also, the project team shall analyze the available resources to figure out what resources will constrain certain functionality of the end product. Task Expected Results: The project team will understand what functionality to work towards and how complex the problem really is. Task No. 2 - Technology Considerations and Selection Task Objective: To find possible technologies that will help in the implementation of the end product and select the best of these technologies for solving the given problem within project constraints. Task Approach: The project team shall first research different approaches to solving the defined problem. Using the information researched, the team will find technologies that will help in the implementation of these different approaches and decide upon what approaches and technologies will best fit the project and its constraints. Task Expected Results: The project team will have an idea of the direction in which to go to solve the defined problem. Subtask No. 2a - Identification of Possible Technologies Task Objective: Research different technologies that will help in the implementation of the end product. Task Approach: The project team will look into similar products already created to get an idea of what technologies have already been used on a similar problem. Also, the project team will look into technologies that deal with different functionalities and/or components of the end product to be considered for different solutions that fit the constraints.

18 -17- Task Expected Results: The project team will gain an idea of what different means there are for implementing the end product. Subtask No. 2b - Identification of Selection Criteria Task Objective: To understand what is needed in the technologies researched to be used to implement the end product. Task Approach: The project team will analyze the constraints and needed functionality of the end product to figure needed constrains in the technology criterion. Also, the research team will analyze different technologies against their cost and/or availability for the end product. Task Expected Results: The project team will have an understanding of what to look for when researching different technologies. Subtask No. 2c - Technology Research Task Objective: To find technology that most effectively helps in the implementation of the end product and is acceptable to the client. Task Approach: The project team will search for different available technologies for use in obtaining the functionalities desired, and that will help implement the different components of the end product. These technologies will be different technologies currently in use on similar problems as the one defined to be solved, or technologies used on problems that are similar to the different functionality requirements of the end product. Task Expected Results: The research will yield technologies that are available and suit the need of the client while best helping in the implementation of the end product. Subtask No. 2d - Technology Selection Task Objective: To select, from researched technologies, the most effective and available technologies that will best implement the end product within the constraints and limitations. Task Approach: Project team will analyze the different technologies, as well as different possible solutions to the given problem. Then after careful analysis the project team will select

19 -18- Task No. 3 - End-Product Design the best solution along with the most appropriate technologies that go with the solution for the client and the end product. Task Expected Results: The project team shall have a direction, and will have defined technologies for following said direction in implementing the end product for the client. Task Objective: To create a well thought out plan as to how to implement the end product for the client. Task Approach: The project team shall analyze a solution, given the constraints and limitations of the project and known technologies, to use for the project and best solve the given problem. The team shall consider what different risks may be involved, potential problem areas, and what possible achievements must be made before certain aspects of the end-product implementation can be started. The project team will identify different required components and the different parts of these components to create a plan of implementation for the end product. Also, the project team shall come up with different use cases and possible error handling procedures. Task Expected Results: The project team will have a descriptive plan of how and what to implement for the end product. Subtask No. 3a - Identification of Design Requirements Task Objective: To understand what must be done and how each component must be accomplished in the implementation of the end product. Task Approach: Project team shall analyze the different constrains, limitations, needed functionality, and wanted functionality to figure what will be required for the end-product. Then the project team shall come up with different components required for the implementation of the end product. The project team shall then analyze the technologies used and figure system or environment requirements, as well as assumptions about users. While doing this the project team will have to analyze different possible use cases in order to detect any possible hazards that may arise in the products use and come up with ways of handling these errors. Task Expected Results: The project team will have a clear understanding of what will be required for the implementation of the end product.

20 -19- Subtask No. 3b - Design Process Task Objective: The project team will gain an intimate knowledge of what the end product should turn out to be and how to achieve this. Task Approach: The project team will analyze the design requirements and figure what different methods, components, inputs, and outputs the team must consider, implement, or obtain in the implementation of the end product. Analyzing this information the design team will come up with a defined plan as to what components will achieve certain goals as well as to how many components there are, what will make up each component, and how they will work together to form the end product. Task Expected Results: This design will provide a defined plan of action for the project team and allow them to understand how far along they are in implementing the project as well as, give a direction for implementing the project. Subtask No. 3c - Documentation of Design Task Objective: To give the project team a reference as to the planned implementation of the end product and the direction of the project as a whole. Task Approach: The project team shall create a requirements document in order to document the Design requirements for future reference when designing or changing the project design. Then the project team shall create a Design document to use as a guide in implementing the end product. These documents include, but are not excluded to the Requirements document and the Design document. The Requirements document and Design document may be updated anytime during the project if additional constrains, limitations, or needed functionality should be found. In this case, either the Design document or both documents must be analyzed and updated to fit new implementation plans. Task Expected Results: The project team will have a definite reference to the plan of implementation of the end product. Task No. 4 - End-Product Prototype Implementation

21 -20- Task Objective: To obtain a working model of the end product for evaluation by the client and project advisors. Task Approach: Using and incorporating found technologies; the project team will use the Design document to implement the Prototype. If problems or additional constraints should arise, the team will reference the Requirements and Design documents and make any needed adjustments while implementing the prototype using other means, such as adding new components, using different researched technologies, or changing existing components to fix the problem. Task Expected Results: The project team will have created a working prototype of the core solution to the defined problem for the end product. Subtask No. 4a - Identification of Prototype Limitations and Substitutions Task Objective: Make sure to incorporate the core requirements of the project and what must yet be done in order to obtain a finished end product. Task Approach: The project team shall review the Requirements document to find what core functionality must be incorporated and what limitations or constraints cannot be ignored in the prototype. Also the project team shall review the Design document for additional functionality or constraints that may be ignored, substituted for or changed in order to produce a prototype for the client to test and evaluate. Task Expected Results: The project team will have an understanding of what crucial components and functionality must be worked out without fail, and what constraints or functionality components may be added later if the client wished to keep them and not make a change. Subtask No. 4b - Implementation of Prototype End-Product Task Objective: To allow the client and advisors to evaluate the implementation and design of the end product. Task Approach: The project team will work on implementing the prototype from the Design document with the core requirements in mind. If there are any problems the team will have to review the Requirements and Design documents for any discrepancies with implementation, or to update the documents with new constraints and/or implementation plans. During the implementation, the

22 -21- project team must make sure the core requirements are met, but may substitute, or ignore certain functionality or constraints that can be added later. Task Expected Results: The project team shall have implemented a working prototype for review by the client and project advisors so that further modifications can be made if required to Requirements, Designs, and Implementation plans. Task No. 5 - End-Product Prototype Testing Task Objective: To ensure that the prototype works properly for client and project advisor evaluations of the project. Task Approach: Using the use cases developed in the Requirements document the project team shall decide upon test input and evaluate the results. Reiterating the test cases several times with unique inputs to find and correct any errors, the team will fix the Prototype to a certain degree, for it to be presentable to the client for evaluation. Task Expected Results: The project team will discover and correct any essential errors in the prototype. Subtask No. 5a - Test Planning Task Objective: To create a direction in finding possible problems in the prototype. Task Approach: The project team shall analyze the different uses and their inputs, as well as, what the different inputs should output. The team shall then analyze what to do should an error or problem occur and test the prototype for these errors and what is output as a result. Task Expected Results: The project team will have base test cases for the testing of the prototype and it s components. Subtask No. 5b - Test Development Task Objective: To create the tests of the prototype for execution. Task Approach: The project team will have to analyze how to test the prototype and its components, either by input data, error generation, or direct interaction with the prototype. The project team will then have to decide upon methods of how to implement said tests. Also, the project team will have to devise tests for each

23 -22- component of the prototype, so as to find where specific errors may lie. Task Expected Results: The project team will have a set of tests to run through the prototype to make sure everything is working correctly, or find what needs to be fixed. Subtask No. 5c - Test Execution Task Objective: Find any errors the in the prototype and/or its components. Task Approach: The project team shall run each test developed on both prototype as a whole and on each component, as applies. The tests shall then be repeated several times with different unique inputs to search for any errors that could occur. Task Expected Results: The project team will find any errors in the prototype that are needed to be fixed before client, advisor evaluation. Subtask No. 5d - Test Evaluation Task Objective: To decide if the prototype can and should be fixed for any found error before client, advisor evaluation. Task Approach: The project team shall review all test outcomes and evaluate the severity of the error before deciding to fix the error. If deciding to fix the error the team will find and change the required component or components of the prototype, otherwise the team may decided to ignore or substitute for the given error prone component or use case. Task Expected Results: The project team shall know of errors in the components and will fix the prototype for client, advisor evaluation as well as have knowledge of future trouble areas in the project. Subtask No. 5e - Documentation of Testing Task Objective: create a record of fixed or unchanged error states within the prototype. Task Approach: The project team shall take note of all errors found from each test and what component may have caused said

24 -23- error. The project team will then document all of these errors and review both the Requirements and Design document. Here the team will make notes and needed changes for future implementation. Task Expected Results: The project team will have an idea of what errors to look for and/or fix when implementing the end product. Task No. 6 - End-Product Prototype Demonstration Task Objective: To understand what the client envisions as compared to what the project team envisions for the end product. Task Approach: The project team will review what functionality is demonstrated in the prototype. Also, the team will review what constrains and limitations were not strictly adhered to. Then the project team will practice going over all of the features incorporated into the prototype and what features are lacking but how they will look on the final product. Also, the team will plan on a suitable time and place for all team members, project advisors, and the client for the Demonstration. Task Expected Results: Increased understanding for both the team and the client as to what the finished product will and should be like. Subtask No. 6a - Demonstration Planning Task Objective: For the project team to be ready to demonstrate the prototype in a professional manner. Task Approach: The project team shall consider time and location of the demonstration. The project team shall review the prototype as compared to the requirements and requested functionality. The project team will rehearse with each other in order for all members to be well informed. The project team will designate a dress code for team members. Task Expected Results: The project team shall be able to demonstrate and inform the client in a professional manner. Subtask No. 6b - Faculty Advisors and Client Demonstration Task Objective: To allow the Advisors and Client to evaluate the current project direction, and obtain better-informed input as to what is wanted for the end product.

25 -24- Task No. 7 - End Product Redesign Task Approach: The project team shall have all members meet with the project advisor and client together in an appropriate place at a convenient time allowing for the demonstration to run long. The project team will demonstrate the different working aspects of the prototype and explain functionality requests or requirements left out of the prototype. The project team will then answer any questions the advisors or client may have and document any needed changes or concerns. Task Expected Results: The project team shall have a greater knowledge of what the client wants in the end product, and what changes may need to be made to accommodate them. Task Objective: To create a definite plan for the design of the end product. Task Approach: The project team will review any changes that need to be made for the client, from the prototype, and incorporate them into the Requirements and Design documents. The project team will then review the Test Evaluations and re-evaluate the Design document and the components in order to get past the errors or incorporate ignored components. Task Expected Results: The project team will have more concise, betterconstructed plans for the end product. Subtask No. 7a - Evaluation of Requirements Task Objective: To update the Requirements to better fit the end product. Task Approach: The project team will incorporate any changes that the client wanted that may not have been in the design or in the Requirements Document, if necessary. Then the team will look over the Test Evaluation to see if there are any additional constrains or required changes for the project and update the Requirements document. Task Expected Results: The project team will have definitive requirements and better knowledge of project constrictions and limitations. Subtask No. 7b - Redesign Process Task Objective: To update the Design of the Prototype to fit the end product.

26 -25- Task Approach: The project team will analyze any changes required by the client and piece them into the design. Then the project team will look again at the Test Evaluation and any changed requirements in the Requirements document to find what additional changes may need to be done to the design to accommodate these errors and new requirements in the project. Task Expected Results: The project team will once again have a defined plan and direction for the implementation of the end product. Subtask No. 7c - Documentation of Design Task Objective: To create reference for the implementation of the project. Task Approach: The project team will make any necessary changes required by the client to the Requirements document. Then the project team will review the Requirements document and Error evaluation to update and change the Design document for further reference. Task Expected Results: The project team will have a reference for implementation of the end-product. Task No. 8 - End-Product Implementation Task Objective: To create a working product that meets client specifications. Task Approach: The project team will decide whether to use the prototype in the of the end product or to scrap it and begin implementing from the beginning. The project team will then follow the Design document to creating each component and integrating them into the end product. Task Expected Results: The project team shall have created a product that meets client specifications. Subtask No. 8a - Identification of Limitations Task Objective: To understand and adhere to the Limitation and constrictions of the project. Task Approach: The project team shall review the requirements document for all constraints and limitations that the project must

27 -26- adhere to. The project team will also identify any limitation or constraints that lie in the end product, either for the client or the user during the course of the implementation. Task Expected Results: The project team shall have a definite understanding of what limitations and constrictions the product must adhere to, as well as, find what limitations and constrictions are inevitable for the client/user. Subtask No. 8b - Implementation of End Product Task No. 9 - End-Product Testing Task Objective: To create a working product that meets client specifications. Task Approach: The project team will decide whether to use the prototype in the implementation of the end product or to scrap it and begin implementing from the beginning. The project team will then follow the Design document to creating each component and integrating them into the end product. Task Expected Results: The project team shall have created a product that meets client specifications. Task Objective: To ensure that the end product works properly for client specifications. Task Approach: Using the use cases developed in the Requirements document the project team shall decide upon test input and evaluates the results. Reiterating the test cases several times with unique inputs to find and correct any errors, the team will fix the end product to be presentable to the client for evaluation. Also, the project team shall incorporate test cases found to cause problems in testing the prototype. Task Expected Results: The project team will discover and correct any errors in the end product essential to the client specifications. Subtask No. 9a - Test Planning Task Objective: To create a direction in finding possible problems in the end product. Task Approach: The project team shall analyze the different uses and their inputs, as well as, what the different inputs should output.

28 -27- The team shall then analyze what to do should an error or problem occur and test the end product for these errors and what the output is as a result. Task Expected Results: The project team will have base test cases for the testing of the end-product. Subtask No. 9b - Test Development Task Objective: To create the tests for the end product, for execution. Task Approach: The project team will have to analyze how to test the code, either by input data, error generation, or direct interaction with the end product. The project team will then have decided upon methods of how to implement said tests. Also, the project team will have to devise tests for each component of the end product, so as to find where specific errors may lie. Task Expected Results: The project team will have a set of tests to run through the prototype to make sure everything is working correctly, or find what needs to be fixed. Subtask No. 9c - Test Execution Task Objective: To find any errors the in the end-product and/or its components. Task Approach: The project team shall run each test on both the end product as a whole and on each component. The tests shall be repeated several times with different unique inputs to search for any errors. Task Expected Results: The project team will find any errors in the end product for evaluation. Subtask No. 9d - Test Evaluation Task Objective: To decide if the end product can and should be fixed for any found error, or to replace an existing component to fix the error. Task Approach: The project team shall review all test outcomes and evaluate the severity of the error before deciding to fix the error. If deciding to fix the component where the error occurs the team will have to make appropriate changes to the component.

29 -28- Otherwise, if it is decided to replace the error prone component a new component will have to be implemented and integrated into the end product. Task Expected Results: The project team shall know of errors in the components and will fix the end product to fit client specifications. Subtask No. 9e - Documentation of Testing Task Objective: To create a record of persistent errors that occurred in the end product. Task Approach: The project team shall take note of all errors found from each test and what component or components may have caused said error. The project team will then document all of these errors and review both the Requirements and Design document. Also, the project team will document how any errors were fixed for future maintenance or expansion reference. Task Expected Results: The noted errors and changes shall make a reference to help in future maintenance, handling, or expansion of the end product. Task No End-Product Documentation Task Objective: To provide a reference for end-users and the client of the end product. Task Approach: The project team will take the Requirements and Design documents and include needed information for maintenance and support of the end product in a document. Also the project team will include information on found errors and how they were fixed in the maintenance document for future reference. Lastly the project team will document limitations and constrains that the end-user may need to know before using the end product. Task Expected Results: Professional and informative documents for the Maintenance and support of the end product. Subtask No. 10a - Development of End-User Documentation Task Objective: To create a comprehensive document that the end-user can understand, instructing them on the use and constrains of the end product.

30 -29- Task Approach: The project team will review the Requirements and Design documents and compile and pertinent information that he end-user will need to know. Also, the project team shall go through the end product and document basic uses from the use case scenarios, to help the user become familiar with the end product. Task Expected Results: The project team shall create a comprehensive document that the end-user may utilize to become familiar with the end product. Subtask No. 10b - Development of Maintenance and Support Documentation Task Objective: To create a comprehensive document from the Requirements and Design documents, as well as the Test Evaluations. Task Approach: The project team will compile a document of all pertinent data, from previous documentation, for use in maintenance and support. The project team will include such items as limitations and constrictions of the end product, Design of components and their integration, and errors found and how the project team fixed them. Also, the project team will have to include use cases that technical support may use to help endusers and work around errors that may occur. Task Expected Results: The project team will have created a detailed comprehensive document representing how the project was implemented, where components are, what common errors occurred, and all limitations and constrictions of the end product. Task No End-Product Demonstration Task Objective: To demonstrate the end product for client and industrial approval. Task Approach: The project team will review the functionality of the end product. Then the project team will practice going over all of the features of the end product. Also, the team will plan on a suitable time and place for all team members, project advisors, and the client for the Demonstration, as well as an appropriate dress code for team members. Task Expected Results: Acceptance of the end product by the client and industry.