seniord.ece.iastate.eduseniord.ece.iastate.edu/projects/archive/ongo08/... · Web viewAPI...

Table of Contents1 Introductory Material...................................................................................................7

1.1 Executive Summary.............................................................................................71.1.1 Need for the Project.....................................................................................71.1.2 Project Description......................................................................................91.1.3 Results to Date...........................................................................................111.1.4 Accomplishments during the Spring 2007 Semester.................................121.1.5 Work yet to be Completed.........................................................................13

1.2 Acknowledgement.............................................................................................141.3 Problem Statement.............................................................................................14

1.3.1 General Problem Statement.......................................................................141.3.2 General Solution Approach.......................................................................14

1.4 Operating Environment.....................................................................................151.5 Intended Users and Uses....................................................................................15

1.5.1 Intended Users...........................................................................................151.5.2 Intended Uses.............................................................................................15

1.6 Assumptions and Limitations............................................................................161.6.1 Assumptions..............................................................................................161.6.2 Limitations.................................................................................................17

1.7 Expected End Product Description....................................................................172 Project Accomplishments and Current Status...........................................................21

2.1 Previous Accomplishments...............................................................................212.1.1 Overall.......................................................................................................212.1.2 MTSS.........................................................................................................212.1.3 GW and USA.............................................................................................252.1.4 SASF..........................................................................................................38

2.2 Present Accomplishments..................................................................................492.2.1 Overall.......................................................................................................492.2.2 MTSS.........................................................................................................542.2.3 GW and USA.............................................................................................542.2.4 SASF..........................................................................................................55

2.3 Future Required Activities.................................................................................562.3.1 All Future Semesters..................................................................................572.3.2 Fall 2007....................................................................................................582.3.3 Spring 2008................................................................................................582.3.4 Fall 2008....................................................................................................58

2.3 Current Project and End-Product Status............................................................582.4 Recommendations for Continued Work............................................................59

3 Documentation of Current Efforts and Results.........................................................603.1 Project Definition Activities..............................................................................60

3.1.1 Overall Team.............................................................................................603.1.2 MTSS.........................................................................................................603.1.3 GW/USA....................................................................................................613.1.4 SASF..........................................................................................................61

3.2 Research Activities............................................................................................61

i

3.2.1 Overall Team.............................................................................................613.2.2 MTSS.........................................................................................................613.2.3 GW/USA....................................................................................................613.2.4 SASF..........................................................................................................61

3.3 Design Activities...............................................................................................623.3.1 Overall Team.............................................................................................623.3.2 MTSS.........................................................................................................623.3.3 GW/USA....................................................................................................623.3.4 SASF..........................................................................................................62

3.4 Implementation Activities.................................................................................633.4.1 Overall Team.............................................................................................633.4.2 MTSS.........................................................................................................633.4.3 GW/USA....................................................................................................633.4.4 SASF..........................................................................................................64

3.5 Testing and Modification Activities..................................................................643.5.1 Overall Team.............................................................................................643.5.2 MTSS.........................................................................................................643.5.3 GW/USA....................................................................................................643.5.4 SASF..........................................................................................................65

4 Resources and Schedules...........................................................................................654.1 Resource Requirements.....................................................................................65

4.1.1 Personnel Efforts.......................................................................................654.1.2 Other Resource Requirements...................................................................674.1.3 Financial Requirements.............................................................................68

4.2 Schedules...........................................................................................................724.2.1 Project Schedules.......................................................................................724.2.2 Deliverable Schedule.................................................................................73

5 Closing Materials.......................................................................................................745.1 Lessons Learned................................................................................................745.2 Risks and Risk Management.............................................................................75

5.2.1 Anticipated Risks.......................................................................................755.2.2 Anticipated Risks Encountered..................................................................765.2.3 Unanticipated Risks Encountered..............................................................765.2.4 Changes in Risk Management...................................................................76

5.3 Project Team Information..................................................................................775.3.1 Client..........................................................................................................775.3.2 Faculty Advisors........................................................................................775.3.3 CprE/EE 492 Team Members....................................................................785.3.4 CprE/EE 491 Team Members....................................................................79

5.4 Closing Summary..............................................................................................795.5 References..........................................................................................................805.6 Appendices........................................................................................................80

5.6.1 Appendix A: Problems Identified..............................................................805.6.2 Appendix B: Feature List...........................................................................865.6.3 Appendix C: Accessing the Project...........................................................895.6.4 Appendix D: Project Evaluation................................................................90

ii

5.6.5 Appendix E: Subteam Test Plans..............................................................915.6.6 Appendix F: Problem Solving Algorithm Definition..............................1115.6.7 Appendix G: Grade Book Design............................................................114

iii

List of Figures

Figure 1 – MTSS Home Page............................................................................................18Figure 2 – Globey’s World Home Page............................................................................19Figure 3 – Uncle Sam’s America Home Page...................................................................19Figure 4 – Globey’s World Prototype...............................................................................26Figure 5 – Globey’s World Web Application, in PHP and MySQL.................................26Figure 6 – Globey’s New Look.........................................................................................27Figure 7 – Prototype of New Country Comparison Page..................................................28Figure 8 – New Country Comparison Page.......................................................................29Figure 9 – Old Country Comparison Page........................................................................29Figure 10 – Screenshot of Globey’s World Homepage.....................................................31Figure 11 – Globey’s World Region Page.........................................................................31Figure 12 – Single Sign-on Page for Ongo08....................................................................32Figure 13 – Quizzing Front Page for Ongo08...................................................................32Figure 14 – Initial USA Navigational Map.......................................................................34Figure 15 – New USA First Screen with Updated Map....................................................35Figure 16 – Comparison tool in the USA Application......................................................35Figure 17 – Blank US Map Used for Game Implementation............................................36Figure 18 – Class Diagram................................................................................................40Figure 19 – Library File Diagram......................................................................................41Figure 20 – Quizzing Tables Diagram...............................................................................43Figure 21 – Overall Tables Diagram.................................................................................47Figure 22 – Problem Solving Algorithm Diagram..........................................................111Figure 23 – Grade Book Diagram...................................................................................115

iv

List of Tables

Table 1 – Spring 2004 Functionality List..........................................................................42Table 2 – Fall 2004 Functionality List..............................................................................43Table 3 – Spring 2005 Functionality List..........................................................................45Table 4 – Fall 2005 Functionality List..............................................................................48Table 5 - Estimated Hours for Project...............................................................................66Table 6 – Actual Hours for Project....................................................................................66Table 7 – Previous Hours for Project................................................................................67Table 8 – Estimated Resource Costs.................................................................................67Table 9 – Actual Resource Costs.......................................................................................68Table 10 – Estimated Project Expenses.............................................................................69Table 11 – Actual Cost of Project......................................................................................70Table 12– Previous Semester Financial Requirements.....................................................71Table 13 – Proposed Project Schedule..............................................................................72Table 14 – Actual Project Schedule...................................................................................73Table 15 – Schedule of Deliverables.................................................................................73Table 16 – Problems Identified..........................................................................................80Table 17 – Feature List.....................................................................................................86Table 18 – MTSS Requested Features...............................................................................87Table 19 – GW Requested Features..................................................................................88Table 20 – USA Requested Features.................................................................................88Table 21 – Overall Team Evaluation.................................................................................90Table 22 – MTSS Evaluation............................................................................................90Table 23 – GW/USA Evaluation.......................................................................................91Table 24 – SASF Evaluation.............................................................................................91Table 25 – Login Information..........................................................................................107

v

List of Definitions

ACSD Ames Community School District

Apache A software product that serves web pages to clients requesting them. Apache can be used in conjunction with PHP in order to produce dynamic web pages that are built and delivered to the requesting client on the fly.

API Application Programming Interface – A redefined set of interfaces to a software model

ASP Active Server Pages – A Microsoft created language used to generate dynamic web pages.

C&I Curriculum and Instruction – An academic department of Iowa State University.

CVS Concurrent Version System – Provides control in keeping only one current version of the software as changes are made by all team members.

GW Globey’s World – An application inside the K-12 Teaching Application Software that teaches world geography.

LAMP Linux, Apache, MySQL, PHP – Defines the architecture that runs Globey’s World. Refers to the operating system, server type, and programming language used to maintain Globey’s World.

MTSS Mathematical Teaching Software System – An application inside the K-12 Teaching Application Software that teaches mathematic problem solving.

MySQL An open-source implementation of an SQL server.

PHP Recursive acronym for PHP: Hypertext Preprocessor – A computer language that enables Apache web server to dynamically generate HTML documents.

PSA Problem solving algorithm

SASF Software Application Support Framework – provides standard functions for use by the educational software applications to store and manage student information within a centralized database

SQL Structured Query Language – A language used to retrieve information from SQL compliant databases.

vi

USA Uncle Sam’s America – An application inside K-12 Teaching Application Software that teaches United States geography.

vii

1 Introductory MaterialThe introductory material in this report intends to familiarize the reader with the Ongo08 senior design project: K-12 Teaching Application Software and Support. The Ongo08 team created this software package as a tool to supplement classroom education in the areas of mathematics and geography. Due to the large nature of the project, the K-12 Teaching Application Software and Support system is divided into three subteams, each responsible for a different aspect of the software project. These subteams include the Mathematical Teaching Software System (MTSS), the Globey's World/Uncle Sam's America geography application (GW/USA), and the Software Application Support Framework (SASF). The introductory material includes an executive summary, a project description, and an overview of results to date. Each is divided into subsections by subteam. Following these segments, the introductory material continues with acknowledgements, the problem statement, the operating environment, intended users and uses, assumptions and limitations, and expected end-product deliverables.

1.1 Executive SummaryThe executive summary gives an overview of the purpose of the project and the solution approach used. In addition, the executive summary provides background information such as operating environment and intended users and uses to give a context for the project. Following the introductory materials, the document continues with a history of the project and previous accomplishments, present accomplishments for the semester, and future project work. The document then concludes with what the team learned, the team’s risk management policy, and team contact information.

1.1.1 Need for the ProjectThe K-12 Teaching Application Software and Support system was created with the intention of being a supplemental educational tool for the classroom. The initial need for the project came from teachers who reviewed results of Iowa students in the K-12 range on nationally standardized tests. Iowa students, as a whole, historically achieve scores that are higher than the national average; however, teachers identified performance in mathematical problem solving as being particularly low and in need of additional instruction. As a result, the K-12 Teaching Application Software and Support project began in order to address this issue and determine a suitable method to improve students’ mathematical problem solving skills.

In addition, teachers expressed interest in geography software for use in the classroom. The mathematics software team and a geography software team joined efforts, along with a framework team to manage them, in order to create a software suite to address teachers concerns and interest in a computer-based educational tool. The current target audience is third through sixth grade students, teachers, parents/guardians, school and computer administrators, and course coordinators. The scope of the project is presently limited to regional schools in Iowa, but may be expanded in the future.

8

1.1.2 Project DescriptionThe K-12 Teaching Application Software and Support system was originally three separate projects, the MTSS, GW, and USA projects. The projects merged into a single senior design project due to the similar goals, needs, and interests of their intended clients. The merger of the MTSS, GW, and USA projects also included creation of a framework team responsible for integrating the other projects and creating a common framework within which they can function.

1.1.2.1 MTSSThe Mathematical Teaching Software System provides supplementary instruction that students need to improve their problem solving skills. By creating a program that is platform independent, this software is accessible by all computers with an Internet connection. The problem creation tool in the program allows teachers and course coordinators to add, edit, and delete problems. Additionally, the MTSS software allows teachers to use sets of individual problems to generate quizzes, tests, and practice tests.

1.1.2.2 GW/USAThe Globey’s World (GW) and Uncle Sam’s America applications are a supplement for educators to use when teaching world and U.S. geography. The intention of the applications is to provide geographical information about the world and U.S., regions of the world, countries, and states. For each country and state, geographical data is available, along with a map, the flag, and statisics about the area.

1.1.2.3 SASFTo meet the expanding functionality needs of MTSS and GW/USA, the SASF subteam developed a PHP framework that is common to all applications in the K-12 Teaching Application Software and Support project. The framework provides standard functions for use by current and future applications to store and manage student and application information within a centralized database. User access to the applications is controlled by the SASF through a web interface and user authentication methods.

1.1.3 Results to DateSince the project inception in 2001 with MTSS and later additions of GW, USA, and SASF, the K-12 Teaching Application Software and Support team has produced the concept, design, and functionality of an application suite that is ready for school districts to evaluate for third through sixth grade classroom use. The applications have undergone alpha testing activities and have entered the beta period in which the teacher evaluation will occur.

1.1.3.1 MTSSThe MTSS application currently allows students to work on elementary problem solving skills through a variety of mathematical concept problems. The application contains a library of example problems that cover two primary mathematical concepts: fractions and geometry. Additionally, teachers may create new problems using a problem creation tool. The teacher may also upload an image file related to the problem.

9

1.1.3.2 GW/USABoth GW and USA have finished the design and functionality plan for their application suite contributions. The current implementation of GW and USA provides users with the ability to navigate to specific countries or states through a series of interactive geographical maps. Once a user selects a country or state, they may view statistics populated by a geographical database as well as maps and flag images. A further enhancement to the applications is a comparison tool, which allows the user to select up to ten countries or states and generate a bar chart, which provides easy visual representation for many of the available numerical facts. Additionally, Uncle Sam’s America has the interaction capability through games that include matching state names to their location on a map of the United States of America and matching states with their flag.

1.1.3.3 SASFThe SASF team has created a librtary of common classes and methods that the developers of the MTSS, GW, and USA applications can use. This functionality currently includes design templates, user authentication, and user creation. The SASF subteam is also responsible for maintaining a development and production server for the project code.

1.1.4 Accomplishments during the Spring 2007 SemesterThe Spring 2007 semester brought the K-12 Teaching Application Software and Support to the alpha testing and beta evaluation phases of the design cycle. Throughout the process, the team has continued to make improvements in the documentation and the applications.

During the semester, the Ongo08 team supported the testing and release of the software to teachers for evaluation by completing several related and prerequisite tasks. Each subteam created a test plan for their respective software application to detail the work to be accomplished during the alpha testing phase. The team also implemented a web-based defect-tracking tool for reporting, assigning, and tracking defects found during testing. Finally, the team released the software to several regional teachers on March 29, 2007, for evaluation during the beta period. The Ongo08 team will provide support to teachers via email during their evaluation and will ask for feedback in the form of a brief survey.

Each subteam also pursued tasks required for the completing their applications. MTSS created a document detailing the problem solving algorithm, implemented a mechanism for obtaining student feedback during the problem solving process, refined search tools, and updated help pages. The MTSS subteam also fixed reported defects found in the problem search functionality. GW/USA met with Anne Thompson in the Department of Curriculum and Instruction to discuss expansion of the functionality of all Ongo08 applications and began planning future improvements. The GW/USA subteam fixed known defects in their applications, updated city displays, and revised help pages. The SASF subteam managed team member accounts, implemented the team’s defect-tracking tool, fixed defects in the framework such as account creation and spelling errors, and created a design for a grade book feature. While preparing for the deployment of the software to regional teachers, the framework team created necessary accounts and

10

passwords for beta evaluators and migrated the project code from the development to the production server.

1.1.5 Work Yet to Be CompletedThe Ongo08 team continues to work on fixing existing defects in the software, supporting beta evaluators, completing project documentation, and constructing a grade book framework for the remainder of the semester.

The entire Ongo08 team will continue to work on resolving the remaining lower priority issues to incorporate into future releases. The team will also document any defects encountered during the beta period using the defect-tracking tool.

The SASF team is in the process of completing a grade book design and implementing necessary database tables. The SASF team will also populate the database tables with sample data from which the team may run queries. Some primary goals for the SASF team are to generate a list of features expected in the grade book software and to begin writing necessary queries for these features.

The GW/USA subteam is still exploring additional games and interactive learning tools that may be incorporated into the geography applications. They are also in the process of setting up a second meeting with Ann Thompson, a member of the Department of Curriculum and Instruction, to gain feedback on the current implementation of the software.

The overall team continues to improve upon the documents that detail the use, design, and implementation of the software. These documents include a user manual, problem solving algorithm description, and design details. The overall team also plans to obtain feedback from the teachers who are assisting the team in the beta period to incorporate what third through sixth grade teachers desire from the learning tool.

1.2 AcknowledgementsThe entire Ongo08 team would like to acknowledge Dr. John Lamont, Professor Ralph Patterson III, and Dr. Greg Smith, the faculty advisors, for the guidance they have provided and will continue to offer throughout this project. Also, thanks to Ann Thompson, from the Department of Curriculum and Instruction, for her contributions in determining aspects of an effective problem solving algorithm and for her suggestions and ideas for expanding the GW and USA applications. Finally, the Ongo08 senior design team would like to acknowledge the teachers and administrators of the Ames Community School District and other participating regional schools, whose cooperation is imperative to the success of the project. In particular, the team would like to express their appreciation to the teachers, who are contributing their time and expertise in education for the benefit of the Ongo08 project.

1.3 Problem StatementSeveral teachers in the Ames Community School District expressed a need to improve student performance in the areas of mathematical problem solving, United States

11

geography, and world geography. They also expressed interest in an application that would focus on student development in these problem areas, which could be used as a supplement to classroom instruction.

1.3.1 General Problem StatementThe objective of the project is to design an application that assists students in improving their problem solving abilities and comparative geography skills, and allows students, parents/guardians, teachers, and administrators to track performance. The application must be extensible for creating additional problems and problem sets as well as creating future applications.

1.3.2 General Solution ApproachThe Ongo08 team chose to design an Internet-based application for supplemental classroom instruction. The project includes development of a framework that integrates and meets the needs of all other applications in the software suite. The project has produced a set of three teaching applications: MTSS, USA, and GW. These applications provide children in elementary school grades three through six an opportunity to exercise their computer skills while learning about mathematics, United States geography, and world geography. MTSS emphasizes teaching of mathematical problem solving techniques through, problem repetition and problem walkthroughs. GW and USA provide an interactive way to learn about both world and United States geography, respectively.

The approach for designing and implementing the applications was to create web-based software that allows students to access a server from their own computer, alternatively called a client. The communication between the client and the server is accomplished via the Internet. Depending on the user’s role, the server generates a custom web page for each individual client. For example, a different web page may be displayed based on user type (i.e., computer administrator, school administrator, course coordinator, teacher, student, parent/guardian, or guest). The team created a MySQL database store user information and generate example problems, homework problems, quizzes, and tests. To aid students in developing their problem solving skills, a problem solving algorithm was implemented to walk students through the steps of solving problems. The geographical software also provides educational games for students to use to practice world and United States geography in an exciting way. The framework supports web tools that allow students to keep track of their score via user accounts and allows teachers and administrators to customize individual problems, homework, quizzes, and tests to evaluate student performance. The entire suite is implemented using dynamic web pages written with a combination of PHP, SQL, and HTML.

1.4 Operating EnvironmentThe K-12 Teaching Application Software and Support project uses LAMP (Linux, Apache, MySQL, and PHP) architecture. The web application code is written in PHP, which runs as a module in the Apache web server to dynamically generate HTML documents. The software uses a MySQL compatible database and runs on a Linux operating system. The use of the LAMP architecture provides a powerful open-standards

12

environment for the web applications to run and be platform independent. In addition, because users may access the entire project using a web browser, there is no need for users to download or install software.

The client software is required to function on both PC and Macintosh computers. This requirement is met by using platform-independent HTML. The central server runs Linux and is capable of making many computations simultaneously. If adopted by several regional school districts, the K-12 Teaching Application Software and Support project requires a sufficient hardware upgrade to serve a large number of simultaneous clients. Alternatively, as a commercial product, the software may run from local servers and databases.

1.5 Intended Users and UsesThis section summarizes the intended of users of the K-12 Teaching Application Software and Support suite and the specific uses for which the software is intended.

1.5.1 Intended UsersThe intended primary users for the software are students in grades three through six, teachers, and course coordinators. In the future, the project may extend to additional grade levels in the kindergarten through twelfth grade range, as curriculum coordinators determine appropriate. Other users include computer administrators, school administrators, and parents/guardians.

1.5.2 Intended UsesThis application is intended to be used as a tool to supplement classroom instruction in the areas of mathematical problem solving, United States comparative geography, and world comparative geography. The application will offer the ability for teachers to create new problems for practice, homework, quizzes, and tests. The software already includes 145 mathematical problems for teacher use and demonstration. Student performance shall be recorded using several metrics, including scores, time taken to solve a given problem, and number of attempts. In addition, the software provides feedback tools for students to report their confidence in their ability to solve mathematical problems. The geographical applications are intended to be used as a supplement to classroom learning and a tool for elementary students to perform research related to geography.

1.6 Assumptions and LimitationsAs with all projects, there are assumptions and limitations that the team must consider at each stage of development. This section summarizes those assumptions and limitations with regard to this software project.

1.6.1 AssumptionsThe following lists summarize the client and team-centric assumptions made for the K-12 Teaching Application Software and Support project.

13

1.6.1.1 User-Centric AssumptionsThe following list summarizes the client-centric assumptions made for this software project. This refers to the assumptions that the team has made about the individuals that are expected to use the product.

Users have access to computers that are capable of running web applications Users’ computers have access to an Internet connection Users’ computers are operating Internet Explorer (Version 5.0 or later), Netscape

(Version 5.0 or later), or Mozilla Firefox (Version 1.0 or later) Users have prior experience using computers or have access to resources to assist

them when they are using the software Computer expertise is available locally to assist users in troubleshooting problems

with software and Internet connections and to assist the students when they are using the system

No students using the software have a disability involving sight, dexterity, or reading comprehension

Students will be exposed to relevant topics prior to their use of the software The instructor has a mastery of relevant topics and experience in designing

problem sets and quizzes The instructor possesses basic computer navigational skills Users have access to help pages and a user manual Students should use the applications at home with parent/guardian supervision or

in a classroom environment with teacher supervision During development, support for the software will be provided via email using the

[email protected] email address

1.6.1.2 Team-Centric AssumptionsThe following list summarizes the team-centric assumptions made for this software project.

Team members have permission to access the server database and the source code Team members have sufficient computer resources to access and work in the

development and production environment Final versions of the applications will be hosted on a computer managed by the

Department of Electrical and Computer Engineering The team has access to a development environment on a separate machine from

the production environment Hardware used for storage and processing will have a high level of stability Applications will not use proprietary web browser extensions or enhancements The framework encompasses all common functionality of the applications The framework will be used by future developers to create additional educational

applications

1.6.2 LimitationsThe section contains the relevant limitations for the K-12 Teaching Application Software and Support project.

14

1.6.2.1 User-Centric LimitationsThe following list summarizes the user-centric limitations for this software project. These limitations are imposed on the project by the intended users of the project.

Internet connections and speeds are limited and may not be consistent or reliable Computer/processor speeds of the client machines may be limited Not all students have access to computers in their homes Teachers may have little or no experience with designing course content for use

on the Internet Younger students may not have enough experience using computers or know how

to type The total number of users from all participating school districts is limited by the

processing power of the server

1.6.2.2 Team-Centric LimitationsThe following list summarizes the team-centric limitations for this software project:

New team members may not be familiar with PHP or MySQL The size of the MySQL database is limited by the operating system and MySQL

file size limits PHP is under development and code updates may be necessary in order to adapt to

feature depreciation within the PHP language A finite number of applications may run on the framework at any time

1.7 Expected End Product DescriptionAt project completion, the K-12 Teaching Application Software and Support project will provide benefits to both teachers and students. It will contain at least three applications (MTSS, GW, and USA) which will provide an online interactive environment for students to learn mathematics and geography. Additionally, the software will include web-based grade book tools for teachers to monitor student scores and progress. These applications will conform to the PHP framework, which contains standardized functions for the applications and centralized database management. The end product will contain user authentication methods as well as user registration tools. Registered users will be able to log in and use any of the three applications.

The MTSS application will allow students to solve mathematical problems in the following formats: single problems, homework, quizzes, and tests. The MTSS application will also provide mathematical problem walkthroughs that assist students in the problem solving process. In GW and USA, students will utilize world and United States databases to learn geographical facts and comparative geography. Geographical information will be presented for states, countries, regions, and continents via games, comparison tools, and problems on selected topics.

For each tool in the applications, online help pages will be available to assist users. In addition, a user manual will be available for more detailed documentation and additional application walkthroughs.

15

During external testing and after deployment, the Ongo08 team will be available via the [email protected] email address for any concerns that arise.

In the software, the homepage will allow access to all included teaching applications. The welcome pages for MTSS, GW, and USA are displayed in Figure 1, Figure 2, and Figure 3.

Figure 1 – MTSS Home Page

16

Figure 2 – Globey’s World Home Page

Figure 3 – Uncle Sam’s America Home Page

17

The final product will be a library of PHP code and MySQL database table skeletons. The framework library will present a common framework for web-based educational application development. Developers will be able to utilize the framework to build highly innovative and customizable applications for web-based training, instruction, assessment, and other forms of education. The framework will be highly customizable and will be open to changes, additions, or corrections. The key to the success of this product will be detailed documentation and further development. The framework approach is a low-cost alternative to traditional specialized educational software. The framework will effectively provide an improved return on investment for existing and future software applications. Additionally, the creation of a common framework will allow future developers and even individual schools to further enhance or expand upon the software suite as they see fit. The SASF subteam has implemented security measures to ensure that only authorized users are able to use the software. Various user levels also exist such that different users (students, teachers, administration, etc) shall have appropriate read and write access capabilities.

The first part of the K-12 Teaching Application Software and Support project is mathematical problem solving application called MTSS that will be available to regional teachers and their students through the Internet. The end product will result in software to allow students to practice their mathematical problem solving skills. Students will be able to practice math problems and adjust the difficulty level to attain experience with different problems. In addition, teachers will be able to create quizzes and tests to assess student progress in mathematical subjects.

The Globey’s World (GW) application is a web application that will serve as a supplement for educators to use when teaching world geography. The application will have an extensive help system and full quizzing functionality. In addition, this software provides games that use world geography information. Teachers will be able to access student statistics in order to gauge student progress. The software will allow instructors to enhance the application by creating new problems, editing existing problems, and modifying/updating solutions as needed. Students will use a map of the world as their main interface into the application, from which they can click on countries to retrieve detailed information about the region.

Uncle Sam’s America (USA) is a web application that will provide support to teachers to have support when teaching United States geography. Students will be able to log in, learn about the states, and solve problems based on comparison problem sets. Game features will further encourage learning through interaction with the computer. In a similar manner to Globey’s World, teachers will be able to access statistics to check the performance of the students in order to evaluate and track their progress in United States geography. Teachers will also be able to add to the application by creating additional problems for the students to solve. The main interface for USA consists of a map of the United States, where each state is linked to an information page about that state. There is a function to compare the states to each other in given categories, as well as a quiz page.

18

In the future, the three applications and any new applications that are developed will be integrated with the framework team’s grade book capabilities. Games will be added as features in the software to let students interact with the information in a less structured manner, while still offering educational value. The database responsible for storing GW’s world data and USA's state information can be updated from an electronic source.

A web solution allows the pages of generated HTML to be viewed on any platform. Teachers will be able to compare information obtained from all participating students. Further, these students do not necessarily need to be in the same classroom with the teacher due to the implementation of an Internet-based solution. Students will have the opportunity to work on math problems associated with geography at home with their parents/guardians. This flexibility can indirectly have a large effect on parent/guardian involvement with the education process.

1.8 Previous AccomplishmentsThis section is divided into subsections pertaining to the previous work of the entire Ongo08 team and individual subteams.

1.8.1 OverallOngo08 functions as a team collaboration that is comprised of three subteams: Ongo08a (MTSS), Ongo08b/c (GW and USA), and Ongo08d (SASF). The Ongo08 team continues to develop and expand upon existing teaching and support software for third through sixth grade students and their teachers. The team will develop the necessary documentation for the software, test the software, and provide support for the software.

1.8.2 MTSSThe following subsections detail the work already accomplished by the MTSS team since its incorporation in Spring 2001 semester.

1.8.2.1 Spring 2001With the project and the technical approach well defined, the Spring 2001 MTSS team devoted the vast majority of its time to researching the implementation of MTSS. The primary area of research was the ASP language. The MTSS subteam developed several practice pages in order to develop a greater understanding of ASP’s ability to interact with databases and text files. The first semester students spent significant time honing and perfecting their ASP programming skills so that when coding began in fall 2001 there would be no delay due to lack of knowledge. The second phase of research was to propose various methods of implementing problem solving aids as well as other indirect methods that could be used to facilitate the process further. The team discussed several different architectures and routes that the project could take. At the end of the semester, an extremely loose structure was defined. The following list contains the significant goals accomplished by the MTSS team for the Spring 2001 semester:

Team members learned the ASP programming language Experimental use of ASP with database Several different architectures and routes were planned out for the project One of the architects was defined

19

1.8.2.2 Fall 2001The primary task for MTSS this semester was to concretely define the loose MTSS framework created for the project in the previous semester. It was determined that a working prototype was the primary goal for the semester. The following list contains the significant goals accomplished by the MTSS team for the fall 2001 semester:

Designed and implemented a database. Designed and implemented ASP pages that added, read, and updated database

fields. Developed eight problem pages that presented basic mathematical story problems

to students, which included graphics, and multiple problem steps. Recorded student answers to the developed problems, compared student answers

with correct solutions stored in a text file, stored the final percentage in the database, and the student answer in a text file.

Developed coordinator pages and functions that allowed teachers/coordinators to login/logout of the application, add students, and edit student profiles.

Developed a text-based menu that provided an intuitive interface to the MTSS ASP pages.

1.8.2.3 Spring 2002With the completion of the initial prototype, the focus for this semester was to increase functionality and capabilities as well as overall system speed and performance. The following list highlights the accomplishments of the MTSS team during the Spring 2002 semester:

Problem creation utility - The problem creation utility allows instructors to design their own problems.

Database redesign - The database was redesigned and a more effective and efficient approach was taken.

Delete student - This option allows the teachers/system administrator to delete students from the database.

Add/edit/delete teachers - These options allow a system administrator to create teachers, edit, and delete teachers and their students.

1.8.2.4 Fall 2002The major contribution of the MTSS team for the fall 2002 semester was the identification of PHP and MySQL as the most suitable technologies for the development of the software. PHP was chose to replace ASP as the scripting language, while MySQL was chosen to replace Microsoft Access for the backend database. This represented a significant turning point in the project –all the code written needed to be rewritten to adopt the new and preferred technologies. At the same time, it was determined worthwhile to continue maintaining the ASP code for demonstration purposes. The following list highlights the accomplishments made in fall 2002.

Identification of PHP as the scripting language, and MySQL as the DBMS Debugged the ASP code Conversion of the database from Microsoft Access to MySQL Development a flow chart showing the program functions, input, and output Have an initial version for demonstration to the teachers for testing and evaluation

20

1.8.2.5 Spring 2003The focus of the MTSS team in the spring of 2003 was to begin conversion of the ASP code to PHP using a free, third party software tool. The decision to adopt a new PHP implementation framework for MTSS caused unforeseen delays in the project activities. As a result, the team abandoned the conversion to PHP midway into the semester since the code generated by the third-party software would be almost impossible to restructure when the framework is developed.

Use of an automated tool to convert the ASP code to PHP (abandoned midway into the semester)

Updated the ASP code to have a version ready for demonstration to teachers Tested of all web pages created to date Addition of new fraction problems to the database

1.8.2.6 Fall 2003The successful conversion of MTSS from ASP code to PHP was a major achievement in fall 2003. In addition, the database was successfully converted from Microsoft Access to a MySQL database backend. Unforeseen circumstances such as debugging and coding made the team spend more time on programming instead of getting the 100 fraction problems done on time. In the end, only 25 fraction problems were added into the database.

Debugged and deployed ASP version Restructured database schema to satisfy newly identified requirements Completed the transition from ASP to PHP and Microsoft Access to MySQL Addition of 25 new fractions problems in database (for a total of 75) Development of a testing matrix for keeping track of defects in the software

1.8.2.7 Spring 2004The following list summarizes the accomplishments of the Spring 2004 MTSS team:

Debugged PHP version Restructured MySQL database to comply with the framework 50 problems were added into the database for every month Development of a new testing matrix to track defects Completed framework integration for login and authentication Documentation completed

1.8.2.8 Fall 2004During the fall 2004 semester, the main goal was to continue the research that began the previous semester on the problem solving algorithm. A written report on the problem solving algorithm was the goal at the end of the semester. On the coding side, the MTSS subteam completed a quizzing application by the end of the semester that would give teachers the ability to create/edit/maintain quizzes. A summary of what the Fall 2004 MTSS team accomplished:

Created a category matrix to organize the problems Added 20 new problems in the database Worked on converting text file to DB

21

Created and improvised an effective problem solving algorithm report Finish coding various parts of the quizzing application

1.8.2.9 Spring 2005The following list describes the significant accomplishments made by the Spring 2005 MTSS team.

Researched problem solving techniques - This task was only partially completed because the team found a new contact who recommended a new way to do the problem solving algorithm (PSA) in the MTSS application.

PSA report – A document outlining three different possible PSA approaches was completed. The document included information to outline the approach each different PSA accomplishes.

Grade-book functionality - The goal of this task was to implement software that would give students the ability to take quizzes, allow for the grading of quizzes, and for grades to be maintained in a database.

1.8.2.10 Fall 2005The following list describes the significant accomplishments made by the fall 2005 MTSS team:

Problem solving algorithm implementation – The MTSS subteam worked on refining the PSA, defined a method for implementing the PSA, and planed for implementation of the PSA. However, refining and defining the PSA was only partially completed. The remaining task is the actual implementation of the PSA into MTSS.

Equivalent answers to questions - The need for equivalent answers to problems to be marked as correct was discussed several times in meetings with the project advisors. A method for implementation had not been selected, so planning for implementation was unfeasible.

.

22

1.8.2.11 Spring 2006During the Spring 2006 semester, MTSS worked on fixing defects found and defined in fall 2005. Due to the large number of defects, they were assigned to individual team members. This was possible due to CVS training and good documentation of the defects. All of the documented defects were fixed on time and documented before the end of spring break. In addition to fixing defects, the structure of the code was also reviewed. Unnecessary code was deleted and the code was restructured.

1.8.2.12 Fall 2006The MTSS subteam worked on three projects during the Fall 2006 semester: improving the problem solving algorithm, creating a simplified problem searching tool, and improving the fundamental structure of the code.

One solution generated for the PSA was to allow teachers to link walkthrough problems to existing problems. Walkthrough problems would be generated by teachers and would assist students in improving their problem solving skills.

The MTSS subteam created a new search page that had the option of using advanced searching, which was the existing method, or using simple search, which took fewer arguments when searching and whose appearance more appropriately resembled the look and feel of the software suite.

To improve the code structure, several files that were duplicated across the student/teacher/administrator folders were moved to a centralized folder, and shared by the various users.

The MTSS subteam’s problem creation tool is very adaptable and provides a solid foundation for creating single problems, walkthrough problems, quizzes, and tests for MTSS. The tool is modular enough to allow GW and USA to use it to create math problems based on geography.

1.8.3 GW and USAThis section of the status report outlines the previous accomplishments for the GW and USA subteams. All data presented in the following sections were drawn from previous status report documents. Please note that after the Spring 2005 semester, the GW and USA subteams merged to become one team, for which there is a separate subsection after the GW and USA individual team.

1.8.3.1 GWThe GW subteam was formed in spring 2001. Its main purpose was to create an easy and entertaining way to teach students about world geography. The following subsections describe the events of the USA team from its initial semester of work through spring of 2005.

1.8.3.1.1 Spring 2001The Spring 2001 semester started with the creation of a GW prototype: a Visual Basic, stand-alone application consisting of a world page, country page and comparison page. Figure 4 shows the original prototype.

23

Figure 4 – Globey’s World Prototype

Successes: Created the standalone application and developed a detailed blueprint for how the final application should operate. Application parameters and objectives were defined as well as the overall direction that GW would take.

Failures: Although it was a suitable prototype, the application took too long to start and was too memory intensive. Interactivity of the Globey character was not fully realized.

1.8.3.1.2 Fall 2001/Spring 2002After realizing the limitations of Visual Basic and the portability of the application, the team decided to implement GW with the web-based LAMP technologies mentioned earlier. Figure 5 shows a screenshot of the original web-based design of GW.

Figure 5 – Globey’s World Web Application, in PHP and MySQL

24

Successes: The stand-alone application was imported to web technologies, a MySQL database of country data which could be accessed over the web via web pages written primarily in PHP.

Failures: The database was riddled with typographical errors. There was minimal interaction with school administrators and teachers, and aside from the comparison page, there was a general lack of mathematical-related content. In addition, the overall presentation could have used more polish. It did not leave database and machine passwords readily available for future team members.

1.8.3.1.3 Fall 2002With a basic framework in place, the fall 2002 team worked on adding polish to the overall feel of GW. Figure 6 shows a screenshot of the improvements. The team updated the graphics to make Globey more presentable, and identified 50 possible mathematical integration ideas to add to GW. The subteam also identified required future changes to the database. Finally, the team leaders of all the Ongo08 subteams created a cookbook for future teams to use as a reference.

Figure 6 – Globey’s New Look

Successes: The updated graphics looked more professional; database errors were fixed, and math concepts were brainstormed. Cookbook ideas allowed future team members to avoid password and system difficulties that were encountered.

Failures: It took too long to locate all the necessary passwords. As a result, the team fell behind schedule.

25

1.8.3.1.4 Spring 2003The primary accomplishments in the spring 2003 were spell checking the country database, creating an outline for the help section and fixing the country comparison page. A large portion of the subteam’s effort went toward updating the country database entries to ensure uniformity throughout each field. This was accomplished by creating a set of formatting rules for each team member to follow when they were editing their assigned countries. The Globey's World team created a prototype screenshot (Figure 7) of the country comparison page because the previous implementation was not fully functional. The old version of the comparison page could compare any statistic from two countries, but the revised version could compare up to ten countries.

Figure 7 – Prototype of New Country Comparison Page

With the assistance of the Department of Electrical and Computer Engineering Computer Support Group, various security upgrades were installed on the project development server. Unfortunately, this caused various database connectivity issues between the GW PHP code and the newly installed software that left the team unable to work on the country database for three weeks.

Successes: The country database had uniformity between all entries. The country comparison page worked again. The project web server was more secure.

Failures: Downtime during the server upgrade caused the team to fall behind schedule.

1.8.3.1.5 Fall 2003The goals of the fall 2003 team were to make GW more attractive and user-friendly. The Globey's World subteam redesigned the world and region pages to contain new maps that

26

were more geographically accurate. The maps were also given Flash multimedia functionality so that a country or geographic region would light up when a user moved their mouse over it. The next major accomplishment was restructuring the help pages so that they would be compatible with multiple web browser types. The final section updated was the country comparison page. The functionality of this page was improved to be more user-friendly for the students. The previous page required students to hold down the CTRL key if they wanted to select multiple countries, while the new page introduced a second selection box that allowed students to make their choices one country at a time. The difference is shown in Figure 8 and Figure 9.

Figure 8 – New Country Comparison Page

Figure 9 – Old Country Comparison Page

The team also spent some time coordinating with the USA team to make the two sites look similar and to encourage easy transition for students using both programs. At the end of the semester, the team introduced an internal testing matrix used to have team members test code that they did not develop during the semester. This ensured that everything was working properly. The last accomplishment of the team was the creation

27

of two scripts to assist in the development process. The first, which was meant to backup all of the GW data, did so by saving the information on one of the team member’s CLUE accounts. The other script, meant to make database updates run easier, was started but not officially released. This task was left for future semesters to finish and release.

Successes: The comparison page was fully functional and time was allotted for it to be tested extensively.

Failures: While the development of the comparison page allowed plenty of time to be tested, there were several errors discovered that had to be fixed.

1.8.3.1.6 Spring 2004The two primary goals of the spring 2004 team were to improve the look of GW and to implement the current version of the authentication and registration framework developed by the SASF team. The GW interface changed from a frames layout to tables. The subteam also implemented a style sheet to give all of the pages a similar look and feel and eliminate the need to code the look and feel into all of the pages. GW coordinated with USA to make these changes because of effort made in previous semesters to provide a similar look and feel to GW and USA. The remaining work was to implement the authentication provided by the framework team. This necessitated the use of a username and password for anyone wanting to use any of the applications of Ongo08. The team also added an additional level of functionality to GW by creating a region page. Previously, a student could select a country, be directed to a region map, and then directed to a country page. However, no method existed to return to the region page. To select a new region or country, a student had to return to the world page and begin the process over again. The design of the world page is similar to the design of the country page. A student could choose a region by clicking from the country page or by choosing a region from the drop-down menu at the top of the region page. Some of the changes are displayed in Figure 10 and Figure 11.

28

Figure 10 – Screenshot of Globey’s World Homepage

Figure 11 – Globey’s World Region Page

1.8.3.1.7 Fall 2004The first accomplishment of the team was a single sign-on page that allowed a user to log in and then navigate through the applications without having to log in to each application. Each application added a link to the suite page, allowing users to choose an application,

29

return to the list, and then choose another. A screenshot of this page is shown in Figure12.

The focus this semester was the implementation of the quizzing framework designed by SASF. Each subteam was assigned a portion of the work and worked closely with the SASF team to enact revisions and updates. The quizzing capabilities were implemented. A screenshot of the quizzing front page is shown in Figure 13.

Figure 12 – Single Sign-on Page for Ongo08

Figure 13 – Quizzing Front Page for Ongo08

30

1.8.3.1.8 Spring 2005The primary task for GW in the spring of 2005 was to implement the grading framework designed by the framework team in the fall of 2004. In particular, the Globey’s World team worked on the front-end display of the grading tool. Other semester accomplishments include:

Creating a short user manual Alpha testing and defect fixes Set up a means for beta evaluators to submit error reports Preparations for merging with Uncle Sam’s America

1.8.3.2 USAThe USA subteam was formed in fall 2002. The Uncle Sam’s America application teaches students about United States geography by presenting the geographical material in a similar manner to Globey's World. The following subsections describe the accomplishments of the USA team from this initial semester of work to the spring of 2005, after this semester the GW and USA subteams were combined.

1.8.3.2.1 Fall 2002The Fall 2002 semester began discussions about design and documentation needed to start work. Team members devised a database schema for the state information and proposed a general design layout for the USA application.

1.8.3.2.2 Spring 2003During the Spring 2003 semester, the USA team took on the task of populating the database with state information. The team did this by hand from printed almanacs due to the lack of an electronic database source. Once complete, the USA application provided students the ability to use it as a reference tool about the states. Navigation to facts about the states was conceptualized and implemented with the use of an interactive United States map. Figure 14 shows the first attempt offering navigation amongst the states’ information pages.

31

Figure 14 – Initial USA Navigational Map

1.8.3.2.3 Fall 2003The Fall 2003 semester entailed user interface design improvements for the USA application, as seen in Figure 15. The team also used this semester to check the database information for errors, as it was possible due to the manually entered data the previous semester. The team also worked with GW for the conceptualizing and implementing a similar comparison tool feature for USA, except for dealing with states instead of countries. Figure 16 shows the USA version of the comparison tool at work.

32

Figure 15 – New USA First Screen with Updated Map

Figure 16 – Comparison tool in the USA Application

33

1.8.3.2.4 Spring 2004The Spring 2004 semester began with small changes to the look of the USA application. The team noticed that Alaska and Hawaii were missing on the main navigation page and took measures to add them into the interactive graphic. The team then focused its attention on creating an authentication login screen for the application. This ability would make sure that only those users allowed to use USA would be able to access it. With the thought of eventually incorporating student progress tracking into all of the Ongo08 applications, including USA, this authentication would make sure individual student profiles were independent.

1.8.3.2.5 Fall 2004The Fall 2004 semester team used their time to expand upon the status of the USA application as a reference tool and began to address the need for interactive features to better gear the application toward the intended audience of third through sixth grade students. The USA subteam implemented two games with a state theme to enforce knowledge of state flag and state name associations. Both games utilized a blank United States map that was similar to that of the main navigation page, seen in Figure 17.

Figure 17 – Blank US Map Used for Game Implementation

34

1.8.3.2.6 Spring 2005The Uncle Sam's America subteam performed implementation activities for an interactive game for the USA application in the spring 2005 semester. This new game dealt with the location of Uncle Sam in various locations around the United States. This semester also started the research for an electronic database source for future updates of the application in order to remove the need for manual data entry of the state information into the database backend. The team found a few leads about the database source, but none could be used to accomplish the task.

1.8.3.3 GW and USA Combined SubteamThe accomplishments from previous semesters for the GW and USA combined subteam are outlined in the following sections.

1.8.3.3.1 Fall 2005The Fall 2005 team spent most of their time researching sources for automatic database retrieval and game development. The GW application utilized the CIA database to gather its information about the various countries around the globe, but unfortunately, there did not exist a similar electronic database for the USA application. The team spent much of their time with this but regrettably did not come up with anything that would improve over the previous method.

In an effort to make the applications more interactive, the Fall 2005 team also spent a large majority of their time on game research and planning. The GW/USA subteam brainstormed ideas such as creating a continent game for GW as well as games about famous landmarks for both GW and USA. The subteam considered including other school subjects such as math, spelling, and knowledge of national landmarks into future games.

1.8.3.3.2 Spring 2006The Spring 2006 team split time between researching and extending usability. Developing additional games and locating sources for automatic database repopulation became the main goals for research. Unfortunately, the team did not find satisfactory sources for automatic database repopulation. Fixing code flaws and verifying cross-browser compatibility created a more robust, stable software package. The GW/USA subteam completely rewrote the comparison page code in order to fix an issue with chart values. In addition, extensive testing allowed the team to target and eliminated several discrepancies between browsers such as Mozilla Firefox and Microsoft Internet Explorer.

1.8.3.3.3 Fall 2006The Fall 2006 subteam worked to increase the stability and long-term sustainability of the software.

The team refined the geography games to increase their learning effectiveness and redesigned games to facilitate increased information retention.

35

The team implemented database auto-repopulation tools in order to keep the software up to date.

The team researched the possibility of expanding the software by combining MTSS math problems with GW and/or USA to make innovative games.

The team improved the appearance of the application by creating clearer global and regional maps and continued to strive for cross-browser uniformity.

1.8.4 SASFThe SASF subteam was initially formed in the fall of 2003. Previously, the May03-01 team, a single-year project team, was responsible for the framework. The team left behind a variety of files that provided some insight into how the framework could be approached but no working prototype or initial release of the framework. The Fall 2003 semester team checked their files into CVS on the sd6 server into a repository named Mercury. The current Ongo08d team does not know the successes and failures of this project team. After this, the fall 2003 team made several important achievements.

1.8.4.1 Fall 2003The accomplishments of the Ongo08d subteam for fall 2003 include the following:

Project initializationo Obtained existing skeleton code from the May03-01 subteamo Reviewed skeleton code and determined that it did not meet requirements

for a first release of the framework Feature list prioritization

o Received a list of requested features from the other Ongo08 subteamso Generated a prioritized feature list

Basic authentication functionality for the users Registration functionality to add/delete/modify users in database

Grade book for teachers Ability to modify/add/delete questions Quizzing functions with a library of math based questions Teacher/parent/guardian ability to view student progress Timing feature for quizzes and record of number of tries

Classifications of problems (different difficulty levels) Creation of CVS repository

o Placed repository on the sd6.eng.iastate.edu in /home/framework foldero Checked May03-01 skeleton code into the repository known as Mercuryo Created a new folder for the current semester’s files, called Venus

Creation of user class (Figure 18)o Allowed for authentication and registration of userso Required for libraries to function

Creation of authentication library (Figure 18)o Created a library with authentication methodso Method created for user authentication: authenticate(MySQL connection,

string username, string password) Creation of registration library (Figure 19)

36

o Created a library with user registration methodso Methods created for user to register, unregister, or update information

registerUser(connection, object user) unregisterUser(connection, string username) updateUser(connection, string username, object newUser)

Created test cases for authentication and registration libraries Documentation

o Created instructions on how to access the framework fileso Created framework documentation as a reference for framework libraries

37

Figure 18 – Class Diagram

38

Figure 19 – Library File Diagram

1.8.4.2 Spring 2004The accomplishments of the SASF subteam for spring 2004 include:

Project initializationo Obtained materials from the previous term, fall 2003o Reviewed PHP and written framework code for new memberso Taught PHP to new members of each subteamo Taught integrating framework methods

Feature list prioritizationo Received a list of precompiled features from the previous framework teamo Updated feature list (Table 1)

39

Table 1 – Spring 2004 Functionality List

# FUNCTIONALITY COMPLETED

1 Basic authentication functionality for the users Fall 2003

2 Registration functionality to add/delete/modify users in database Fall 2003

3 Ability to modify/add/delete questions by the teacher Spring 2004

4 Quizzing functions with a library of math based questions Spring 2004

Collected quizzing functionality informationo Determined necessary the methods required/requestedo Determined a base set of necessary functions

Created a database requirements documento Created a list of functionso Created a list of SQL tableso Documented queries used in all applications

Created a quizzing libraryo Created a library of methods for adding, removing, and modifying

quizzes/questions/imageso Tested the library and integrated into latest version of code

Created necessary SQL database tableso Created necessary SQL tables (Figure 20)

Quiz table Quiz problems table Problems table Problem choices table File catalog table

Created test cases for quizzing library (/home/framework/repository/venus/test) Previous library code improvements

o Improved existing library for greater flexibility Stored server address into globals file Allowed for flexibility within authentication and registration

functions Eliminated need to change server name in each file

o Improved authentication Documentation

o Created a project feature matrixo Created framework documentation as a reference for framework libraries

Application supporto Initiated and supported integration of framework into applications of other

subteams

40

Quiz

PK QuizID

QuizName QuizSubject QuizOwner QuizWeight

QuizProblems

PK QuizIDPK ProblemNumber

ProblemID ProblemWeight

Problems

PK ProblemID

Category SubCategory Difficulty ProblemType QuestionText RandomizingAllowed IsSubProblem SubProblemOwner AllowCalculator SubProblemNumber FileID EvaluationType AllowedDeviation Answer

ProblemChoices

PK ProblemIDPK ChoiceNumber

ChoiceText ChoiceFileID

FileCatalog

PK FileID

Subject Category FileName FileDescription IsLink FileType Link BinaryData

Figure 20 – Quizzing Tables Diagram


Project initializationo Obtained materials from the previous term, spring 2004o Reviewed PHP and written framework code for new memberso Taught PHP to new members of each subteamo Taught integrating quizzing framework methods

Feature list prioritizationo Received a list of precompiled features from previous framework teamo Updated functionality list (Table 2)

Table 2 – Fall 2004 Functionality List




3 Basic quizzing functionality for students and teachers Spring 2004

4 Basic quiz grading functionality for students Fall 2004

5 Functionality to relate authentication, quizzing, and grading into one large system

Fall 2004

41

Collection of necessary grading functionalityo Determine the methods other subteams requiredo Determined functions necessary to implement other subteam requests

Database requirements documento Created and revised a list of functions, SQL tables, and uses for all actionso Distributed list to all subteamso Completed database requirements documentation

Creation of grading/overall libraryo Created a library for adding, removing, and modifying quiz results

Creation of SQL database tableso Created a SQL tables for grading/overall functionality

School Administrator Course coordinator Teacher Parent ParentsToStudents Student SectionsToStudents Section SectionQuizzes QuizRecords ProblemsAnswered

o Creation of test cases for quizzing library (located at /home/framework/repository/venus/test)

Previous library code improvementso Improved method of obtaining framework errors messageso Added quizCreator field to quiz tableo Added quizPrivate field to the quiz tableo Added global variables to represent different applicationso Added getUserByCriteria method, which allowed searching for users

Documentationo Updated a project focus matrixo Created a framework document as a reference for framework libraries

Application supporto Initiated and supported the integration of the quizzing framework into

other subteam applicationso Wrote documentation for ease of use of quizzing framework

1.8.4.4 Spring 2005Accomplishments of the Ongo08d subteam for the spring of 2005 include the following:

Project initializationo Obtained materials from the previous term, fall 2004.o Reviewed PHP and written framework code for new memberso Taught PHP to new members of each subteam

42

o Taught integrating grading framework methods Feature list prioritization

o Received a list of precompiled features from previous framework teamo Updated the functionality list (Table 3).

Table 3 – Spring 2005 Functionality List







Fall 2004

6 Improve authentication so it is more secure and can store a greater number of user fields

Spring 2005

7 Timing functionality for quizzes Spring 2005

8 Ability to classify problems by purpose and difficulty Spring 2005

Collection of necessary functionality for timing, classification, and authenticationo Met with other subteams to determine the methods required/requestedo Determined a base set of functions necessary to implement every action

requested by other subteams Creation of functionality

o Created new code that delivered the required functionality Added the ability to classify problems by difficulty and purpose Added the ability to time quizzes Rewrote authentication code to provide security and functionality

Added SQL tables for grading/overall functionality (Figure 21)o Schoolso Teachers o Userso Parents o ParentsToStudents o Studentso Administratorso Coordinatorso Sections o SectionStudents o Quizzeso SectionQuizzes

43

o QuizProblemso Problemso QuizRecordso ProblemsAnsweredo ProblemAnswerso ProblemChoiceso FileCatalog

Creation of test cases for new code Documentation

o Updated a project focus matrix to determine every subteam’s goals and focus for the given term

o Updated an existing overall framework document Application support

o Initiated and supported subteam integration of the quizzing framework into their applications

o Responded to and assisted with troubleshooting of numerous issues uncovered by the other subteams

Server supporto Performed troubleshooting and analysis on the project’s servero Determined there was server hardware failure, resulting in unpredictable

server crasheso Worked with the Computer Support Group (CSG) to create a virtual server

on one of CSG’s physical serverso Assisted with the migration of files and applications between servers

44

Figure 21 – Overall Tables Diagram

45


Project initializationo Obtained materials from the previous term, spring 2005o Reviewed PHP and written framework code for new memberso Taught PHP to new members of each subteamo Taught integrating grading framework methods

Feature list prioritizationo Received a list of precompiled features from previous framework team. o Updated prioritized feature list

Table 4 – Fall 2005 Functionality List







Fall 2004

6 Improve authentication so it is more secure and can store a greater number of user fields

Spring 2005

7 Timing functionality for quizzes Spring 2005

8 Ability to classify problems by purpose and difficulty Spring 2005

Implemented uniform look and feel across applications Restructure timing functionality for quizzes Server clean up

o Removed unused source codeo Reorganized working folders and stable code

Documentationo Updated a project focus matrix to determine every subteam’s goals and

focus for the given termo Updated an existing overall framework document

Application supporto Initiated and supported subteams during integration of the quizzing

framework into their applicationso Responded to and assisted with troubleshooting of numerous issues

uncovered by the other subteams Server support

o Assisted with the migration of files between servers.o Assisted with the migration of applications between servers.

46

1.8.4.6 Spring 2006The accomplishments of the Ongo08d subteam for spring 2006 include the following:

Server account maintenanceo Created accounts for local schoolso Updated accounts for team members

Framework documentationo Improved documentation for code structureo Documented cohesion elements among subsystems

Improved look and feel of applications Server maintenance

o Code Migrationo Continued code cleanup

1.8.4.7 Fall 2006The Fall 2006 SASF subteam continued work to make the framework of the software suite as robust as possible.

Existing automatic logout based on a timer was found frustrating for program users: it was modified to time out after a period of two hours

Implemented a new logout feature Created a more aesthetically pleasing login page Investigated and stripped of outdated comments and code in existing framework

1.9 Present AccomplishmentsThe following section describes the significant accomplishments made during the current semester, Spring 2007.

2.2.1 OverallFor the Spring 2007 semester, the focus of all subteams has been on preparing the K-12 Teaching Application Software and Support for evaluation by teachers. In order to accomplish this, the Ongo08 team performed alpha testing on the software and prepared user accounts and passwords for beta evaluators. Tasks related to accomplishing this goal included documenting items such as formal requirements and test plans. Other ongoing goals for the entire application included refining the problem solving algorithm design, training new team members, updating the user manual, producing end product documentation, and project reporting. A detailed description of each of these accomplishments follows in detail.

2.2.1.1 Problem DefinitionOngo08 defined project goals for the Spring 2007 semester and established deadlines and a schedule to accomplish them. Ongo08 members were informed of the project’s semester goals and deadlines and were instructed to conform to common software practices. The project goals outlined specific tasks and how these tasks would be accomplished. The expected results of accomplishing these goals were made clear to team members and all project goals were documented in the current project plan.

47

The overall project definition had only minor changes this semester compared with the project definition from the previous semester. This semester was a continuation of Fall 2006 project goals with the addition of formal procedures for testing and releasing the software and requirements and definition documentation. The requirements and definition documentation provide standards for future extensions to the applications. The formal test procedures outlined this semester are for implementing a testing cycle that future semesters may follow. In the future, it is the team’s goal to apply a cycle that involves alpha testing and beta evaluation with concurrent software development. This cycle is to be implemented on either a one or a two-semester basis. This establishes regular contact with educators and ensures that software additions are properly tested and verified.

2.2.1.2 Training SessionsThe training session consists of two sections: software training courses and framework training course with documentation and coding practices.

2.2.1.1.1 Software Training CourseThe first training course was held the second week of team assignment during the Spring 2007 semester. This training course, which included all members of the Ongo08 team, prepared new members with the technology used in the project. The training courses were PowerPoint presentations with two tutorials. The first tutorial described overall team layout, team member expectations, and project goals. The second tutorial covered CVS, Eclipse software installation, and the required PHP plug-in necessary to access project code. The 492 team members also answered any questions regarding the project and the technologies employed in the K-12 Teaching Application Software and Support. The goals of the training courses were that new members were quickly brought up to speed with the project, the technology, and had an opportunity to meet their teammates.

2.2.1.1.2 Framework, Code, and Documentation Training CourseA framework, code, and documentation training course was held the third week of the Spring 2007 semester for the entire Ongo08 team. The training course introduced the new team members to the layout of the project and its framework. The results of the session were that the new team members were familiar with the framework and understood how to access and modify project code. The training course also distinguished between development and production code.

The second purpose of this meeting was to review good coding practices and the documentation to be used within the code. Examples of easy to read and well-documented code were provided at this meeting. There were examples in PHP, MySQL, and HTML. The result of this overview was that all team members had the ability to access and update code, and document it in a uniform manner. This resulted in the ability for future semesters to easily review the project code.

2.2.1.2 User Manual CompletionPrevious drafts of the user manual for the K-12 Teaching Application Software and Support were recovered and reviewed to determine if they were still applicable to the

48

project in their current state. The drafts were determined to be out of date and not applicable to the current state of the project. Members from each subteam worked on a new version of the user manual to ensure that the manual was consistent with the latest version of the software. These members used the previous user manual documentation to generate a list of required topics for the new document. Although the team used previous documentation as a starting point, the content of the user manual needed to be almost completely rewritten in order to reflect the latest version of the software. In addition, all new screenshots needed to be taken for accurate visuals.

2.2.1.3 Preparation for Software ReleaseThe Preparation for Software Release section consists of six subsections: test lead position created, defect tracking tool, test plan, alpha testing, beta period, and survey users.

2.2.1.3.1 Test Lead Position CreatedThe Spring 2007 semester team had one major goal: to release the software to end users. In order to accomplish that goal, the Ongo08 team created a test lead position. The reason behind creating this new position was that the team needed a single person to oversee and supervise alpha testing, beta evaluation, and software support. This person was responsible for ensuring that all test activities were completed on time and all reported defects were assigned promptly. The test lead was also in charge of handling defects, suggestions, and issues communicated by beta evaluators.

2.2.1.3.2 Defect-Tracking ToolWith alpha testing and the beta period both being completed this semester, a consensus was gathered that a new tool was needed to manage the K-12 Teaching Application Software and Support project’s defects. This defect-tracking tool is a web-based tool written in PHP that was created solely to track and manage all errors, issues, and defects that have been found throughout the project. The defect-tracking tool relied on a MySQL database for storing defect information. The tool makes managing defects simple and enables team members to determine the priority of reported defects and identify those that could delay the release of the project.

2.2.1.3.3 Test Plan for each SubteamFormal test plans and test procedures were designed for each subteam (see Appendix E) to create a formal and traceable way for every team member to test. Team members followed the test plans during the alpha testing phase. These test procedures outline how each subteam will fully test the K-12 Teaching Application Software and Support suite in future semesters.

2.2.1.3.4 Alpha TestingTo prepare the K-12 Teaching Application Software and Support for release, a formal procedure for testing and evaluation needed to be followed. Prior to spring 2007 there has not been any support for formal testing processes and all testing was done as ad hoc testing. Alpha testing drew the need for formal requirements, test plans, and then processes for testing and evaluation. Alpha testing was scheduled to span two weeks of

49

the semester. This phase of testing occurred as scheduled between February 19, 2007 and March 7, 2007.

The result of the alpha testing period was that a total of 44 defects were identified by the Ongo08 team and a total of 22 defects were resolved prior to the end of this phase. All high priority defects were corrected before the end of alpha testing. Outstanding medium priority defects were determined not to be critical to the basic functionality of the software. Low priority defects were minor issues in the software or features to implement in the future. Since beginning beta period there are still 22 outstanding defects outlined in Appendix A

Since the end of formal alpha testing, team members have done additional informal testing. As of the end of the semester, a total of 84 defects have been identified, and 60 have been resolved. All high priority defects have been resolved.

Each defect was documented using a web-based defect-tracking tool. Each defect was given a unique ID for reference purposes. In addition, the defect-tracking tool stored the following information for each defect: what application it was found in (MTSS, GW, USA, SASF, Other), what version of code the defect applies to, reporter comments, priority (low, medium, high), status (reported, assigned, in progress, fixed), who the defect was assigned to, the date the defect was assigned, and the date the defect was fixed. Detailed results of alpha testing may be found in Appendix A. This appendix documents both the reported defects that have been fixed and those that are still in progress.

2.2.1.3.5 Beta PeriodThe beta period began after the Ongo08 team completed alpha testing, and the suite has been released to teachers who have volunteered to offer feedback on the project. It is important to note that the participating teachers are identified as beta evaluators and not beta testers. The Ongo08 team has asked that they explore the K-12 Teaching Application Software and Support suite in their free time and has not requested that formal beta testing be performed at this time.

The beta period is considered the period of time when the beta evaluators are reporting defects and suggesting product improvements. The beta period was scheduled to begin on March 9, 2007, however due to availability of schools and difficulties confirming teacher contact information, the beginning of this phase was delayed until March 29, 2007. Throughout the beta period, the [email protected] email address will be used as the primary software support contact for beta evaluators. To date, there are no results or responses from beta evaluators to include in the status report.

2.2.1.3.6 Survey UsersA letter to selected teachers in the regional school districts has been drafted by faculty advisors of Ongo08 with the purpose of inviting them to test the Ongo08 production software. Letters were emailed by faculty advisors to participating teachers on March 29,

50

2007. The purpose of contacting teachers was to create a panel of educators who would be willing to test the production software and offer feedback.

2.2.1.4 End Product DocumentationThe Ongo08 team worked on producing end product documentation for future team members. Detailed documentation for a portion of the tasks for spring 2007 has been completed.

2.2.1.4.1 Project PlanAll members of Ongo08 were responsible for writing a portion of the project plan document. The project plan outlined the project goals and schedule for this semester. An unbound project plan for Ongo08 was submitted and completed by the team. The project plan was reviewed by faculty advisors and returned with comments and suggestions. Changes were made to the project plan as per suggestions by advisors. A final bound version of the project plan was submitted on February 27, 2007.

2.2.1.4.2 Weekly E-mail ReportingA member of Ongo08 was assigned the position of communications coordinator. His responsibility was to inform faculty advisors of project developments on a weekly basis via emails. Weekly status reports have been turned in to faculty advisors every Monday morning providing an overview of accomplishments from the previous week.

2.2.1.4.3 Presentation to Senior Design ClassThe Ongo08 team members contributed in creating two PowerPoint presentations for the first semester senior design students on February 13, 2007. Two practice sessions were held in order to address concerns about the presentation and be prepared to speak to the class. All members attended the practice sessions, and all thirteen team members were present for the presentation.

2.2.1.4.4 Project PosterThe project poster for the K-12 Teaching Application Software and Support was heavily restructured and updated for spring 2007. Due to previous poor project posters for Ongo08, this semester’s goal was to take new approaches and new designs and implement them into a refreshed project poster. The final version of the poster was submitted on February 27, 2007.

2.2.1.4.5 Status ReportThe status report for the K-12 Teaching Application Software and Support project was submitted on Friday, March 30, 2007. All members of Ongo08 contributed to writing sections of the report using the previous semesters’ status report as a template and the project plan and presentation to the senior design class as sources. The status report reflects current progress and identifies work accomplished.

51

2.2.1.4.6 Industrial Review PanelThe Industrial Review Panel presentation has yet to be completed. A presentation will be given on April 25, 2007. This presentation will be based on the feedback from the presentation to the first semester senior design class.

2.2.2 MTSSThis section contains an overview of the present accomplishments of the MTSS subteam.

2.2.2.1 Problem Solving AlgorithmTypically, the problem solving algorithm has been the primary focus of the MTSS subteam. Because testing took priority this semester, the time spent toward problem solving algorithm work was reduced. This semester, the problem solving algorithm has been formally defined. The goals of the PSA were outlined and an implementation method was determined. The method has been evaluated for feasibility and impact on the MTSS program as a whole. Implementation has begun in the form of creating walkthrough problems and storing them in the database and working on storing problems in the database as different file types. See Appendix F: Problem Solving AlgorithmDefinition for a more in-depth description.

2.2.2.2 Improved Feedback and InterfaceThe MTSS problem interface system has been evaluated and several desired improvements have been implemented. The team created a feedback system for students to report their confidence in how they performed on each MTSS problem. Students are now able to select one from a set of smiley faces to report how comfortable they were with their responses to questions. For problem walkthroughs, the tool requests student feedback at each step of the problem solving process as well as at the end of the problem. Currently the feedback is not stored anywhere, but will be incorporated into the future grade book System designed by the Framework team.

In addition, the MTSS subteam has updated the simple and advanced search feature for their software. Defects found in alpha testing have resulted in many corrections to story problems within the MTSS software.

2.2.2.3 File TypesAllowing different problem file types to be saved using the same MTSS tool greatly improves the effectiveness of the problem solving algorithm by allowing walkthroughs to be created and stored. Implementation is complete for allowing different file types within the structure of the MTSS problem creation tool, such as: problems, walkthroughs, and assessments (quizzes and tests). Currently both problems and problem walkthroughs may be created and are stored in the same database within the MTSS program. These files may be filtered using simple one-word headers within the file name. For example, a walkthrough file name would have the word ‘Help’ placed in front of every title to indicate the file contents. This allows for easy identification and separation of the files. Once headers are established, filters will be implemented into the search query to allow

52

for finding only problems, only quizzes, or only walkthroughs. This is expected to be fully functional by the end of the semester.

2.2.2.4 SurveyBecause the application is being released to users outside the development team, the MTSS team created an online survey to receive feedback about the entire application. The survey asks the teachers to rate various attributes of the application on a scale of 1 to 5. It also asks teachers if they would use the application in a classroom, and asks for additional features and enhancements they would like to see in the application. All requirements of the survey our team sought out to fulfill were completed.

2.2.3 GW and USAThis section contains an overview of the present accomplishments of the GW and USA subteam.

2.2.3.1 Collaboration with the Department of Curriculum and Instruction

The objective of this meeting with the Department of Curriculum and Instruction (C&I) was to gather information of how to improve the effectiveness and usefulness of the GW and USA applications. Previous semesters have focused on adding games as educational tools. Meeting with C&I provided valuable information that activities, quizzes, tests, and games could greatly increase the use, effectiveness, and intuitiveness of both GW and USA. After meeting with C&I it was also suggested to implement learning objectives and learning activities to the GW and USA applications.

Ideas such as path finding activities, landmark or capital searching, and quizzes on information stored in the GW/USA database were all discussed as possible enhancements to GW and USA. Among the ideas of enhancements, C&I also recommended to survey the intended users to determine what would provide the best results for their students. A survey will be sent to the software evaluators during the beta period to determine what they feel would be the best course of action for future additions to GW and USA.

2.2.3.2 Updated Help Pages for GW and USAPrevious semester teams developed and updated help pages for the GW and USA application. This semester the team created uniform and consistent help pages for both GW and USA. The new help pages offer step-by-step visual walkthroughs for each part of the application. They are in accordance with the latest version of software and are detailed enough to act as a substitute to the user’s manual. Each help page explains basic navigation and usage of each area, including information pages, comparison pages, and each game. Upon completion, a student can now find easy to understand help detailing every aspect of both GW and USA.

53

2.2.3.3 Improved random state generator in USAPreviously, the random state generator did not actually randomly select states as intended. Instead, it had a bias toward repeating the same selection. The random state generator algorithm has been fixed, and now the same state cannot be repeated for at least 20 tries.

2.2.4 SASFThis section contains an overview of the present accomplishments of the SASF subteam.

2.2.4.1 Documentation and Code StructureThe SASF subteam created up to date documentation for the code to allow team members to easily identify and locate project files as well as understand dependencies and interactions. The SASF subteam also created documentation for the grade book and defect-tracking tool.

2.2.4.2 Server MaintenanceThe SASF subteam created accounts for all levels of users. The subteam maintains accounts for guests, students, teachers, and administrators for testing purposes. The framework team also created accounts for each new member of the Ongo08 team and removed unused accounts that belonged to previous Ongo08 team members. In addition, sample teacher and student accounts were created for each school participating in beta evaluation so that they could have their own username and password when using the project software.

The server also contained portions of irrelevant data discovered this semester, which was either commented out or removed from the server. Additionally, within the database, entries for unknown registered users and unused SQL tables were removed. Also, the CVS repository had to be maintained. Specifically, new folders were added and user permissions were changed. Lastly, another necessary task involved in server maintenance was the migration of code from the development server to the release server prior to both the alpha test period and the beta period.

2.2.4.3 Grade Book ImplementationThe SASF subteam completed the requirements design for a functional grade book that records student’s scores. Although there was prior work completed toward a grade book, no previous grade book implementations were located on the project server. The grade book requirements that were developed this semester include recording student’s progress for individual problems, problem sets, quizzes, and tests. All of these records will be stored in the database. The SASF team has also identified what grade book privileges are associated with each kind of user and implement appropriate restrictions (see AppendixG: Grade Book Design). A simple prototype of the grade book was also created.

2.2.4.4 Security ImprovementsThe SASF team improved security such that third parties are unable to intercept unencrypted login names and passwords when a user logs in. Specifically, the login data

54

transferred between the client and server has been encrypted using a cryptographic hash function called MD5 (Message-Digest algorithm 5).

The SASF team researched and implemented some improved security measurements. The user passwords were encrypted using a cryptographic hash function called MD5 (Message-Digest algorithm 5). In addition, research was done on implementing Secure Socket Layer (SSL). SSL implementation would ensure the data exchanged from the client and server would be encrypted and difficult to intercept. SSL research began too late in the semester in order to implement it.

In addition, some pages within the application did not enforce the proper authorization level. For example, the MTSS homepage for administrators could be accessed by any level of user. This defect in the software has been corrected.

2.2.4.5 Instructions for “Guest” loginGuest accounts have been created for the entire K-12 Teaching Application Software and Support. Users who do not have an account may still login to the application, with a limited number of features, to test out the application. Instructions for using the guest account have been added to the login page of the application.

2.3 Future Required ActivitiesThis section includes information about what is required in terms of activities and deliverables for future sessions. Future activities are divided into separate semesters that each outline recommended work. Gantt charts are not included for work because the exact dates of each activity and deliverable should be decided by teams in future semesters. Estimated resources for future semesters should closely match the actual resources for this semester, which are located in section 3.1.3.2 of this document. Because the project is software-based, the team foresees no large expenses in future semesters.

2.3.1 All Future SemestersThe following activities are recommended for completion by each semester of this project:

Training Courseso Objective: To educate incoming team members about the project, the

technologies it uses, and its purpose.o Approach: Hold training sessions for the entire team. Sessions will cover

the project purpose, goals, technologies used, documentation requirements, and semester tasks.

o Results: To have a team that has a common understanding of the project and of the goals of the semester.

Code Cleanup and Documentationo Objective: To continue to improve the code layout as well as

understanding of new and existing code. In addition, user manual

55

documentation must be updated as needed and provided to users in future software releases.

o Approach: Review and improve code for better layout, performance, and understanding. Document new and existing code per the provided documentation guidelines. Each subteam should update the user manual whenever a software change is made that results in a change in the user interface or any aspect of the software that the end user should be familiar with.

o Results: More clear and complete code that can be understood from one semester to the next. The user manual will remain up-to-date with accurate instructions and screenshots.

Testingo Objective: To start a new test cycle every semester that will allow each

new feature to go through an alpha testing phase and a beta period.o Approach: Each semester will go through an alpha testing phase utilizing

the defect-tracking tool to report any current defects in the development server. During this phase, high priority defects will be fixed, there will be a code freeze, and code will be migrated from the development to the production server for release to the beta evaluators. This will begin the beta period, which will include more defect reporting and fixing within the development server, as well as any new defects reported by beta evaluators.

o Results: An ongoing test cycle for every release of the project and more stable and reliable code.

Supporting the Cliento Objective: To ensure the teachers and other intended users have reliable

access to support from the team.o Approach: The teachers will be able to contact the team via e-mail and the

online survey.o Results: Users that are comfortable with the stability and features of the

project. Review Future Activities

o Objective: To develop a clear understanding of what needs to be completed in the next semester.

o Approach: A final team meeting will be held to discuss a list of goals for the next semester.

o Results: A clear list of goals the team wants accomplished the next semester (see Appendix B).

2.3.2 Fall 2007 Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

New faculty advisors will be assigned to the Ongo08 project Grade book functionality integration with GW/USA and MTSS Research and design new games in GW/USA

56

Research and design game(s) for MTSS Problem solving algorithm implementation in MTSS Complete file types implementation in MTSS Continue contact with the Department of Curriculum and Instruction Release and test new features for the semester

2.3.3 Spring 2008 Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Finalize grade book and grade book testing Implement new games into GW/USA Implement new game(s) into MTSS Finalize the first version of the problem solving algorithm in MTSS Finalize and test file types in MTSS Continue contact with the Department of Curriculum and Instruction Release and test new features for the semester

2.3.4 Fall 2008Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Improve interface within the entire application Research and design new game for MTSS Release project to more schools Finalize games in GW/USA Continue contact with the Department of Curriculum and Instruction Release and test new features for the semester

1.10Current Project and End-Product StatusCurrently, each Ongo08 subteam is getting closer to completion of the applications and the release of the product to schools. The MTSS subteam has started designing and implementing its problem solving algorithm. They have also implemented functionality for adding new problems, and answering problems.

To complete the application, the MTSS subteam needs to finish implementing the problem solving algorithm. The MTSS subteam also needs to improve the feedback features when solving problems. Once these things are completed, MTSS is ready to release.

The GW and USA subteam populated a database with world and state facts. They also implemented an interactive world and state map that when clicked displays information about what was clicked. The GW and USA subteam has also implemented two games for USA.

To complete the applications, the GW and USA subteam needs to add additional functionality to improve the learning process and objectives. They also need to make the

57

application more appealing to the grade ranges that are targeted. Once these things are completed GW and USA are ready to release.

The SASF subteam created a database to store MTSS, GW, and USA application data. They also created and implemented a common theme that all other applications must adhere to in order to ensure consistency and compatibility. In addition, the SASF subteam has created a defect-tracking tool that allowed the Ongo08 team to efficiently track its defects.

To complete the applications, the SASF subteam needs to implement grade book functionality for the MTSS problems, GW, and USA games. They also need to improve security of the application, user login, and user registration. Another thing that needs to be completed is maintaining the server and database to clear out unused data. Finally, the SASF subteam needs to implement a guest user login to the application. Once these things are complete SASF is ready to release.

Overall the Ongo08 team needs to complete an in depth user manual to aid the users when using the product. Each of the subteams also needs to complete help pages for each of the applications to give the user a quick reference. Once the user manual, help pages, and each subteam is ready to release then the K-12 Teaching Application Software and Support project will be ready to release to the public.

1.11Recommendations for Continued WorkThe Ongo08 team has three options for this section:

1. Continue the project as originally envisioned which will ultimately be a commercial product for schools.

2. Altering the direction of the product by incorporating additional educational applications or tools or, altering the scope of the project.

3. Abandoning the project

At this stage in the project, option 1 is the best choice for the team. In the future, the Ongo08 team is going to continue the project as originally envisioned which will ultimately lead to a commercial product for school.

However, during the current and semesters, the Ongo08 team is focusing on third through sixth grade study materials in order to ensure the product will run smoothly on a small scale and that the team may make a successful product for a narrow target audience. After that, the Ongo08 team plans to extend the content of the study materials to all grades in the K-12 range.

During this semester, the Ongo08 team might not be able to finish the functions and interface of the grade book because it is the largest module of the application. Hence, the Ongo08 team will continue working on the grade book next semester. The Ongo08 team also will continue documenting all defects that are reported from beta evaluators and team members via the defect-tracking tool.

58

2 Documentation of Current Efforts and ResultsThis section is separated into five different components: project definition activities, research activities, design activities, implementation activities, and testing and modification activities.

2.1 Project Definition ActivitiesThe project definition activities section is divided into four parts: the overall team, MTSS subteam, GW and USA subteam, and SASF subteam.

2.1.1 Overall TeamProject definition activities for the team included outlining project goals for monthly meetings, training sessions, testing, documentation, and software release preparation.

The PHP/MySQL training sessions educated new members in PHP and MySQL programming languages. During these training sessions, Ongo08 team members were taught the basics of PHP/MySQL, shown examples of PHP/MySQL code, and introduced to standard code conventions and document formatting techniques used by the Ongo08 team. Code convention and document formatting education was initiated this semester in order to improve consistency within the project.

2.1.2 MTSSProject definition activities for MTSS subteam: weekly meetings, and reviewing the MTSS materials from the previous semesters. Additional project definition activities for the MTSS subteam included creating a problem solving algorithm document which outlined the overall approach used by the team and how it was to be implemented (See Appendix F: Problem Solving Algorithm ).

2.1.3 GW/USAProject definition activities for GW and USA subteam: weekly meetings, and reviewing the GW and USA materials from the previous semesters. The GW/USA subteam also created a requirements document this semester that clearly defined project goals and expectations. This document shall be referred to in semesters for project refinement and testing purposes.

2.1.4 SASFProject definition activities for SASF subteam: weekly meetings, and reviewing the SASF materials from the previous semesters. The SASF subteam also worked on defining the grade book design this semester. In order to do this, the subteam was required to identify users, their associated privileges, and the different data types that must be stored.

2.2 Research ActivitiesThe research activities section is divided into four parts: the Overall Team, MTSS subteam, GW and USA subteam, and SASF subteam.

59

2.2.1 Overall TeamNot applicable.

2.2.2 MTSSResearch activities for the MTSS subteam included enhancing the team members’ understanding of PHP, MySQL, HTML, and JavaScript. These preliminary research activities were necessary for the subteam to effectively evaluate the problem creation tool and improve upon the simple and advanced search functions within the MTSS application.

The MTSS subteam also participated in a meeting with Ann Thompson from the Department of Curriculum and Instruction in order to discuss future direction for the mathematical tool set. Ann Thompson encouraged the use of mathematical games as an alternative to problem sets in order to make learning more fun and engaging for students.

2.2.3 GW/USAAs well as researching PHP, MySQL, HTML, and JavaScript in order to write code for the quizzes and games, the GW and USA subteam researched new concepts that incorporate mathematical skills into geographical learning. The GW/USA subteam contacted Ann Thompson from the Department of Curriculum and Instruction for guidance as to the best approach available. Options considered for such an education tool included games, research tools, and interactive exploration activities that could be designed using the current database information.

2.2.4 SASFResearch activities for the SASF subteam include PHP, MySQL, HTML, and JavaScript research in order to design the grade book, the defect tracking tool, and correct defects. Additional research hours were spent on investigating the feasibility of using Secure Sockets Layer (SSL) cryptographic protocol to secure login and user registration tools. It was determined that certificate providers, such as VeriSign, would not be a feasible solution due to the expense of their service. An option that is still being investigated is the usefulness of creating the team’s own SSL certificate.

Additionally, the encryption used for sending password information in both the login tool and the user registration tool, which currently is in hex, was determined to be insufficient. The SASF subteam decided that using MD5 (Message-Digest algorithm 5), a widely used cryptographic hash function with a 128-bit hash value, would be a substantial improvement to software security in this project.

2.3 Design ActivitiesThe design activities section is divided into four parts: the overall team, MTSS subteam, GW and USA subteam, and SASF subteam.

2.3.1 Overall TeamNot applicable.

60

2.3.2 MTSSThe MTSS subteam made three major improvements to the software. First, the subteam refined the problem solving algorithm definition (see Appendix F: Problem SolvingAlgorithm ). MTSS also designed an improved feedback system, in the form of a set of smiley faces, which indicate how comfortable a student is with their answer. The third major improvement was the design of a method in which problem data files are saved. The team implemented a naming convention that imbeds the file type into the file name. This will allow for filtering of file types in the search query.

2.3.3 GW/USAThe Globey’s World and Uncle Sam’s America subteam designed a method to eliminate the chance that a state is selected several times within a short period in the USA games. Previously, a simple random number generator was used to select the next state for these games. While testing both Name that State and State that Flag, the team discovered that the same state may randomly be selected several times before cycling through other states. To prevent this from occurring, the subteam implemented a queue that kept track of the last several states and would not permit a state within this queue to be reselected.

2.3.4 SASFThe SASF subteam designed a web-based defect-tracking tool this semester. Previous semesters used a spreadsheet to document defects. This approach was clumsy and, because it was a common file for the entire team, there was no assurance that multiple team members would not attempt to update at the same time. If this were to occur, updates may be overwritten and lost. The defect-tracking tool allows the entire team to view, submit, and modify defect reports submitted by team members via a web-based interface. This tool also includes the ability to sort defects by attributes such as priority, date submitted, and status. The sorting method was implemented using AJAX technique (Asynchronous JavaScript And XML), a new technique for the second generation of the web (Web 2.0). This defect-tracking tool was mainly coded by Duc Ho.

The SASF subteam also designed a grade book framework this semester. The details of this design are located in Appendix G: Grade Book Design.

2.4 Implementation ActivitiesThe implementation activities section is divided into four sections: the overall team, the MTSS subteam, the GW/USA subteam, and the SASF subteam.

2.4.1 Overall TeamThe primary goals for the Ongo08 team were to test the K-12 Teaching Application Software and Support suite and release a working version to regional teachers of grades three through six for beta evaluation. The entire team worked together to test common functionality in the software, and specific test activities were done on a subteam basis.

61

2.4.2 MTSSMTSS worked on implementing the problem solving algorithm for several semesters and has continued into the spring of 2007. This task involves designing a problem solving algorithm that will enhance students’ problem solving skills. This will be accomplished by walking students through the problem solving process in four steps:

1. Identify important information2. Choose a strategy to solve the problem3. Solve the problem4. Reflect upon the answer

The MTSS subteam created a document that details the requirements and high-level design of the problem solving algorithm. This document is intended for faculty advisors and future team members to refer to.

In addition, the subteam implemented a problem feedback system for the MTSS application. The system adheres to the subteam’s design, referred to in section MTSS2.3.2, which allows students to select one of a set of smiley faces to represent their confidence in their answer. This system has been implemented to gather feedback at the end of a standard mathematical problem, but will be applied at each step of problem walkthroughs.

Finally, MTSS modified the search tool to incorporate the filtering of specific file types (problems, quizzes, and walkthroughs) as described in section MTSS2.3.2.

2.4.3 GW/USAThe primary implementation tasks for GW/USA were to update the help pages and improve upon the USA games. Recent changes have been made, both graphically and functionally, to USA and GW. Because of this, the help pages were updated to correspond to those changes. The Name that State and State that Flag games were upgraded to include a method that prevents the same state from being selected again within a short period of time (see 2.3.3).

2.4.4 SASFThe SASF subteam had four main implementation activities: the defect-tracking tool (see 2.3.4), the creation of a database for a grade book, security precautions, and creating guest user accounts and instructions. The defect tracking tool was fully implemented and used for alpha and beta testing activities. The grade book database design is nearly complete and the subteam is in the process of creating necessary tables. Security precaution research has resulted in the team deciding to use MD5 hash tables for improved encryption. Finally, a guest user account has been created so that unregistered users may experience the K-12 Teaching Application Software and Support suite.

2.5 Testing and Modification ActivitiesThe testing and modification activities section is divided into four parts: the overall team, the MTSS subteam, the GW/USA subteam, and the SASF subteam. The alpha test phase has been completed, and beta period testing activities will continue for the duration of the semester.

62

2.5.1 Overall TeamAspects of the project that were common to all applications were tested by the entire team. These testing activities included navigation and verifying appropriate user access based on user types. There is no overall team test plan; however, these common activities are outlined in each subteam’s test plan.

2.5.2 MTSSThe MTSS subteam tested the problem creation tool and database search tools. The subteam verified that the problem creation tool successfully creates mathematical problems and walkthroughs in the MTSS database. MTSS team members used the defect-tracking tool to report errors that were encountered while testing these tools. These defects are documented in Appendix A: Problems Identified. Many of the MTSS defects involved spelling or grammar errors within mathematical problems. Additionally, the subteam determined that the simple and advanced search functions query the database without any unexpected results or errors.

2.5.3 GW/USAThe GW/USA subteam tested navigation between different country and state pages, the USA games, and both the GW and USA comparison tools. Navigation between pages was tested by verifying that there were no dead or erroneous links. The USA games were tested by having team members spend time playing the games using the web-interface. Finally, the comparison tools went through rigorous testing which involved selecting and deselecting sets of states/countries of various sizes. Additionally, the different comparison options were tested to ensure they functioned correctly. The defects encountered during these testing activities are documented in Appendix A: ProblemsIdentified. The subteam is currently working on correcting a defect in the comparison tool that occurs intermittently when multiple states/countries are selected and then deselected.

2.5.4 SASFThe SASF subteam’s testing activities centered on evaluating the functionality of user login, logout, registration, and the tool to edit user information. SASF team member tested each of these from administrator, teacher, student, and guest user types. Additionally, the SASF subteam verified that users only are permitted access to the appropriate web pages within the software.

3 Resources and SchedulesThis section of the status report contains the personnel resource and financial requirements.

3.1 Resource RequirementsThe resource section is divided into three sections: personnel efforts, other expenses, and financial requirements. These sections include previous semester values, Spring 2007 semester estimates, and actual Spring 2007 data.

63

3.1.1 Personnel EffortsThe following sections contain tables that detail the estimated and actual personnel hours for twenty different tasks that were determined in the Project Plan for the Spring of 2007 semester. The semester tasks are:

Task 1: Problem Definitions Task 2: Training Task 3: Create User Manual Task 4: Code Clean Up Task 5: Software Testing and Evaluation Task 6: Task Transition Activities Task 7: Project Reports Task 8: MTSS Testing Task 9: MTSS: Problem Solving Algorithm Task 10: MTSS: Improve Feedback and Interface Task 11: MTSS: Implement File Types Task 12: GW/USA: Testing Task 13: GW/USA: Update Help Pages Task 14: GW/USA: Collaborate with the Department of Curriculum and

Instruction Task 15: Framework: Testing Task 16: Framework: Documentation for Code Structure Task 17: Framework: Ensure Login Security Task 18: Framework: Implement Grade Book Task 19: Framework: Guest Login Instructions Task 20: Framework: Server Maintenance

Following the Spring 2007 semester personnel effort data is a summary of hours reported in previous semesters for each subteam.

64

3.1.1.1 Estimated Personnel EffortsTable 5 is from the project plan and details the estimated hours for each task.

Table 5 - Estimated Hours for Project

3.1.1.2 Actual Personnel EffortsTable 6 details the actual hours that each team member logged for the semester tasks through the status report deadline.

Table 6 – Actual Hours for Project

3.1.1.3 Previous Semester Personnel EffortsTable 7 summarizes the hours that each subteam contributed toward the Ongo08 project. Hours are organized by semester and subteam. Note that Ongo08b and Ongo08c combined to form Ongo08b/c in the fall of 2005.

65

Table 7 – Previous Hours for Project

3.1.2 Other Resource RequirementsThis section outlines both the estimated and actual additional resource expenses for the Ongo08 team during the Spring 2007 semester.

3.1.2.1 Estimated Resource RequirementsTable 8 outlines the estimated expenses for the Spring 2007 semester excluding personnel costs. Because the Ongo08 project is a software project, the only expenses involved those related to producing required semester documentation.

Table 8 – Estimated Resource Costs

RESOURCE COSTBinding $5.00Copying $10.00Poster printing and lamination $30.00Total $45.00

3.1.2.2 Actual Resource RequirementsTable 9 displays the actual resource requirements for the semester. These costs are very close to the estimated values. The project poster altogether was the most expensive item, although the Computer Support Group (CSG) printed the poster at no charge. Costs were due to lamination costs and additional materials needed to mount the poster.

66

Table 9 – Actual Resource Costs

RESOURCE COSTBinding $5.00Copying $10.00Poster Design Print $0.00 (Provided by CSG)Poster Lamination $17.10Spray Mount $4.27Foam Poster Board $5.89Total $42.26

3.1.3 Financial RequirementsTable 10 summarizes the estimated financial budget for the Spring 2007 semester. The budget includes estimated labor costs based on the departmental undergraduate wage of $10.50/hour and the additional resource costs from Table 8. The actual financial requirements are shown in Table 11. The discrepancies between the estimated and actual financial requirements are due to both over-estimates in time commitments for various tasks or insufficient estimations for administrative tasks such as reviewing documentation.

The attributes of the both tables are:

Category: either the name of a subteam or an additional expense type

Item/Member: a description of the item or the name of a team member

Hours: the number of hours the team member spent for all semester tasks

W/O labor: expense of the item without in labor costs

With labor: expense of the item with labor costs

Following the estimated and actual semester financial requirements is a summary of financial requirements for all previous semesters.

67

3.1.3.1 Estimated Financial RequirementsTable 10 is taken from the Spring 2007 Project Plan and is an estimate of the project expenses for this semester.

Table 10 – Estimated Project Expenses

68

3.1.3.2 Actual Financial RequirementsTable 11 contains the project expenses based upon the actual hours in Table 6.

Table 11 – Actual Cost of Project

69

3.1.3.3 Previous Semester Financial Requirements summarizes the financial requirements from previous semesters. Financial requirements are listed first without labor expenses and then with labor expenses included.

Table 12– Previous Semester Financial Requirements

Semester W/O Labor With Labor

Spring 2002 $60 $10,195

Fall 2002 $60 $6,405

Spring 2003 $65 $16,233

Fall 2003 $65 $10,776

Spring 2004 $75 $15,834

Fall 2004 $75 $14,721

Spring 2005 $75 $15,907

Fall 2005 $30 $13,608

Spring 2006 $60 $12,678

Fall 2006 $45 $16,383

Total $610 $133,305

70

3.2 SchedulesThis section is divided into two categories: the project schedule, which includes the proposed and actual project schedules, and the deliverables schedule.

3.2.1 Project Schedules, the proposed project schedule, describes the planned duration and deadlines for each Spring 2007 semester task. Several tasks, such as project reporting, are ongoing and were expected to last throughout the semester. Actual duration and completion dates of the Spring 2007 semester tasks are detailed in Table 14.

Table 13 – Proposed Project Schedule

ID Task Name Duration Start Finish

1 Problem Definition 7 days Mon 1/15/07 Tue 1/23/07

2 Training 14 days Mon 1/15/07 Thu 2/1/07

3 Create a User Manual 47 days Thu 2/15/07 Wed 4/25/07

4 Continue Code Cleanup 72 days Mon 1/15/07 Wed 4/25/07

5 Softw are Testing and Evaluation (Total for #5)68 days Fri 1/19/07 Wed 4/25/07

6 Create a Test Lead Position 7 days Mon 1/22/07 Tue 1/30/07

7 Establish formal test procedures 14 days Mon 1/29/07 Tue 2/13/07

8 Alpha Testing 33 days Wed 1/24/07 Mon 3/5/07

9 Beta Testing 20 days Thu 3/29/07 Wed 4/25/07

10 Establish Formal Bug Documentation15 days Wed 1/31/07 Sun 2/18/07

11 Survey Users 20 days Thu 3/29/07 Wed 4/25/07

12 Task Transition Activities 11 days Mon 4/9/07 Mon 4/23/07

13 Project Reporting 72 days Mon 1/15/07 Wed 4/25/07

14 Semester Plan 11 days Wed 2/14/07 Tue 2/27/07

15 Status Report 33 days Mon 3/5/07 Wed 4/25/07

16 Weekly E-mail Reporting 77 days Mon 1/15/07 Wed 5/2/07

17 Poster 11 days Wed 2/14/07 Tue 2/27/07

18 Presentation to Senior Design Class17 days Wed 1/24/07 Tue 2/13/07

19 Industrial Review Panel 11 days Wed 4/11/07 Wed 4/25/07

20 MTSS: Testing 72 days Mon 1/15/07 Wed 4/25/07

21 MTSS: Problem Solving Algorithm 76 days Tue 1/9/07 Wed 4/25/07

22 MTSS: Improve Feedback and Interface13 days Sun 2/4/07 Mon 2/19/07

23 MTSS: Implement File Types 21 days Tue 2/13/07 Sun 3/11/07

24 GW/USA: Testing 72 days Mon 1/15/07 Wed 4/25/07

25 GW/USA: Update Help Pages 11 days Mon 2/12/07 Sun 2/25/07

26 GW/USA: Collaborate w ith Curriculum77 days Mon 1/8/07 Wed 4/25/07

27 Framew ork: Testing 72 days Mon 1/15/07 Wed 4/25/07

28 Framew ork: Documentation for Code Structure39 days Sun 2/4/07 Sun 4/1/07

29 Framew ork: Ensure Login Security24 days Sun 2/4/07 Sun 3/4/07

30 Framew ork: Implement Grade Book72 days Mon 1/15/07 Wed 4/25/07

31 Framew ork: Guest Login Instructions7 days Mon 2/5/07 Mon 2/12/07

32 Framew ork: Server Maintenance 72 days Mon 1/15/07 Wed 4/25/07

1/14 1/21 1/28 2/4 2/11 2/18 2/25 3/4 3/11 3/18 3/25 4/1 4/8 4/15 4/22 4/29 5/6

71

Table 14 – Actual Project Schedule

ID Task Name Duration Start Finish

1 Problem Definition 7 days Mon 1/15/07 Tue 1/23/07

2 Training 14 days Mon 1/15/07 Thu 2/1/07

3 Create a User Manual 47 days Thu 2/15/07 Mon 4/23/07

4 Continue Code Cleanup 72 days Wed 1/17/07 Wed 4/25/07

5 Softw are Testing and Evaluation (Total for #5)68 days Tue 1/23/07 Wed 4/25/07

6 Create a Test Lead Position 7 days Mon 1/22/07 Tue 1/30/07

7 Establish formal test procedures 14 days Mon 1/29/07 Tue 2/13/07

8 Alpha Testing 33 days Thu 1/25/07 Mon 3/5/07

9 Beta Testing 20 days Thu 3/29/07 Wed 4/25/07

10 Establish Formal Bug Documentation13 days Sun 2/4/07 Mon 2/19/07

11 Survey Users 20 days Thu 3/29/07 Wed 4/25/07

12 Task Transition Activities 11 days Mon 4/9/07 Mon 4/23/07

13 Project Reporting 74 days Mon 1/15/07 Wed 4/25/07

14 Semester Plan 11 days Thu 2/15/07 Tue 2/27/07

15 Status Report 33 days Tue 3/6/07 Wed 4/25/07

16 Weekly E-mail Reporting 79 days Mon 1/15/07 Wed 5/2/07

17 Poster 11 days Thu 2/15/07 Tue 2/27/07

18 Presentation to Senior Design Class17 days Wed 1/24/07 Tue 2/13/07

19 Industrial Review Panel 11 days Wed 4/11/07 Wed 4/25/07

20 MTSS: Testing 72 days Wed 1/17/07 Wed 4/25/07

21 MTSS: Problem Solving Algorithm 74 days Mon 1/15/07 Wed 4/25/07

22 MTSS: Improve Feedback and Interface13 days Sun 2/4/07 Mon 2/19/07

23 MTSS: Implement File Types 21 days Mon 3/19/07 Fri 4/13/07

24 GW/USA: Testing 74 days Mon 1/15/07 Wed 4/25/07

25 GW/USA: Update Help Pages 11 days Tue 2/6/07 Mon 2/19/07

26 GW/USA: Collaborate w ith Curriculum74 days Mon 1/15/07 Wed 4/25/07

27 Framew ork: Testing 66 days Thu 1/25/07 Wed 4/25/07

28 Framew ork: Documentation for Code Structure48 days Wed 1/24/07 Thu 3/29/07

29 Framew ork: Ensure Login Security29 days Sat 2/24/07 Sun 4/8/07

30 Framew ork: Implement Grade Book42 days Sat 2/24/07 Wed 4/25/07

31 Framew ork: Guest Login Instructions7 days Mon 2/5/07 Mon 2/12/07

32 Framew ork: Server Maintenance 74 days Mon 1/15/07 Wed 4/25/07

1/14 1/21 1/28 2/4 2/11 2/18 2/25 3/4 3/11 3/18 3/25 4/1 4/8 4/15 4/22 4/29 5/6

3.2.2 Deliverable ScheduleTable 15 is the schedule of deadlines for the semester’s primary documentation assignments and tasks. It includes the actual delivery dates for completed assignments and the anticipated delivery dates for remaining tasks.

Table 15 – Schedule of Deliverables

72

4 Closing MaterialsThis section concludes the Spring 2007 status report document for Ongo08. It outlines the lessons that the team has learned this semester, the team’s risk management procedures, and contact information.

4.1 Lessons LearnedThis senior design project has presented many challenges, obstacles, frustrations, and learning opportunities for the team members. By the end of the semester, team members had gained new skills and valuable experience. A brief summary of the team’s most valuable lessons follows.

What went well: Utilization of group meetings and presentations early in the semester to

introduce new members to the project goals, how to access project code, and the application functionality

Distribution of documentation tasks to ensure involvement of all team members

Identification and correction of defects Efficient assignment of reported defects to team members Effective resolution of all high priority defects during the alpha phase Delegation of coding and research tasks to familiarize team members with

project code Implementation of defect-tracking software

What did not go well: Consistency and compilation of documentation due to multiple authors Adherence to the proposed schedule for user manual creation due to

difficulties locating former user manual drafts Adherence to the scheduled beta period due to difficulties verifying teacher

contact information

Technical knowledge gained: PHP coding standards MySQL coding standards Source control tools such as CVS Security tools and encryption methods such as SSL and MD5

Non-Technical knowledge gained: Awareness of the value of project plan and semester schedule Methods of communication and collaboration between subteams Importance of detailed documentation for ongoing projects Mathematical problem solving methods applicable to third through sixth grade

students Educational methods applicable to third through sixth grade students, related

to geography

73

Necessity for standardized formatting in both code and documentation Usefulness of outlining a formal plan for work such as testing

4.2 Risks and Risk ManagementThis section describes the potential risks that were anticipated at the beginning of the semester. It contains anticipated and unanticipated risks that were encountered during the semester, and the resultant changes that were made to risk management.

4.2.1 Anticipated RisksBelow are the risks, and their corresponding management approach, that the team anticipated at the beginning of the semester.Risk: Loss of a subteam member due to an unforeseen eventMitigation: The additional workload associated with losing a subteam member may be

divided amongst the remaining subteam members for the remainder of the semester. The subteam member's logbook and notes would be reviewed by remaining subteam members to ease the transfer of the missing member’s work. If the above approach is not possible, a member from another subteam could be transferred to assist with the additional workload. As a preventative measure, all project activities will be thoroughly documented and no single team member will be solely responsible for any aspect of the project. Effectively, each team member will act as backup to another.

Risk: Destruction or loss of any portion of the software stored on the project serverMitigation: Because the project is entirely software-based, it is imperative that the

source files are secured. Access of the project files is limited to Ongo08 team members via user permissions on the Linux computer and all source code, supporting material, and related data will be backed-up on a regular basis. Backup copies of the source are stored on removable media (DVD-R, CD-R or tape) and stored safely off-site.

Risk: Content within the geography database becomes outdated or inaccurateMitigation: The database allows for the addition, removal, or modification content. In

the occurrence of information becoming irrelevant, the team can update or change it accordingly. In addition, the databases have associated repopulation tools that update the database with current information from reputable sources.

Risk: Internet access is unavailable to clientsMitigation: Schools will be informed that the software is Internet-based and an Internet

connection is required to use the software. Because the software may not be used without an Internet connection, schools that do not have an available Internet connection will be unable to use the software suite.

Risk: Undesired effects result from software updatesMitigation: Concurrent Version System (CVS) is used to provide archiving and version

tracking services, so an undesired version can simply be rolled back to its last correct state. Defect-tracking software will document what specific pages are

74

producing undesired effects in the software. This assists the team in reproducing defects and making corrections in an efficient manner.

Risk: Client requirements are changed from original specificationsMitigation: Clients will be informed of software capabilities. Additional requests will

be evaluated and incorporated into either current or future semester tasks if the project leaders and faculty advisors consider the addition feasible.

Risk: Testing methods for the software are inadequateMitigation: The test lead will review testing procedures each semester and testing

methodology will be redesigned in the event that current methods are determined to be insufficient. On Thu, 19 Apr 2007, it has been reported via the defect-tracking tool that we have 50 fixed defects out of 73, and all the high priority defects have been fixed successfully.

4.2.2 Anticipated Risks EncounteredNo anticipated risks were encountered during the semester.

4.2.3 Unanticipated Risks EncounteredThe user manuals from previous semesters were unable to be located on either the project server or the Ongo08 website.

4.2.4 Changes in Risk ManagementThe anticipated risks will still be applicable to future semesters. In addition, a new risk will be incorporated into the Ongo08 risk management policy.Risk: Previous semester documentation cannot be locatedMitigation: The team will contact faculty advisors in an attempt to locate a hard copy of

the desired document. In the event that the document still cannot be located, previous team members may also be contacted. In order to prevent this from occurring, each semester, documents will be uploaded to both the team’s CVS repository and the team’s website.

75

4.3 Project Team InformationThe following people and organizations were involved in the Ongo08 project during the Spring 2007 semester.

4.3.1 ClientAmes Community SchoolsAdministrative Offices1921 Ames High DriveAmes, IA50010Phone: 515-268-6600

4.3.2 Faculty AdvisorsDr. John Lamont Prof. Ralph Patterson, III 324 Town Engineering 326 Town Engineering Ames, IA50011-3230 Ames, IA50011-3230 Phone: 515-294-3600 Phone: 515-294-2428 Fax: 515-294-6760 Fax: 515-294-6760 [email protected] [email protected]

Dr. Gregory Smith350 Town EngineeringAmes, IA 50011-3230Phone: 515-294-1828Fax: [email protected]

76

4.3.3 CprE/EE 492 Team MembersMTSSAaron Menz Cameron Travers1306 Iowa Circle 307 Ash Ave.Ames, IA 50014 Ames, IA 50010515-491-0565 [email protected] [email protected] Engineering Computer Engineering

GW/USAJennifer Novak Todd Steffen1424 Nebraska Ave 127 South Franklin AveAmes, IA 50014 Ames, IA 50014515-231-1248 [email protected] [email protected] Engineering Computer Engineering

SASFErin Boggess Grant Eckels2415 Aspen Rd #103 4116 Fredericksen CtAmes, IA 50010 Ames, IA 50010319-430-4976 [email protected] [email protected] Engineering Computer Engineering

77

4.3.4 CprE/EE 491 Team MembersMTSSAmy Joines Adam Wise307 Ash Ave. Apt. #113 1232 Fredericksen CtAmes, IA 50014 Ames, IA 50010563-320-0750 [email protected] [email protected] Engineering Computer Engineering

GW/USASean Boyle Justin Brown2216 Fredericksen Ct 1115 Fredericksen CtAmes, IA 50010 Ames, IA 50010515-975-4808 [email protected] [email protected] Engineering Computer Engineering

SASFPaul Hartwell Duc Ho4720 Mortensen Rd Apt #302 169 University Village, Apt. HAmes, IA 50014 Ames, IA 50010402-709-3500 [email protected] [email protected] Engineering Computer Engineering

Nathan Taucher5328 Wallace NielsenAmes, IA [email protected] Engineering

4.4 Closing SummaryThe K-12 Teaching Application Software and Support team is developing web-based teaching software applications. The project includes a common framework that supports teaching applications. The project consists of three applications: Mathematical Teaching Software System (MTSS), Globey’s World (GW), and Uncle Sam’s America (USA). These applications provide students in grades three through six the opportunity to improve their computer skills while learning math and geography. MTSS emphasizes the teaching of core mathematical techniques and strengthen students’ mathematical problem solving skills. Globey’s World and Uncle Sam’s America provide interactive ways for students to learn both World and United States geography. In the future, these applications will be integrated with a grade book. Teachers and administrators will have access to student scores, which will help them customize lessons accordingly. Within each application, content may be varied in topic and difficulty at the teacher’s discretion.

78

4.5 ReferencesThe following websites were referenced while writing code and automating different tasks.

http://php.net/ - This site made it easy to look up PHP functions while writing code in PHP.

https://www.cia.gov/cia/publications/factbook/docs/faqs.html - This site was utilized in the automation of repopulating the Globey’s World database with current facts and statistics.

4.6 AppendicesThe following appendices contain defects discovered this semester, a feature list, project access instructions, project evaluation, test plans, problem solving algorithm design, and grade book design.

4.6.1 Appendix A: Problems IdentifiedThis appendix contains defects encountered during the alpha testing phase. The defects in Table 16 are separated by subteam and each entry contains the defect description, date discovered, who discovered it, and if the defect has been fixed.

Table 16 – Problems Identified

MTSS ProblemsDescription Date Found Found By FixedHyperlinks are blue rather than bold white on the left side of the about pages for student, teacher and admin pages

2/27/2007 Aaron Menz Yes, no comment.

The student search page, the teacher search page, the teacher edit page, and the teacher delete page all have different versions of the search ability. Uniformity would be nice.

2/27/2007 Aaron Menz Yes, no comment

Two of the categories for the concept types for fractions are substraction (which should be spelled subtraction).

2/27/2007 Aaron Menz Yes, the misspelled database entry was modified.

Wording on the individual MTSS problem could be changed to “He plans to plant 1/5 of his field with potatoes” instead of “He plans 1/5th of the yard for potato planting.”

2/27/2007 Aaron Menz Yes, changed the text stored into the database (hard coded)

79

This is my solution to the Potato Yard Problem: Q A Score Correct Solution 1 .8 0.00/1.00 4/5 2 .6 0.00/1.00 3/5 3 .4 0.00/1.00 2/5 4 .2 0.00/1.00 1/5 Total 0.00/4.00 As you can see I got it all wrong but my answers were all correct. We need to address the multiple inputs problem, I know we have talked about it in previous presentations to class and panels, but we never actually got to it. Is this a framework thing?

2/27/2007 Aaron Menz Yes, this should be included in our long-term plans for MTSS, not a minor defect.

New pictures uploaded as part of the teacher create feature do not get stored to the development server. For example in this problem Test: Triangle Area, has picture file: p0000203.gif, which does not exist and the maximum picture file number is 175, which was probably added quite some time ago, CVS says last modified (February 14, 2006 6:35:31 PM) Possible causes: files never uploaded different picture formats other than .gif may not be supported (although the smiley faces are jpgs) picture storage directory issue on the webpage pictures not CVS-ed?

2/27/2007 Aaron Menz In Progress, the directory name to which it is storing is not correct, need to look at teacher create or possibly problem display.

Received PHP error: Warning: Invalid argument supplied for foreach() in /var/www/html/application/mtss/ teacher/problems/editproblem.php on line 413 when trying to edit problem (name : test )

2/27/2007 Aaron Menz Yes, simply a test problem, it was deleted.

80

When someone deletes a problem, there is a broken image link on the page http://ongo8d.ece.iastate.edu/application/mtss /teacher/images/success.gif believe it should be http://ongo8d.ece.iastate.edu/application/mtss/images/success.gif as there is an image called success in the image directory of MTSS but cannot open if from Eclipse, nor does it work if you copy it to PC and try to open it: Windows Picture and Fax Viewer says (Drawing failed.) So, it is both a broken link and a dead picture.

2/27/2007 Aaron Menz Yes, utilityfunction displayerror was referencing the image file from the wrong location (they were moved from separate folders to a single folder)

Example Fraction Problem About Pizza -> says cannot find file, but if you look at p0000001.txt (the very first problem ever for this application); it contains all of the text of the problem. Something is not correct in the database lookup.

2/27/2007 Aaron Menz Yes, code was old and query feature has changed a lot. Deleted the broken link to the problem fixed it.

MTSS: edit/create-> generate preview does not render the help smiley faces

3/3/2007 Aaron Menz Yes, previews now generate “Feedback Mechanism”

Something to think about: Do we have a way of easily moving the problems teachers will create back to the development server?

2/28/2007 Aaron Menz Yes, this is a database question and should be directed more towards framework. Not really a defect.

On the navigation bar, the logout link text is blue, and it should be white

2/28/2007 Aaron Menz Yes, simple code fix.

On the navigation bar on the left, on a mouse rollover, the links change color and the text changes to bold. The color change is correct, but the text font should not change to bold. This is the only page where this is done.http://ongo8d.ece.iastate.edu/application/mtss/teacher/about/

2/28/2007 Amy Joines Yes, simple code fix.

81

On the navigation bar on the left, after a mouse rollover, the Homepage link text color turns to blue. It should be white.http://ongo8d.ece.iastate.edu/application/mtss/student/about/

2/28/2007 Amy Joines Yes, simple code fix.

Description text field, Grades check boxes, and the And/Or radio buttons current states are not preserved when changing from Simple to Advanced Search and vice versa. However, the matching/do not care radio button feature is preserved from search method. This may be intended depending on the design documentation, though is unlikely.http://ongo8.ece.iastate.edu/application/mtss/student/problems/searchproblem.php

3/2/2007 Adam Wise Yes, switching between simple and advanced states now retains your features until the search button is clicked which then clears the fields.

Simple and Advanced Searches always return to a simple search upon completion and never retain the text field value prior to the search. This may be intended depending on the design documentation.http://ongo8.ece.iastate.edu/application/mtss/student/problems/searchproblem.php

3/2/2007 Adam Wise Yes, fixed.

Topic and Concept drop-down boxes can have depopulated fields when switching to advanced search after completing either simple and advanced searches. (Same page as previous)

3/2/2007 Adam Wise Yes, simple code fix.

Searching is not able to occur a second time after an initial search result set is returned.http://ongo8.ece.iastate.edu/application/mtss/student/problems/searchproblem.php

3/2/2007 Adam Wise Yes, utilized warnings generate to figure out what lines of code to investigate.

82

There is a limit to the number of characters that can be typed in a text box (of course), but this limit is small, and trying to recreate an old broken problem from the source txt files and the question is too long. Amy should address this in her help pages regarding software limitations.

3/3/2007 Aaron Menz Yes, this issue is discussed in the help pages and will also be included in the user manual.

Everybody (guest, student, teacher, admin) can access that page after they log in.http://ongo8d.ece.iastate.edu/application/mtss/admin/

3/5/2007 Alex Ho In Progress, each page is supposed to authenticate before doing anything else. Problem in the verifying user.

Too many head and body tags in the source code cause an error message on the status bar: "Done, but with errors on page".

3/6/2007 Alex Ho No

When using advanced search after the first search causes the "Concept" tab to not be repopulated. Related to previous fixed defect

3/6/2007 Aaron Menz No

Currently: MTSS is a software system designed to help students grades three through six develop their problem solving skills by providing practice problems and quizzes. Needs to be: MTSS is a software system designed to help students IN grades three through six develop their problem solving skills by providing practice problems and quizzes.

4/5/2007 Dr. Smith Yes, changed for student, teacher, and admin.

Screenshots in Solve Help are blurry. New non-blurry screenshots should be inserted.

4/5/2007 Dr. Smith No

“Do not care” button doesn’t do anything if you have included text in the search box: it will search by that critera EX: box="hi" button="do not care" 2 results: 1) Chicken Pot Pie 2) Thirsty For More"

4/5/2007 Dr. Smith No

83

It seems like the problem creation feature is broken again."Warning: fopen(/var/www/html/application/mtss/shared/tempfiles/p034c3bb48e5ce7ff9ebce88a7f11e660.txt): failed to open stream: Permission denied in /var/www/html/application/mtss/shared/problemclass.inc on line 409"

4/9/2007 Aaron Menz Yes, Grant fixed this problem by modifying the server permissions per Aaron’s request.

After performing a search, the show information buttons do nothing. This is probably related to the multiple tags, the multiple event handlers and the inconsistant javascript loader


When searching with just the default values, it says no results to query found, BUT if you do supply a search string then it can find the problems easily. Only applies to teacher solve search, edit search works fine as does admin solve & edit.


Page title uses CENTER tag. CENTER is depreciated in HTML 4.0, so will want to change this.

https://ongo8d.ece.iastate.edu/appapplicat/mtss/teacher/problems/crecreateprob.php

4/18/2007 Erin Boggess Yes, removed the depreciated center tag, added align=”center” to div tag around title.

No starting tag found for: “dive”, or it was closed too many times. Line 47.

http://ongo8d.ece.iastate.edu/test/bugreport/mtssteachersupportindex.php

4/18/2007 Erin Boggess Yes, removed extra div tag in file.

Title and first image use CENTER tag. This is deprecated and should be changed in file.

http://ongo8d.ece.iastate.edu/test/bugreport/mtss/teacher/problems/solvesearchproblem.php

4/18/2007 Erin Boggess Yes, removed the depreciated center tag, added align=”center” to div tag around title.

84

Empty DIV and FONT tags found in this file.

http://ongo8d.ece.iastate.edu/application/mtss/help/index.php

4/18/2007 Erin Boggess Yes, removed empty tags.

If I try to create a problem, but don't enter anything (just go straight to the preview), the next page has a broken image on it. The URL for the image is: http://ongo8d.ece.iastate.edu/application/images/noresponse.gif This might not exist anymore, or the link points to the wrong address.

http://ongo8d.ece.iastate.edu/application/mtss/problems/previewproblem.php

4/18/2007 Erin Boggess No, if this file isn't used anymore, we should change the permissions on it so that a user won't accidently access it.

MTSS Create/Edit/Delete/Solve pages: Some of the MTSS files are missing this CSS link in the header: "link rel="stylesheet" href="./shared/commonstyles.css”

http://ongo8d.ece.iastate.edu/application/mtss/problems/editsearchproblems.php

4/18/2007 Erin Boggess No, we should probably go ahead and change permissions on the problems directory so that users cannot access these files from the Internet - especially if they are outdated.

"Suggesting Improvements" should be a separate line. Right now it falls at the end of a bullet in the previous section. (occurs about halfway down the text).

http://ongo8d.ece.iastate.edu/application/mtss/admin/support/

4/18/2007 Erin Boggess No

Should not be able to close this window. This must have been a pop-up at one point... Need to get rid of this button on all preview problem pages.

http://ongo8d.ece.iastate.edu/application/mtss/problems/previewproblem.php


85

Found this on the admin page - it's might be the same for teachers. The "Uncheck All" and "Delete" buttons are disabled. There is no reason for "Uncheck All" to be disabled. If no delete functionality exists, there should probably be some kind of error message that pops up if the user clicks the button (instead of disabling it)...

http://ongo8d.ece.iastate.edu/application/mtss/admin/problems/searchresults.php


In the instructions, the bullet "The default settings of the form returns all the problems in the database." should be on one line, not two. There might be an extra return here or something.

http://ongo8d.ece.iastate.edu/application/mtss/student/problems/searchproblem.php


"File last modified" text at the bottom of the page is not aligned correctly. Should be aligned with the horizontal rule above it in a similar fashion to other pages.

http://ongo8d.ece.iastate.edu/application/mtss/student/support/


Globey’s WorldWhen adding and removing many countries to and from the compare field, the field no longer displays what is selected in the "Countries to Compare" field.http://ongo8d.ece.iastate.edu/application/gw/comparison/

2/20/2007 Todd Steffen Yes, the problem was in the sorting algorithm, fixed with the help from Paul.

86

The country image is reversed for North and South Korea. All information is correct; the countries' maps just need to be switched in the database.http://ongo8d.ece.iastate.edu/application/gw/countrypage/index.php?id=162

3/4/2007 Todd Steffen Yes, fixed the map and flag numbers. Replaced the “Interesting Places” for South Korea as well.

Comparison pages are not consistent. Should have a warning message pop-up when you try to compare 0-1 countries, or more than 10 countries. Currently, there is no messages in GWhttp://ongo8d.ece.iastate.edu/application/gw/comparison/

3/4/2007 Todd Steffen No

The name of the country Cote d'Ivoire is supposed to have a ^ over the o, but the page puts a question mark instead of the ^o.http://ongo8d.ece.iastate.edu/application/gw/countrypage/index.php?id=102

3/5/2007 Sean Boyle No

There is a list of countries that have a literacy rate of 0%. This can be found here: http://boyles30.public.iastate.edu/lit0.pdf This should probably be corrected sometime in the future. http://ongo8d.ece.iastate.edu/application/gw/countrypage/index.php?id=41

3/5/2007 Sean Boyle No, code needs to check if the value is a zero and print off “N/A” instead.

Remove large space between title: Globey's World Comparison Page, and the information also make GW, and USA comparison pages look consistent

http://ongo8.ece.iastate.edu/application/gw/comparison/

4/5/2007 Justin Brown Yes, fixed.

87

/BODY tag falls before content! It's also repeated at the end of the file.

http://ongo8d.ece.iastate.edu/application/gw/comparison/

4/18/2007 Erin Boggess Yes, replaced tag with correct BODY tag.

It looks like there is an extraneous "Globey's World" at the bottom of the page.

http://ongo8d.ece.iastate.edu/application/gw/help/regionhelp.php

4/18/2007 Erin Boggess Yes, commented out header code at the bottom of the page.

Extra "2006 Globey's World" at the bottom of page.

http://ongo8d.ece.iastate.edu/application/gw/help/worldhelp.php

4/18/2007 Erin Boggess Yes, commented out title in code.

Bullets should not be full sentences here. Rewrite if necessary and remove the period from the end of the bullet. This should be repeated for the index page and all help pages.

http://ongo8d.ece.iastate.edu/application/gw/help/

4/18/2007 Erin Boggess Yes, fixed this bug as well as other consistency issues.

Atlantic Ocean: Number of Regions: Not available at this time Should say N/A like the other fields.

http://ongo8d.ece.iastate.edu/application/gw/countrypage/index.php?id=198

4/18/2007 Erin Boggess Yes, updated DB to say “N/A”

Kingman Reef: Population: \uninhabited (July 2002 est.) Remove \

http://ongo8d.ece.iastate.edu/application/gw/countrypage/index.php?id=234

4/19/2007 Erin Boggess Yes, removed in population field.

88

Department of Reunion: Bodies of Water: N\A Should be: N/A

Kingman Reef: Population: \uninhabited (July 2002 est.) Remove \

4/19/2007 Erin Boggess Yes, problem was in the code, not the database.

USAState Info help page – 5th bullet – says ‘Below the map is lots of information about this state.’ There should be more info provided. Maybe it could say each of the main sections that are talked about for each state. (Facts and Figures, Economy, Geography, Political, Population)

2/26/2007 Sean Boyle Yes, added additional information to the help page.

The following States are missing data in the Surrounding States: Wyoming, Wisconsin, West Virginia, Washington, Virginia, Vermont, Maryland, Indiana

2/21/2007 Sean Boyle Yes, the data was added to the database.

The following States are missing data in the National Park Field: Wisconsin, West Virginia, Vermont, South Carolina, Rhode Island, Pennsylvania, Oregon, Oklahoma, Ohio, North Dakota, North Carolina, New York, New Mexico, New Jersey, New Hampshire, Nevada, Maryland, Maine, Louisiana, Kentucky, Kansas


The following States are missing data in the Airport field: West Virginia, Utah, Texas, Tennessee, South Dakota, South Carolina, Rhode Island, Pennsylvania, Oregon, Oklahoma, Ohio, North Dakota, New Hampshire, Nevada, Maryland, Maine, Louisiana, Kentucky, Kansas, Indiana


89

The following States are missing data in the Governor: Pennsylvania, Oregon, Oklahoma, Ohio, North Dakota, North Carolina, New York, New Mexico, New Jersey, New Hampshire, Nevada, Maryland, Maine, Louisiana, Kentucky, Kansas, Iowa, Indiana, Connecticut, Colorado, Arkansas, Arizona, Alaska, Alabama


The state of Texas has its cities over 100,000 displayed weird

2/21/2007 Sean Boyle Yes, a bunch of <br> tags used to separate the cities in the DB and the last half of the cities were missing the tags.

When the State of Nevada is used to Compare Highest Point, it returns a Negative Value

2/21/2007 Sean Boyle Yes, when the highest point and lowest point data is entered into the database the location comes first and then the elevation is separated by a semicolon. The Nevada had a - separator instead of a semicolon so it was reading it as a negative number.

Whenever a state with a negative elevation is shown, the graph does not readjust properly.

2/26/2007 Sean Boyle No, comparing with what is in Globey’s World.

Change State Info to State, listed as State info in multiple places. (country, world, region, all aren't listed with info after it, so this again is a consistency issue)

http://ongo8.ece.iastate.edu/application/usa/stateinfo/

4/5/2007 Dr. Smith Yes, fixed.

90

Current: If you guess wrong, the flag that belongs to the state you clicked will appear in red text above the map on the right along with the number of tries you have left. The flag you are trying to state will still be on the left.

SHOULD BE: If you guess wrong, the flag that belongs to the state you clicked will appear in red text above the map on the right along with the number of tries you have left. The flag you are trying to GUESS will still be on the left.

http://ongo8.ece.iastate.edu/application/usa/help/gamehelp.php

4/5/2007 Dr. Smith Yes, fixed.

Extra "Uncle Sam's America" at bottom of these help pages

http://ongo8d.ece.iastate.edu/application/usa/help/countryhelp.php http://ongo8d.ece.iastate.edu/application/usa/help/statehelp.php

http://ongo8d.ece.iastate.edu/application/usa/help/comparehelp.php http://ongo8d.ece.iastate.edu/application/usa/help/gamehelp.php

4/18/2007 Erin Boggess Yes, commented out the header line at the bottom of each page.

Bullets should not be full sentences here. Rewrite if necessary and remove period. This must be repeated for the index page and each help page.

http://ongo8d.ece.iastate.edu/application/usa/help/

4/18/2007 Erin Boggess Yes, fixed this bug, as well as other consistency issues.

91

Washington D.C. or District of Columbia is accessible from the Country page by clicking on the star or "Washington D.C.", but it does not appear in the drop down list on state pages. I know it's not a state, but a student should still be able to select it from a list if they can't find it on the map.

http://ongo8d.ece.iastate.edu/application/usa/country/

4/19/2007 Erin Boggess Yes, added “DC” to the drop down menu.

On the District of Columbia page, there is a broken image for the flag. The URL that is given for the missing image is: http://ongo8d.ece.iastate.edu/application/usa/img/flags/DC_fl.gif. There is a DC flag, this may need to be added to the project and the database updated manually.

http://ongo8d.ece.iastate.edu/application/usa/stateinfo/index.php?state=DC

4/19/2007 Erin Boggess Yes, found one at this website http://flagspot.net/flags/us-dc.html.Added to flags source folder under usa (DC_fl.gif)

DC is missing most of its data. This will probably have to be entered manually. Here is one reliable source you can get some of the information from: http://about.dc.gov/about.asp

http://ongo8d.ece.iastate.edu/application/usa/stateinfo/index.php?state=DC

4/19/2007 Erin Boggess Yes, added to the database.

FrameworkAn error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use here... It looks like the defect reporting tool fails if you include quotation marks in the description (not sure if it is single quote or double quote or both that causes failure)

2/27/2007 Aaron Menz Yes, added addslashes($string) when storing into the database and stripslashes($string) when retrieving information.

92

Using this defect reporting utility: Application of Defect (MTSS) [maybe doesn’t matter which application] -> Type of Error[OTHER]: Does not work "Unknown column 'Other' in 'field list' "

2/28/2007 Aaron Menz Yes, the value of [OTHER] was spelled as ‘vlaue’... This caused the web page not to recognize the string OTHER as its value rather than 7.

When attempting to create any of the 6 user types from an administrator account (Section 2.1 of framework test plan), I was unable to do so. I filled in all the necessary fields and upon clicking Create User. This error occurred: The requested URL /users/register/register.php was not found on this server. After looking on eclipse to see if this file exists, I found it does not.

3/5/2007 Paul Hartwell Yes, file referenced incorrectly.

When testing 2.2.1 of framework test plan, the password would change when the password hint was there, but the hint itself was not updating, it would always say, "the password is admin"... The password does change this is why it is low priority. Was behaving this way with both admin and teacher instances.

3/5/2007 Paul Hartwell Not a defect, misinterpreted password hint purpose.

Teacher and Student logins were set up using an incorrect password. Teacher evaluators cannot log in to the software. Database issue...

http://ongo8d.ece.iastate.edu/

4/4/2007 Erin Boggess Yes, Alex helped me determine the encryption method and we were able to resolve the issue. All teacher/student logins work correctly now.

The only user type that has a student ID should be student. The student ID field should be disabled if the user has selected any other user type because it is not applicable.

http://ongo8d.ece.iastate.edu/users/register/


93

Button should be "Update" or "Submit", not "(U)pdate"

http://ongo8d.ece.iastate.edu/users/maintainUser/

4/18/2007 Erin Boggess Yes, changed text.

4.6.2 Appendix B: Feature ListAppendix B is the matrix of features already completed, to be completed this semester, and required in future semesters. lists the feature, which subteam(s) it applies to, and its target date for completion. , , and Table 20 contain feature requests specific to each subteam have been considered for future development.

Table 17 – Feature List

FEATURE LIST MTSS GW USA SASFTARGET DATE

Adding additional registration fields (class, teacher, etc.) N/A N/A N/A L Spring 2007

Application removing JavaScript L L L N/A Spring 2007

Automatic database updating N/A M M N/A Complete

Cleaning server file system M M M M Ongoing

Code reviews / fix H H H H Ongoing

Database repopulation N/A M M N/A Complete

Documentation update H H H H Ongoing

Evaluate Initial Release Feedback H H H H Spring 2007

Find electronic database of USA data N/A N/A M N/A Complete

Games N/A M M N/A Fall 2007

Grading functionality creation N/A N/A N/A H Fall 2007

Grading functionality implementation L L L N/A Fall 2007

Grading functionality testing L L L M Fall 2007

Large-scale testing M M M M Spring 2007

Math problems L N/A N/A N/A Ongoing

Off-site backup management N/A N/A N/A L Ongoing

Operational environment research (school visit) L L L L Spring 2007

Prioritize feature matrix N/A N/A N/A M Ongoing

94

FEATURE LIST MTSS GW USA SASFTARGET DATE

Problem solving algorithm H N/A N/A N/A Spring 2007

Providing uniformity H H H H Ongoing

Quizzing and problem data migration H N/A N/A N/A Fall 2007

Quizzing functionality creation N/A N/A N/A M Spring 2007

Quizzing functionality implementation M M N/A H Spring 2007

Quizzing functionality testing M L N/A H Spring 2007

Securing authentication N/A N/A N/A L Fall 2007

Software Release H H H H Spring 2007

Globey’s World map changes N/A L N/A N/A Complete

User Manual H H H H Spring 2007

User progress tracking L L L H Spring 2007

Outline for Development/User Maintenance Manual M M M M Complete

Graphical representation of score distribution N/A N/A N/A M Fall 2007

Quizzing functionality creation N/A N/A N/A M Spring 2007

Priority Key: L=Low, M=Medium, H=High, N/A=Not Applicable

Table 18 – MTSS Requested Features

MTSS

Students should have a list rather than searching problems

Dropdown list for problems button

No way for a student to chart his or her progress or check grades again.

Cover more subjects in the creating problems list, currently only geometry and fractions perhaps make user defined

No way to return to page you were on after clicking feedback without going 'Back' or going somewhere else first

95

Table 19 – GW Requested Features

GW

I do not know if it is clear within the “Region” page that they need to push the button for “Select New Country” once they have selected from the drop-down menu. I do not know if it would be better to say “Go to New Country” or something else instead. Really, this one is not that big of a deal probably.

Perhaps there should be links at the bottom of country fact sheets that would return the user to the top of the page without so much scrolling.

What are the stars? For example, in the “United Kingdom” page under “Number of Regions,” it says: England - 47 boroughs, 36 counties*, 29 London boroughs**, …

Add help pop-up window

Some entries still incomplete in database, e.g. Number of Regions under “Ukraine”

Table 20 – USA Requested Features

USA

Is there really a need for small, medium, large chart sizes on the compare page? It seems like it would look better and make better use of space only allowing a large chart size. Unless there’s another reason for small, medium charts that I do not under

US map also contains other cities; do we want these or just keep to capitals?

Name that State is not colorful. Maybe add the ability to show what state it was?

Several flags are too small for the text to be read.

Suggestion for another game – display the outline of a state and a list of five state names that include the correct state and four others chosen randomly, bus displayed alphabetically, and ask user to identify correct state.

Ref “Games” in USA: No running stats; i.e., 4 out of 6 correct. Or perhaps elapsed time.

Scrolling in USA: quite a lot of scrolling is required, even at 1024 x 768, especially inGames. Could some be eliminated, or at least reduced, by shrinking maps, etc.?

The flags shown are pretty small. I also think they could be centered or otherwise formatted differently to make the page layout look more professional (maybe cut down on white space?).

4.6.3 Appendix C: Accessing the ProjectAppendix C contains brief instructions on how to log into the CVS repository to access the Ongo08 project development code for users with a login and password.

96

From UNIX (Mac, RedHat, etc): Open a terminal and type “ssh [email protected].” Enter your password. From Windows: Download Putty, which you can do at the site

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Set the server to ongo8.ece.iastate.edu.

Accessing the Code To access the code you need to download Eclipse or any other CVS code

manager. Eclipse is available at http://www.eclipse.org/downloads/index.php. After it is all installed go to File -> New Project -> CVS -> Create new location.

Fill in the following: Host: ongo8.ece.iastate.edu Path: /cvs User: username Pass: password from above Connection Type: extssh (use default port)

Once it all connects, you want to “Use existing module” and pick the application you want to work on (GW, USA, or MTSS).

97

http://ongo8.ece.iastate.edu/

http://www.eclipse.org/downloads/index.php

http://ongo8.ece.iastate.edu/

mailto:[email protected]

4.6.4 Appendix D: Project EvaluationAppendix D consists of tables for the overall team and each subteam that contain the team’s self-evaluation.

Table 21 – Overall Team Evaluation

Milestones Relative Importance

Evaluation Score

Resultant Score

Project Definition 5% 95% 4.75Training Courses 10% 100% 10User Manual 10% 75% 7.5Code Cleanup 10% 80% 8Software Test and Evaluation 50% 90% 45Project Reporting 10% 95% 9.5Outline Future Activities 5% 100% 5

Total 100% 89.75Passing Score 80 points

Table 22 – MTSS Evaluation

Milestones Relative Importance

Evaluation Score

Resultant Score

Problem Solving Algorithm 20% 70% 14Improved MTSS Feedback 15% 95% 14.25MTSS File Types 5% 50% 2.5MTSS Specific Testing 50% 90% 45MTSS Updated Help Pages 5% 100% 5MTSS Revised Search Pages 5% 95% 4.75

Total 100% 85.5Passing Score 80 points

98

Table 23 – GW/USA Evaluation

Milestones RelativeImportance

EvaluationScore

ResultantScore

Meet with C&I 10% 85% 8.5Update GW/USA Help Pages 5% 100% 5GW/USA Specific Testing 50% 90% 45GW\USA Explore Future Activities and Games

10% 70% 7

Requirements Document Creation 10% 95% 9.5Test Procedure Documentation 15% 95% 14.25Total 100% 89.25

Passing Score 80 points

Table 24 – SASF Evaluation

Milestones RelativeImportance

EvaluationScore

ResultantScore

Create Documentation for Code Structure 5% 70% 3.5Server and Account Maintenance 15% 95% 14.25Grade book Implementation 15% 70% 10.5Security for Login/PW and User Registration

5% 50% 2.5

SASF Specific Testing 40% 90% 36Instructions for Guest Login 5% 100% 5Identify unused portions of Database 5% 80% 4

Defect Tracking Tool Implementation 10% 100% 10Total 100% 85.75

Passing Score 80 points

4.6.5 Appendix E: Subteam Test Plans

4.6.5.1 MTSS Test Plan

4.6.5.1.1 Functional testingThe following sections intend to ensure that the basic functionality of the MTSS software is working correctly.

4.6.5.1.1.1 Homepage TestsVerify navigational bar links are functional and link to the appropriate pages.

99

4.6.5.1.1.2 Navigational Bar TestsVerify links are functional and link to the appropriate address/e-mail.

4.6.5.1.1.3 Problems Page Tests

4.6.5.1.1.3.1 Student Page: Verify links are functional and link to the appropriate address.

4.6.5.1.1.3.2 Teacher Page

4.6.5.1.1.3.2.1 Verify links are functional and link to the appropriate address.

4.6.5.1.1.3.2.2 Verify each link is only visible with a level of permission higher than a student.

4.6.5.1.1.4 Home Page TestsNo testing required. Help pages were updated and edited at the beginning of the semester.

4.6.5.1.1.5 Support Page TestsVerify links are functional and link to the appropriate address/e-mail.

4.6.5.1.1.6 About MTSS Page TestsVerify information is up-to-date.

4.6.5.1.1.7 MTSS Student Problems Page TestsVerify MTSS Student Problem Solve link.

4.6.5.1.1.8 MTSS Student Problem Solve Page Tests

4.6.5.1.1.8.1 Verify Grade Level search functionality.

4.6.5.1.1.8.2 Verify AND/OR Functionality.

4.6.5.1.1.8.3 Verify functionality of Show Advanced Search, Show Instructions, and Search buttons.

4.6.5.1.1.9 Advanced Search Page Tests

4.6.5.1.1.9.1 Verify Topic, Concept, Difficulty Level, and Allow Calculator menu functionality.

4.6.5.1.1.9.2 Verify Do Not Care and Matching radio button functionality.

4.6.5.1.1.9.3 Verify Description text field functionality.

4.6.5.1.1.9.4 Verify Grade Level search functionality.

100

4.6.5.1.1.9.5 Verify functionality of Show Simple Search, Show Instructions, and Search buttons.

4.6.5.1.1.9.6 Verify AND/OR Functionality.

4.6.5.1.1.10 MTSS Teacher Problems Page TestsVerify Create, Edit, Delete, and Solve links.

4.6.5.1.1.11 Create Page Tests

4.6.5.1.1.11.1 General Page Testing

4.6.5.1.1.11.1.1 Verify Show Instructions, Browse, and Generate Preview buttons.

4.6.5.1.1.11.1.2 Verify Topic, Concept, Difficulty Level, and Number of Questions menus.

4.6.5.1.1.11.1.3 Verify “Allow Calculator?” and “Include an image?” radio button.

4.6.5.1.1.11.1.4 Verify Grade Level check boxes.

4.6.5.1.1.11.1.5 Verify Description, Image File, and Specify Problem Statement text fields.

4.6.5.1.1.11.2 Problem Creation Testing

4.6.5.1.1.11.2.1 Verify Type menu.

4.6.5.1.1.11.2.2 Verify selecting a “Text” problem populates fields for the correct problem type.

4.6.5.1.1.11.2.3 Verify selecting a “Multiple Choice” problem populates fields for the correct problem type.

4.6.5.1.1.11.2.4 Verify selecting a “True/False” problem populates fields for the correct problem type.

4.6.5.1.1.11.2.5 Verify selecting a “Yes/No” problem populates fields for the correct problem type.

4.6.5.1.1.11.2.6 Verify selecting a “Check All That Apply” problem populates fields for the correct problem type.

4.6.5.1.1.11.2.7 Verify Multiple Choice Solution, Yes/No Solution, and True/False Solution radio buttons.

4.6.5.1.1.11.2.8 Verify each Question, Choices, and Solution text field.

101

4.6.5.1.1.11.2.9 Verify Number of Choices menu for each respective problem type.

4.6.5.1.1.11.2.10 Verify “Check All That Apply” Solution check boxes.

4.6.5.1.1.12 Edit Page Tests

4.6.5.1.1.12.1 Verify Show Instructions and Search buttons

4.6.5.1.1.12.2 Verify Topic, Concept, Difficulty Level, and Allow Calculator menus

4.6.5.1.1.12.3 Verify Description and And/Or radio buttons

4.6.5.1.1.12.4 Verify 3rd, 4th, 5th, and 6th grade check boxes

4.6.5.1.1.12.5 Verify Description text field

4.6.5.1.1.12.6 Edit – Select Problem to Edit Page Tests

4.6.5.1.1.12.7 Verify problem links

4.6.5.1.1.12.8 Verify population of problems

4.6.5.1.1.13 Edit – Editing Page Tests

4.6.5.1.1.13.1 Verify Show Instructions, Browse, and Generate Preview buttons.

4.6.5.1.1.13.2 Verify Topic, Concept, Difficulty Level, and Number of Questions menus.

4.6.5.1.1.13.3 Verify “Allow Calculator?” and Image-based radio buttons.

4.6.5.1.1.13.4 Verify Grade Level check boxes.

4.6.5.1.1.13.5 Verify Description, Image File, and Specify Problem Statement text fields.

4.6.5.1.1.13.6 Verify Type menus.

4.6.5.1.1.13.6.1 Verify selecting a “Text” problem populates fields for the correct problem type.

4.6.5.1.1.13.6.2 Verify selecting a “Multiple Choice” problem populates fields for the correct problem type.

4.6.5.1.1.13.6.3 Verify selecting a “True/False” problem populates fields for the correct problem type.

4.6.5.1.1.13.6.4 Verify selecting a “Yes/No” problem populates fields for the correct problem type.

102

4.6.5.1.1.13.6.5 Verify selecting a “Check All That Apply” problem populates fields for the correct problem type.

4.6.5.1.1.13.7 Verify Multiple Choice Solution, Yes/No Solution, and True/False Solution radio buttons.

4.6.5.1.1.13.8 Verify each Question, Choices, and Solution text field.

4.6.5.1.1.13.9 Verify Number of Choices menu for each respective problem type.

4.6.5.1.1.13.10 Verify “Check All That Apply” Solution check boxes.

4.6.5.1.1.14 Delete Page Tests






4.6.5.1.1.15 Delete – Delete Problem Page Tests

4.6.5.1.1.15.1 Verify valid population of problem list.

4.6.5.1.1.15.2 Verify problem check boxes.

4.6.5.1.1.15.3 Verify Uncheck All and Delete buttons

4.6.5.1.1.16 Solve – Search for Problem Page Tests






4.6.5.1.1.17 Solve – Problem Selection Page Tests

4.6.5.1.1.17.1 Verify valid population of problem list

4.6.5.1.1.17.2 Verify problem links

103

4.6.5.1.1.18 Solve – Problem Solving Page Tests

4.6.5.1.1.18.1 Verify all text fields

4.6.5.1.1.18.2 Verify all radio buttons

4.6.5.1.1.18.3 Verify Submit for Grading button

4.6.5.1.2 User Interface testing

4.6.5.1.2.1 Navigational Bar Tests

4.6.5.1.2.1.1 Verify the bar maintains functionality throughout the entire application. (IE: Every page works the same)

4.6.5.1.2.1.2 Verify the bar maintains form throughout the entire application. (IE Font never changes etc)

4.6.5.1.2.2 Homepage TestsVerify the main MTSS page is grammatically correct and all images load correctly.

4.6.5.1.2.3 Problems Page Tests

4.6.5.1.2.3.1 Verify each menu button Create, Edit, Delete and Solve look/function correctly.

4.6.5.1.2.3.2 Verify all images load correctly and grammar is correct.

4.6.5.1.2.4 Help Page Test

4.6.5.1.2.4.1 Check grammar and page layout.

4.6.5.1.2.4.2 Verify images and information are up-to-date with the current MTSS application.

4.6.5.1.2.5 Support Page Tests

4.6.5.1.2.5.1 Check grammar and page layout.

4.6.5.1.2.5.2 Verify all information is up-to-date with the current MTSS application.

4.6.5.1.2.6 About MTSS Page Tests

4.6.5.1.2.6.1 Verify all information is correct with the current MTSS team and Advisors.

4.6.5.1.2.6.2 Check grammar and Page layout.

4.6.5.1.2.7 MTSS Student Problem Solve Tests

4.6.5.1.2.7.1 Login as a Student and navigate to the problem solve feature.

104

4.6.5.1.2.7.2 Verify that each problem is appropriate to be released to students (IE: Get rid of Test problems.

4.6.5.1.2.7.3 Verify every problem graphics and questions load correctly.

4.6.5.1.2.7.4 Verify submission and reporting layout and images load correctly.

4.6.5.1.2.8 Advanced Search Page Tests

4.6.5.1.2.8.1 Verify show/hide instructions works correctly.

4.6.5.1.2.8.2 Verify Search layout and navigation.

4.6.5.1.2.9 Create Problem Page Tests

4.6.5.1.2.9.1 General Page Testing

4.6.5.1.2.9.1.1 Make sure you are logged in as acsteacher password: teacher

4.6.5.1.2.9.1.2 Verify number of questions function

4.6.5.1.2.9.1.3 Verify functionality of the Show/hide Instructions button

4.6.5.1.2.9.2 Problem Creation Testing

4.6.5.1.2.9.2.1 Check and verify functionality of each type of problem

4.6.5.1.2.9.2.2 Generate preview of blank page

4.6.5.1.2.9.2.3 Verify Generate preview of test problem

4.6.5.1.2.9.2.4 Verify creation of problem and solvability in the database (shows up in search, can solve)

4.6.5.1.2.9.2.5 Any test problem created should be deleted.

4.6.5.1.2.10 Edit Problem Page Tests

4.6.5.1.2.10.1 Verify navigation.

4.6.5.1.2.10.2 Verify search (See section 4.6.5.1.2.8)

4.6.5.1.2.10.3 Verify images are uploaded correctly and saved when replaced.

4.6.5.1.2.10.4 Delete and edited test problems from the database.

4.6.5.1.2.11 Delete Problem Page Tests

4.6.5.1.2.11.1 Verify navigation.

105

4.6.5.1.2.11.2 Verify search (See section 4.6.5.1.2.8)

4.6.5.1.2.11.3 Verify test problem actually deleted in database. (Not contained in search.)

4.6.5.2 Globey’s World Test Plan

4.6.5.2.1 User Interface Testing

4.6.5.2.1.1 World Page Tests

4.6.5.2.1.1.1 Clear your internet browsers ‘cache’ and navigate to the World page: Verify the world image page loads within 5 seconds on Cable/DSL internet or greater.

4.6.5.2.1.1.2 Clear your internet browsers ‘cache’ and navigate to the World page: Verify the world image page loads within 25 seconds on 56kps internet or less.

4.6.5.2.1.1.3 Verify the world image is “easy to read.”

4.6.5.2.1.1.4 Verify links to all eight regions are functional from the world image map.

North America

Central America

South America

Europe

Asia

Africa

Middle East

Oceania

4.6.5.2.1.2 Regional and Country Page Tests

4.6.5.2.1.2.1 Verify links to all eight regions are functional from the drop down menu on the Region page.

4.6.5.2.1.2.2 Clear your internet browsers ‘cache’ and navigate to EVERY Region page: Verify the region pages load within 5 seconds on Cable/DSL internet or greater.

4.6.5.2.1.2.3 Clear your internet browsers ‘cache’ and navigate to EVERY Region page: Verify the region pages load within 25 seconds on 56kps internet or less.

106

4.6.5.2.1.2.4 Verify links to all 193 countries are functional from the eight region image maps.

4.6.5.2.1.2.5 Verify links to all 193 countries are functional from the drop down menu on the Country page.

4.6.5.2.1.2.6 While verifying country links, verify all 193 countries populate database information in: Facts and FiguresEconomyGeographyPolitical

4.6.5.2.1.2.7 Also, while verifying country links, verify all 193 countries have a county image and country flag image.


4.6.5.2.1.3.1 Verify the GW application has Help pages for the World, Region, Country, and Compare pages.

4.6.5.2.1.3.2 Verify the GW Help pages have links that navigate to each of the other help pages.

4.6.5.2.1.3.3 Navigate to each of the GW Help Pages; verify all help pages provide a step-by-step walkthrough that is consistent with the current GW application.

4.6.5.2.1.3.4 Verify the screenshots and images on all GW Help pages are consistent with the current GW application.

4.6.5.2.2 Comparison Testing

4.6.5.2.2.1 General

4.6.5.2.2.1.1 For all tests performed below [1.2.2 – 1.2.11], make a checklist and verify the following:

4.6.5.2.2.1.1.1 The comparison charts shall always display the countries in the ‘Countries to Compare’ field.

4.6.5.2.2.1.1.2 The y-axis of the charts shall contain the ‘Data to Compare’ type.

4.6.5.2.2.1.1.3 The x-axis of the charts shall contain the ‘Countries to Compare’ list.

4.6.5.2.2.1.1.4 The comparison charts shall always be in bar graph form.

4.6.5.2.2.1.1.5 The bars on the bar graphs shall never extend above or below the chart bounds.

107

4.6.5.2.2.1.1.6 The auto-scaling of the bar graph charts shall always be visually readable.

4.6.5.2.2.1.1.7 Each country shall have a bar and value for each ‘Data to Compare’ type, unless auto-scaling disallows it

4.6.5.2.2.1.1.8 The y-axis scales shall become smaller the larger the graph becomes.

4.6.5.2.2.1.2 (Make the following tests in the “Data to compare:” in Globey’s World Comparison Page)

4.6.5.2.2.2 Total Area

4.6.5.2.2.2.1 Select no countries to compare, verify nothing happens but a pop-up warning.

4.6.5.2.2.2.2 Select one country to compare, verify nothing happens but a pop-up warning.

4.6.5.2.2.2.3 Select over 10 countries to compare, verify nothing happens but a pop-up warning.

4.6.5.2.2.2.4 Attempt to add more than 10 countries at one time (hold the [shift] key and click with mouse), verify nothing happens but a pop-up warning.

4.6.5.2.2.2.5 Add 2 to 10 countries into the ‘Countries to Compare’ list, and then attempt to add more than 10 countries by clicking on multiple countries with the shift key. Verify nothing happens but a pop-up warning.

4.6.5.2.2.2.6 Select a small chart size and random number of countries (between two and ten) to compare. Verify a small chart displays all selected countries Total Area.

4.6.5.2.2.2.6.1 Repeat the above step 2 more times with small chart size.

4.6.5.2.2.2.7 Select a medium chart size and random number of countries (between two and ten) to compare. Verify a medium chart displays all selected countries Total Area.

4.6.5.2.2.2.7.1 Repeat the above step 2 more times with medium chart size.

4.6.5.2.2.2.8 Select a large chart size and random number of countries (between two and ten) to compare. Verify a large chart displays all selected countries Total Area.


4.6.5.2.2.3 Land Area

108

4.6.5.2.2.3.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Land Area

4.6.5.2.2.4 Water Area

4.6.5.2.2.4.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Water Area

4.6.5.2.2.5 GDP

4.6.5.2.2.5.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for GDP

4.6.5.2.2.6 Population

4.6.5.2.2.6.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Population

4.6.5.2.2.7 Literacy

4.6.5.2.2.7.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Literacy

4.6.5.2.2.8 Birth Rate

4.6.5.2.2.8.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Birth Rate

4.6.5.2.2.9 Death Rate

4.6.5.2.2.9.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Death Rate

4.6.5.2.2.10 Elevation Low

4.6.5.2.2.10.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Elevation Low

4.6.5.2.2.11 Elevation High

4.6.5.2.2.11.1 Repeat test steps 1.2.1 through 1.2.2.8.1.1 for Elevation High

4.6.5.2.3 Automatic Database Repopulation Testing

4.6.5.2.3.1.1 Randomly select 10 countries and verify the database information matches the latest database information from the CIA database used in the database repopulation tool. (Document which countries you chose).

4.6.5.2.4 Games Testing

4.6.5.2.4.1.1 No games to test at the current time.

4.6.5.3 Uncle Sam’s USA

4.6.5.3.1 User Interface Testing

4.6.5.3.1.1 Country Page Test

109

4.6.5.3.1.1.1 Clear your internet browsers ‘cache’ and navigate to the USA Country page: Verify the Country page’s USA map image loads within 5 seconds on Cable/DSL internet or greater.

4.6.5.3.1.1.2 Clear your internet browsers ‘cache’ and navigate to the USA Country page: Verify the Country page’s USA map image loads within 25 seconds on 56kps internet or less.

4.6.5.3.1.1.3 Verify the USA map image is “easy to read.”

4.6.5.3.1.1.4 Navigate to every state from the USA image map. Verify links to all 50 states are functional from the USA image map.

4.6.5.3.1.2 State Info Page Tests

4.6.5.3.1.2.1 From the States Info pages, verify links to all 50 states are functional from the drop down menu on the State Info page.

4.6.5.3.1.2.2 Navigate to every state’s page. Verify each state page has a state image and state flag image.

4.6.5.3.1.2.3 Verify each state page populates all database information in the following: Facts and Figures Economy Geography Political Population


4.6.5.3.1.3.1 Verify the USA application has Help pages for the Country, State Info, Compare, and Games pages.

4.6.5.3.1.3.2 Verify the USA Help pages have links that navigate to each of the other help pages.

4.6.5.3.1.3.3 Navigate to each of the USA Help Pages; verify all help pages provide a step-by-step walkthrough that is consistent with the current USA application.

4.6.5.3.1.3.4 Verify the screenshots and images on all USA Help pages are consistent with the current USA application.

4.6.5.3.2 Comparison Testing

4.6.5.3.2.1 General

110

4.6.5.3.2.1.1 For all tests performed below [2.2.2 – 2.2.11], make a checklist and verify the following:

4.6.5.3.2.1.1.1 The comparison charts shall always display the states in the ‘States to Compare’ field.

4.6.5.3.2.1.1.2 The y-axis of the charts shall contain the ‘Data to Compare’ type.

4.6.5.3.2.1.1.3 The x-axis of the charts shall contain the ‘States to Compare’ list.

4.6.5.3.2.1.1.4 The comparison charts shall always be in bar graph form.

4.6.5.3.2.1.1.5 The bars on the bar graphs shall never extend above or below the chart bounds.

4.6.5.3.2.1.1.6 The auto-scaling of the bar graph charts shall always be visually readable.

4.6.5.3.2.1.1.7 Each country shall have a bar and value for each ‘Data to Compare’ type, unless auto-scaling disallows it

4.6.5.3.2.1.1.8 The y-axis scales shall become smaller the larger the graph becomes.

4.6.5.3.2.1.2 (Make the following tests in the “Data to compare:” in Uncle Sam’s America Comparison Page)

4.6.5.3.2.2 Total Area

4.6.5.3.2.2.1 Select no states to compare, verify nothing happens but a pop-up warning.

4.6.5.3.2.2.2 Select one state to compare, verify nothing happens but a pop-up warning.

4.6.5.3.2.2.3 Select over 10 states to compare, verify nothing happens but a pop-up warning.

4.6.5.3.2.2.4 Attempt to add more than 10 states at one time (hold the [shift] key and click with mouse), verify nothing happens but a pop-up warning.

4.6.5.3.2.2.5 Add 2 to 10 states into the ‘States to Compare’ list, then attempt to add more than 10 states by clicking on multiple states with the shift key. Verify nothing happens but a pop-up warning.

4.6.5.3.2.2.6 Select a small chart size and random number of states (between two and ten) to compare. Verify a small chart displays all selected states Total Area.

4.6.5.3.2.2.6.1 Repeat the above step 2 more times with small chart size.

111

4.6.5.3.2.2.7 Select a medium chart size and random number of states (between two and ten) to compare. Verify a medium chart displays all selected states Total Area.


4.6.5.3.2.2.8 Select a large chart size and random number of states (between two and ten) to compare. Verify a large chart displays all selected states Total Area.


4.6.5.3.2.3 Land Area




4.6.5.3.2.5 GDP

4.6.5.3.2.5.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for GDP

4.6.5.3.2.6 Land Area




4.6.5.3.2.8 Population

4.6.5.3.2.8.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Population

4.6.5.3.2.9 Birth Rate

4.6.5.3.2.9.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Birth Rate

4.6.5.3.2.10 Death Rate

4.6.5.3.2.10.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Death Rate

4.6.5.3.2.11 Lowest Point

4.6.5.3.2.11.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Lowest Point

4.6.5.3.2.12 Highest Point

4.6.5.3.2.12.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Highest Point

112

4.6.5.3.2.13 Acres Forested

4.6.5.3.2.13.1 Repeat test steps 2.2.1 through 2.2.2.8.1.1 for Acres Forested

4.6.5.3.2.14 Chart Auto-scaling

4.6.5.3.2.14.1 Minimum Auto-scaling – Choose ‘Elevation Low’ Data to Compare. Compare ‘Nevada’ and ‘Connecticut’. Verify that the Chart appears with no errors. Verify that Nevada’s bar does not extend below the chart.

4.6.5.3.2.14.2 Minimum Auto-scaling – Choose ‘Elevation Low’ Data to Compare. Pick ‘Colorado’ and another random state. Verify that the bar does not extend into the gray area above or below the chart. Do 10 more times.

4.6.5.3.2.14.3 Maximum Auto-scaling – Choose ‘Elevation High’ Data to Compare. Compare ‘Nevada’ and ‘Florida’. Verify that the chart appears with no errors.

4.6.5.3.2.14.4 Maximum Auto-scaling – Choose ‘Elevation High’ Data to Compare. Compare ‘Nevada’ and another random state. Verify that the bar does not extend into the gray area above or below the chart. Do 10 more times.

4.6.5.3.2.14.5 List and Chart Population

4.6.5.3.2.14.6 Choose a state from the ‘State List’ box, and add it to the ‘States to Compare’ box. "Compare!” Verify that the correct state is in the chart and ‘States to Compare’ box. Empty the ‘States to Compare’ box, choose a different state from the ‘State List’ box, and add it to the ‘States to Compare’ box. Compare! Verify that the correct state is in the chart and ‘States to Compare’ box.

4.6.5.3.2.14.7 Choose multiple states from the ‘State List’ box, and add them to the ‘States to Compare’ box. "Compare!" Verify that the correct states are in the chart and ‘States to Compare’ box. Empty the ‘States to Compare’ box, choose multiple new states from the ‘State List’ box, and add it to the ‘States to Compare’ box. Compare! Verify that the correct states are in the chart and ‘States to Compare’ box.

4.6.5.3.3 Automatic Database Repopulation Testing

4.6.5.3.3.1.1 Randomly select 10 countries and verify the database information matches the latest database information from the CIA database used in the database repopulation tool. (Document which countries you chose).

4.6.5.3.4 Games Testing

4.6.5.3.4.1 Games Random State Algorithm

113

4.6.5.3.4.1.1 Navigate to the USA ‘Name that State’ page. Start the game. Note which state’s flag appears first (do not proceed into the game). Now navigate away from the page, clear your browser’s cache. Navigate back to the ‘State that Flag’ page and note which state’s flag appears first. Repeat this process 15 times and verify the state generation is pseudorandom.

4.6.5.3.4.1.2 Navigate to the USA ‘State that Flag’ page. Start the game. Note which state’s flag appears first (do not proceed into the game). Now navigate away from the page, clear your browser’s cache. Navigate back to the ‘State that Flag’ page and note which state’s flag appears first. Repeat this process 15 times and verify the state generation is pseudorandom.

4.6.5.3.4.1.3 Navigate to USA ‘Name that State’ game. Play the game until you have chosen over 30 states, and write down each state that was generated. Verify no states repeat within 20 consecutive tries.

4.6.5.3.4.1.4 Navigate to USA ‘State that Flag’ game. Play the game until you have chosen over 30 state flags, and write down each state that was generated. Verify no state flags repeat within 20 consecutive tries.

4.6.5.3.4.2 Name that State

4.6.5.3.4.2.1 Play Name that State 30 times randomly guessing 0 to 3 incorrect answers. Verify the following occurs:

4.6.5.3.4.2.1.1 Verify ‘Name that State’ pages display the state to be guessed above the country map.

4.6.5.3.4.2.1.2 Verify ‘Name that State’ pages display the guessed state (whether right or wrong).

4.6.5.3.4.2.1.3 Verify correct answers are displayed in GREEN text and incorrect answers are RED.

4.6.5.3.4.2.1.4 Verify ‘Name that State’ pages display the number of tries left to guess.

4.6.5.3.4.2.1.5 Verify ‘Name that State’ pages display the correct state.

4.6.5.3.4.2.2 Play ‘Name that State’ 15 more times, guessing all correct answers in a row. Try your best and verify correct operations occur with your choices.

4.6.5.3.4.2.3 Play ‘Name that State’ 15 more times, guessing all incorrect answers (three times) in a row. Verify correct operations occur with your choices.

4.6.5.3.4.2.4 Play ‘Name that State’ 50 times and write down the states that are displayed. Verify that the states you just answered are not asked again for 20 more tries. Keep track of what states appear on all 50 tries. Verify that no state appears more than 3 times.

114

4.6.5.3.4.3 State that Flag

4.6.5.3.4.3.1 Play State that Flag 30 times randomly guessing 0 to 3 incorrect answers. Verify the following occurs:

4.6.5.3.4.3.1.1 Verify ‘State that Flag’ pages display the state to be guessed above the country map.

4.6.5.3.4.3.1.2 Verify ‘State that Flag’ pages display the guessed state (whether right or wrong).

4.6.5.3.4.3.1.3 Verify correct answers are displayed in GREEN text and incorrect answers are RED.

4.6.5.3.4.3.1.4 Verify ‘State that Flag’ pages display the number of tries left to guess.

4.6.5.3.4.3.1.5 Verify ‘State that Flag’ pages display the correct state.

4.6.5.3.4.3.2 Play ‘State that Flag’ 15 more times, guessing all correct answers in a row. Try your best and verify correct operations occur with your choices.

4.6.5.3.4.3.3 Play ‘State that Flag’ 15 more times, guessing all incorrect answers (three times) in a row. Verify correct operations occur with your choices.

4.6.5.3.4.3.4 Play ‘State that Flag’ 50 times and write down the states that are displayed. Verify that the states you just answered are not asked again for 20 more tries. Keep track of what states appear on all 50 tries. Verify that no state appears more than 3 times.

4.6.5.4 SASF Test Plan

4.6.5.4.1 Authentication

4.6.5.4.1.1 Logging InVerify logging in works for each of the following usernames and passwords:

Table 25 – Login Information

Username Passwordacsadmin adminacsteacher teacheracstudent studentGuest guestA successful login results in the user being directed to the Homepage.

4.6.5.4.1.2 Logging Out

115

4.6.5.4.1.2.1 Verify logging out works for the following accounts: acsadmin acsteacher acstudent guest

A successful logout results in the user being required to login in order to return to the application.

4.6.5.4.1.2.2 Verify the application automatically logs the user out after 2 hours with any account.

4.6.5.4.1.3 Page NavigationThe following tests refer to the links in the main window immediately after login.

4.6.5.4.1.3.1 Verify the “Mathematical and Teaching Software System (MTSS)” link takes the user to the MTSS homepage.

4.6.5.4.1.3.2 Verify the “Globey’s World” link takes the user to the GW homepage.

4.6.5.4.1.3.3 Verify the “Uncle Sam’s America” link takes the user to the USA homepage.

4.6.5.4.2 User Registration

4.6.5.4.2.1 Register UserThe following tests refer to the “Register a New User” link found on the menu when logging in as an administrator.

4.6.5.4.2.1.1 Verify an account can be created with all six user types. Administrator Coordinator Teacher Student Parent Guest

4.6.5.4.2.1.2 Verify an account cannot be created when the Password and Verify Password fields do not match.

4.6.5.4.2.1.3 Verify an account can be created when each of the fields is left blank. (Test each field by leaving it blank and filling out every other field correctly.)

Middle Name Note Owner Password Hint Student ID Email

116

4.6.5.4.2.1.4 Verify an account cannot be created when each of the fields is left blank. (Test each field by leaving it blank and filling out every other field correctly.)

First Name Last Name Username Password Verify Password\

4.6.5.4.2.2 Edit UserThe following tests refer to the “Change My Password/E-Mail” link when logged in as an administrator or teacher. In this section, all tests will be verified both as an administrator and as a teacher.

4.6.5.4.2.2.1 Verify a password can be changed when leaving the following sets of fields blank.

None Password Hint Email Password Hint and Email

4.6.5.4.3 Interface NavigationThe following tests refer to the links in the menu on the left-hand side of the application interface.

4.6.5.4.3.1 HomepageThe following tests relate to common tools in the software. These tests shall involve web pages that may be reached using links from the Homepage.

4.6.5.4.3.2 AdministratorConfirm that the following links exist and function correctly on the Homepage, the Change My Password/E-Mail page, and the Register a New User page when logged in as an administrator.

Homepage MTSS Globey’s World Uncle Sam’s America Change My Password/E-Mail Register a New User Logout

4.6.5.4.3.3 TeacherConfirm that the following links exist and function correctly on the Homepage and the Change My Password/E-Mail page when logged in as a teacher.

Homepage MTSS

117

Globey’s World Uncle Sam’s America Change My Password/E-Mail Logout

4.6.5.4.3.4 StudentConfirm that the following links exist and function correctly on the Homepage and the Change My Password/E-Mail page when logged in as a student.

Homepage MTSS Globey’s World Uncle Sam’s America Change My Password/E-Mail Logout

4.6.5.4.3.5 GuestConfirm that the following links exist and function correctly on the Homepage when logged in as a guest.

Homepage MTSS Globey’s World Uncle Sam’s America Logout

4.6.5.4.3.6 MTSSConfirm that the following links exist and function correctly on the MTSS homepage when logged in as an administrator, teacher, student, and guest.

Homepage Problems Help Support About MTSS Return to K-12 Homepage Logout

4.6.5.4.3.7 GWConfirm that the following links exist and function correctly on the Globey’s World homepage when logged in as an administrator, teacher, student, and guest.

Homepage World Region Country Comparison Help Return to K-12 Homepage Logout

118

4.6.5.4.3.8 USAConfirm that the following links exist and function correctly on Uncle Sam’s America homepage when logged in as an administrator, teacher, student, and guest.

Country State Info Compare Games Help Return to K-12 Homepage Logout

4.6.6 Appendix F: Problem Solving Algorithm Definition

4.6.6.1 Problem StatementThe MTSS application is designed to teach students the process of problem solving. To accomplish this, an algorithm was designed that assists students with problem solving techniques by guiding them through a problem walkthrough. The walkthrough breaks down an otherwise complex problem into several steps and explores different ways to solve a mathematical problem.

The problem solving algorithm is a four-step algorithm in which students identify important information in a word problem, choose a strategy to solve the problem, find a solution to the problem, and then reflect upon their answer. At each step of the problem solving process, the student is asked to express their confidence in their solution.

Figure 22 – Problem Solving Algorithm Diagram

4.6.6.2 IdentifyThe first step in the algorithm is the identification of important information. Often problems contain extraneous information that is not needed to find a solution. The student must first identify the question asked, and then identify which pieces of given information are necessary to solve the problem. Once the student has the recognized the pertinent information, they may continue to the next step: choose a strategy to solve the problem.

4.6.6.3 Choose a StrategyA problem solving strategy is the process used to turn the meaningful information into the solution. The walkthrough helps the student explore several different processes that

119

Identify Choose Solve Reflect

may be used to solve a problem. After the student evaluates these processes, they will select one to be their preferred method for solving the problem. The student must understand why they chose a certain process to solve the problem. The algorithm must provide strategies appropriate for the student’s skill level. This is because problem solving strategies may be ability dependent.

4.6.6.4 Solve the ProblemOnce the student has identified the question and relevant information, and has chosen process to find a solution, they may apply their problem solving process to form a solution. The problem walkthrough must assist students who are struggling to apply their problem solving process to the problem.

4.6.6.5 ReflectOften, a solution is viewed as the final step in problem solving, but reflection and checking that a solution is reasonable and answers the original question is crucial to the learning process. Once a solution is found, several questions should be asked pertaining to previous steps:

Did the student use the correct information to find the solution? Did they choose an appropriate process to solve the problem? Did the student apply the process correctly? Does the answer make sense to the student? If a similar problem were given, would the student be able to solve this problem as well?

The reflection offers a final opportunity for a student to express their confidence in their ability to solve the problem. Once this step is completed, the student may review a previous step to develop understanding of the problem.

4.6.6.6 AudienceThe problem solving algorithm must be designed in a simple manner that will third through sixth grade students will understand. Using straightforward language and easy to follow instructions will allow this algorithm to be effectively used by a younger audience. Problems must be categorized by a difficulty level in order select problems appropriate to a student’s mathematical abilities.

4.6.6.7 Current SituationThe problem solving algorithm is in the development phase. The algorithm’s purpose and definition are well-defined, and the MTSS team is currently working on design activities. Presently, the MTSS application has an extensive problem creation tool that will be used in the future to create single mathematical problems, assessments, and problem walkthroughs. All of these will be based on the four-step problem solving algorithm. Trial walkthroughs have been created by the team in order to assess the capabilities of the problem creation tool in its effectiveness as a walkthrough creation tool.

120

File types used for different kinds of problem are stored in the same database. To distinguish between single problems, walkthroughs, etc., the problem type is incorporated into the file name. This allows the option to query by problem type from the MTSS search tools. Problems are to their corresponding walkthrough via a button located on the problem page.

4.6.6.8 Future ActivitiesThe following tasks must be accomplished in order to complete the design and implementation of the problem solving algorithm:

Creation tool must undergo extensive testing to ensure stability Additional walkthroughs must be created A general template needs to be created for the problem creation tool Creation tool must allow for different file types and templates Walkthroughs must be linked to problems and tested for a stable workflow Search queries must be enhanced to allow for future file types Problem solving algorithm step must be tested, verified, and presented to the

Department of Curriculum and Instruction for acceptance

4.6.6.9 ConclusionThe problem solving algorithm is an abstract and complicated process. The problem solving algorithm definition in this document is based on the current perception of the MTSS subteam and may be changed or enhanced in future semesters. The MTSS subteam currently has sample walkthroughs and has incorporated the student confidence feedback mechanism in the current semester. Future work for the problem solving algorithm has been outlined in this document that future MTSS subteams must accomplish in order for full problem solving algorithm implementation.

121

4.6.7 Appendix G: Grade Book DesignThe following information pertains to the grade book design created this semester by the SASF subteam. The grade book is a tool that is responsible for storing information about.

4.6.7.1 Grade Book DiagramFigure 23 notes:

For column type of table ASSIGNMENTS:o 1 = examo 2 = practice_examo 3 = quizo 4 = homework

For column type of table USERS:o 1 = computer administratoro 2 = school administratoro 3 = course coordinatoro 4 = teachero 5 = studento 6 = parent / guardian

PK indicates the primary key in a database table The third column in each table indicates the data type

122

Figure 23 – Grade Book Diagram

123

4.6.7.2 User PrivilegesWith the design of this grade book functionality, it is critical that only the correct individuals shall be able to see confidential grades based on the users specified privileges. The following will point out key specifications for each type of user the grade book will account for.

o Computer Administrator: Full privileges Create parent/student username ID Create course coordinator Create courses Create individual course sections Assign teachers to specific section

o School Administrator: View individual student records from corresponding school View overall section and course records

o Course Coordinator Create single “course” questions (common to all sections) View scores and responses (w/o student identifying information) of

course questions View entire course statistics View statistics of sections Rank sections by section average

o Teachers: Add/remove an assignment Create single “section” questions View scores and answers (by question, by assignment, by student) View section statistics Apply weights to assignments Input scores from assignments not included in the K-12 Teaching

Application Software Modify student scores within their own section Add/remove students to their section Track time spent student spent on each assignment

o Students: View grades of their individual records View averages of their course section View their responses to questions on previous assignments Work on assignments, quizzes, tests, and practice tests

o Parents / Guardians: View grades of their child / children View averages of their child’s course section

124

4.6.7.3 Feature ListBased on the design of the grade book, the following are some of the features that are planned to be implemented in the future. Figure 24, illustrates these features and how the users will be permitted to access them.

- Score Statistics: Report of average (mean, median mode), standard deviation, highest score,

lowest score for a given question/assignment/quiz/test. Scope may be section data or entire course data.

Teachers will also be able to view students' answers to individual questions so the teachers can better understand what their class is not understanding.

Teachers should be able to see time spent on each assignment to see if their students are actually trying on the assignment.

- Rank:Rank students by score on questions/assignment. This feature will optionallyidentify "cut-offs" such as a score, percentage, or rank (i.e. students below20pts, students above 80%, top 10 students).

- Weight:A teacher or course coordinator may apply a weight to assignment categories (homework, quiz, test) and to assignments within that category.

- Charts:Visually summarize score information based on course by section, section by student, and individual student. (Based on GW/USA chart generation methods)

- Generate grades:Generate current grades based on teacher section preferences and weights applied to assignments. May be based on...

- Cutoffs for A/B/C/etc- % of A/B/C allowed in section- # of A/B/C allowed in section- # of standard deviations away from average

Attendance Records:Teachers will be able to input attendance of each individual student for school district administration purposes.

125

Figure 24: Grade Book Features and Permissions

Features Computer Admin

School Admin

Course Coordinator

Teacher Student Parent

Scores

Section Mean View View View View View View

Section Median View View View View View View

Section Mode View View View View View View

Standard Deviation View View View View View View

Section High Score View View View View View View

Section Low Score View View View View View View

Individual Score Edit, View View - Edit, View View View

Student Answers to Indiv. Questions

View - View View View View

Time Spent on Each Assignment

View - - View - -

Student Rank (cutoffs) Based On..

Score Edit, View View - View View View

Percentage Edit, View View - View View View

Class Rank Edit, View View - View View View

Weight

Assign. Categories Edit, View View Edit, View Edit, View View View

Individual Assign. in Category

Edit, View View Edit, View Edit, View View View

Charts

Course by Sections View View View View - -

Section by Students (Histogram by decades)

View View - View - -

Individual Student (with class stats)

View View - View View View

Generated Grades (Done Auto. Based on weight and scores input prior)

View View - View View View

Student Attendance Records

Edit, View View - Edit, View - -

126

seniord.ece.iastate.eduseniord.ece.iastate.edu/projects/archive/ongo08/... · Web viewAPI...

Documents

Transcript of seniord.ece.iastate.eduseniord.ece.iastate.edu/projects/archive/ongo08/... · Web viewAPI...