| Exterior Functionality (User point of view) | Engineering - interior (Programmer's point of view) | Adaptability - (Future, plans for maintainability) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C. Hayes | Flexibility of parameters: Check wide range of values for hard-coded parameters such as number of iterations, number of games per iteration, number of players, number of "parts" per game, mutation caps. | Heuristic variance: Check to see that each heuristic function has approximately the same natural variance to ensure understandable weighting. | Validity of Created player: Run many trials with the created player to check for increased ability levels. | |||||||||||||||
| R. Kappiyoor | Running is trying to figure out why the Earth is showing up when some people run our program, but not when other people run it. | Printout of our stats. Then, if we cannot see something, then we can tell right away why we can't see it. It is either too far away, or something in the code messed up, and then we can go back and see what messed up. | Asking other people to look at our code and our documentation and asking them if they think they could take our project and continue to update it and make it better (i.e. maintain it) after we left for college. | |||||||||||||||
| T. Loffredo | Tested collision response and planar math at several points in the code for validity | Checked the amount of time for each frame over time to check average frames/second and for presence of spikes. | Use of object oriented methods/principles of programming. | |||||||||||||||
| M. Murphy | Tested that user could successfully input variables and observe interpretable results. (be more specific?) | Code is clearly labeled and divided into meaningful sections. (examples?) | Code needs to be revised to be scaleable as there is currently no 'classroom' class. | |||||||||||||||
| L. Ouyang | test: | test: | test: | |||||||||||||||
| C. Powell | User testing is done visually (Do the planets orbit the sun believably - also verified with output data). Do input features work - zoom, up, down, left; speed change based on inputs?; planetary point of view change? | Code is clearly divided and commenting of sections; variables declared at beginning, window setup, calculations for planetary positions, camera placement. | The clearly outlined program structure facilitates maintainability | |||||||||||||||
| A. Ravichandran | User data configures the output mechanism (be more specific?) | Debug the data-saving function (more specific) | Program uses an abstraction layer by converting all data to numbers. (more specific) | |||||||||||||||
| A. Smith | test: | test: | test: | |||||||||||||||
| D. Stalcup | Counting frequency of debug pop-up screens based on selected buttons. | Checking to see if data in debug pop-up screens matches correct data. | Counted number of lines required to make a simple subclass. | |||||||||||||||
| D. Tran | Streamlined placement into existing World Bank website template - viewing page source to reveal any errors. Beta testing by other users of the product - evaluate ease of use from observation. | Peer review - coworker/programmer comments on quality of code | Tested ease of adding new statisitical criteria by adding fake statistic | |||||||||||||||
| J. Trent | test: | test: | test: | |||||||||||||||