K-12 Teaching Application Software & Support
K-12 Teaching Application Software & Support
Project Number: Ongo8
Status Report
Client:
Iowa School Districts
Faculty Advisors:
Dr. John W. Lamont
Prof. Ralph Patterson III
|CprE 492 Students |
|Parikshit Advani (8d) |CprE |Laurie Bidrawn (8b/c) |CprE |
|Nichole Dugan (8d) |CprE/ComSci |Nathan Gordon (8d) |CprE |
|Sara Murphy (8a) |CprE |Samantha Olson (8b/c) |CprE |
|John Saterfiel (8a) |CprE |Tiffany Schweer (8a) |CprE |
|David Wire (8a) |CprE | | |
| | | | |
|CprE 491 Students |
|E. Ryan Adamson (8d) |CprE |Aaron Hurd (8a) |CprE |
|Jennifer Carlson (8b/c) |CprE |Chun-Pang Kuk (8d) |CprE |
|Dustin Fee (8b/c) |CprE |Maria-Cristina Olivas (8b/c) |CprE |
|Michael Fong (8a) |CprE |Nate Evans (8b/c) |CprE |
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
November 14, 2005
Table of Contents
1 Introduction 6
1.1 Executive Summary 6
1.2 Acknowledgements 12
1.3 Problem Statement 12
1.4 Operating Environment 13
1.5 Intended Users and Uses 14
1.6 Assumptions and Limitations 16
1.7 Expected End Product Description 19
2 Product Accomplishments and Current Status 19
2.1 Previous Accomplishments 19
2.2 Present Accomplishments 56
2.3 Future Required Activities 62
2.4 Recommendation for Continued Effort 64
3 Documentation of Current Efforts and Results 65
3.1 Project Definition Activities 65
3.2 Research Activities 67
3.3 Design Activities 69
3.4 Implementation Activities 69
3.5 Testing and Modification Activities 70
4 Resources and Schedules 73
4.1 Resource Requirements 73
4.2 Schedules 78
5 Closing 79
5.1 Lessons Learned 79
5.2 Risks and Risk Management 80
5.3 Project Team Information 82
5.4 Summary 84
List of Figures
Table 2. User Group and Description 15
Table 3. User Group and Uses for the Application 16
Table 4. Spring 2004 Functionality List 44
Table 5: Fall 2004 functionality list 48
Table 6: Spring 2005 functionality list 52
Table 7: Estimated Personnel Requirements 74
Table 8: Actual Personnel Requirements 75
Table 9: Estimated Financial Requirements 76
Table 10: Actual Financial Requirements 77
Table 1. List of Definitions
|ACS – Ames Community Schools. |
|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. |
|CVS – Concurrent Version System – Provides control in keeping only one current version of the software as changes are made by all team members. |
|FW – Framework |
|GW – Globey’s World |
|GUI – Graphical user interface - A usable interface that interacts with the user and the application. |
|LAMP – Linux, Apache, MySQL, PHP – defines the architecture that runs GW and USA. Refers to the operating system, server type, and programming |
|language used to maintain GW and USA. |
|Linux – An open-source operating system that is optimized for use as a web application server. |
|HTML – Hyper Text Markup Language - The language used to describe the formatting and presentation of a web page. |
|MTSS – An acronym for Mathematical Teaching Software System. |
|MySQL – An open-source implementation of an SQL server. |
|Open-source – Software whose source-code is open to the public. |
|PC-compatible – A personal computers which runs a Microsoft Windows operating system |
|PHP – Pseudo-acronym for 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. |
|USA – Uncle Sam’s America |
Introduction
This section of the report intends to familiarize the reader with the project. It is divided into subsections that include the executive summary, acknowledgements, problem statement, operating environment, intended users and uses, assumptions and limitations, and expected end product and other deliverables. Throughout this report, sections will be divided amongst the group’s sub teams where applicable.
1 Executive Summary
The executive summary includes subsections about the need for the project, project description, results to date, and work yet to be completed.
1 Need for the Project
The K-12 Application Support project started as a means to address the issues school districts have identified as weaknesses in student learning. These weaknesses deal with mathematical problem solving and geography. It is the intent of the Ongo8 team to create a suite of applications to solve this need for area school districts through a course of three sub teams developing supplemental programs dealing with math and geography.
1 MTSS
The purpose of the MTSS project is to help students in grades third through sixth improve their skills by supplementing classroom teaching and learning in the area of mathematics, while focusing on the improvement of problem solving skills. MTSS has the potential to go beyond ACS standardized tests and serve as a cornerstone in the development of mathematical problem solving skills that students will need throughout their high school and college careers.
2 GW and USA
The GW and USA projects address the need to teach geography to students in grades third through sixth. The projects provide a solution that is easier to use and more effective than physical reference material. It is the intent of these two applications to offer an interactive approach to learning about world and United States geography through graphical representations and games, besides being a reference tool of country and state information. In the end, the product will lead the student to a greater understanding of the subject matter due to direct involvement and through problem-solving materials.
3 SASF
During the development of the applications, it was realized that there existed a need for common functionality between MTSS, GW, and USA. Each educational software application developed must manage user information and provide a way to only allow authorized access into the applications. There also existed the need to have a common method for teachers to easily create quizzes for the applications, as well as storing and maintaining quizzing results in order to allow teachers and parents to track a student’s progress. In short, this subteam is providing a framework that the other applications can depend on for similar functionality between the applications in the suite.
2 Project Description
It is the intent of the K-12 Application Support team to provide an application suite dealing with teaching mathematical problem solving and geography skills along with an application framework for providing common functionality.
1 MTSS
MTSS will provide the supplementary instruction that students need to improve their problem solving skills on national standardized exams. By creating a program that is platform independent, this software will be accessible by all computers with an Internet connection. The problems used with the program will be set up in a basic structure so that teachers and coordinators will have the ability to add/edit/delete problems and use those problems to create/modify quizzes. The statistical analysis modules will provide invaluable insight to the teachers and coordinators by highlighting the strengths and weaknesses of the students, both as a group and individually.
MTSS will include a series of problems in a specific topic, for instance, fractions, to serve as a supplement to classroom lectures. Students can evaluate their individual performances by looking at the statistics and a database of results that will be generated for the instructors and administrators. By allowing instructors and administrators to view each student’s performance, teachers will be able to focus on specific areas for that students need help, rather than taking a broader approach for a subject.
Problem solving is a skill that develops better with repetition and practice; developing problem-solving skills is more than just being able to perform mathematical operations taught by drill exercises. Problem solving includes recognizing when to use those operations in a practical application. It also includes visualizing the problem, analyzing the information provided, determining what information is needed, coming up with a solution process, and verifying that the solution makes sense. MTSS will guide the student through the process of problem solving by using a generalized problem solving method. MTSS will help the students go through all procedures mentioned above, one by one, until each student understands how to solve the problem.
2 GW and USA
The GW and USA applications will provide an interactive, web-based software tool to supplement students’ understanding of geographical concepts pertaining to the world and the United States. Students will be able to interact with the software through graphical representations of regions, countries, and states in order to find information pertaining to their selections. Using a database backend, GW and USA will present information about the countries and states the students can use as a reference tool for other coursework.
Additionally, GW and USA will provide further interaction through a series of games to strengthen the skills obtained through the programs. There is also the want to increase the scope of the games to test other school-related concepts such as spelling and important landmark knowledge.
3 SASF
To meet the functionality needs listed above, a PHP framework is being developed. The SASF provides standard functions for use by the mentioned educational software applications to store and manage student information within a centralized database. Student access to educational applications will be controlled by the SASF through a web interface. The SASF helps standardize the applications, in turn helping teachers track student progress to improve student performance.
3 Results to Date
Since the inception in 2001 with MTSS and later additions of GW, USA, and SASF, the K-12 Application Support team has so far produced the concept, design, and functionality of an application suite that is almost ready for school districts to view and use in the classroom with third through sixth grade students. While there remains much more work to be done, each subteam has produced functionality that increases the overall effectiveness of the application suite.
1 MTSS
The MTSS application is currently one that allows students to work on their problem solving skills through a variety of mathematical concept problems. The application currently contains problems that can be done to cover many math concepts. The user also has the ability to select problems in the database according to categories (such as skill level, grade, and use of a calculator) set for the problem. After answering the questions associated with a problem, the user gains instant feedback about the correct answers in the form of a feedback page.
2 GW and USA
Both GW and USA have finished with the basic conception and functionality planning behind their application suite contribution. The current view of GW and USA provides a user the ability to navigate to specific regions and countries or states, respectively, through a series of interactive geographical maps. Once a country or state has been selected in these applications, a user is able to view information pulled from a general database about it that serves as a general reference tool along with maps and flags for the selection. A further enhancement to the applications is the comparison tool, which allows the user to select up to ten countries or states for a generated bar graph to appear for easy visual representation of many of the numerical facts available. Additionally, USA has the ability for interaction through a small series of games that include matching state names to their placement in a US map and matching state flags. Overall, the two geographical applications of the suite serve mainly as reference tools in a web-based format that students can easily navigate around and view. It is the team’s further intent to increase the interactive features of these applications in order to appeal to students in grades third through sixth.
3 SASF
The SASF team has provided common functionality through basic classes and methods that the developers of the MTSS, GW, and USA applications can use. This subteam has taken constant feedback in regard to further common functions to be added to the available development libraries for the applications. This team has also maintained the status of the development server that is being used for the entire Ongo8 project through maintenance of usernames and passwords, keeping the server running, and keeping the PHP version up to date.
4 Current Semester Accomplishments
The Fall 2005 semester has brought many changes to the K-12 Application Support team as a whole. With the merge of GW and USA, it has only been natural for the other subteams to merge as well for working on common projects that pertain to the application suite, such as documentation. The subteams have also explored individual projects for their particular applications as well.
The current semester has brought the subteams together for tasks involving documentation of the application suite. The semester began with the teams working on a user manual (see Appendix B) that would serve as the means to introduce teachers and administrators to the suite. While a previous semester’s team had submitted such a document, this semester’s group had the task of making the manual more visually appealing and uniform in description. From work with the user manual, the team realized by looking through each application that further work and refinement was needed before the suite was to be deployed. Working as a team, individuals took on the task of searching through at least two applications to find errors with functionality, grammar, and appearance. This list was then compiled and saved for the current semester of work and subsequent semesters.
As for individual subteam work, each has pursued tasks that are still needed for their application. MTSS has continued research and support for their problem solving algorithm implementation. GW and USA have further looked into finding a database source in order to keep the applications current. SASF has taken this semester in improving documentation of the workings behind coding in PHP, the server, and CVS control of code as well as cleaning up the server.
5 Work Yet to be Completed
While progress has been made since project definition in 2001 to the current semester, there still remains work yet to be completed before the application suite will be fully functional and ready for deployment. Like the current semester accomplishments, tasks that remain to be completed pertain to both the application suite as a whole and with individual application work.
Overall, the application suite is seen as a functional software program addressing the issues of supplementing mathematical problem solving and geographical concepts. In order for the suite to be completed, future work will be needed in addressing the issues the team came up with as a whole regarding functionality, grammar, and appearance problems. Some of these will hopefully be completed yet this semester, with the remaining being left for future semester teams.
As for individual application work, each subteam has a few tasks they hope to implement in making the application even more functional in providing grading capabilities, interactive features, and stability.
2 Acknowledgements
The entire Ongo8 team would like to extend thanks to Dr. John Lamont and Professor Ralph Patterson III, the faculty advisors, for the guidance they have provided and will continue to offer throughout this project.
3 Problem Statement
The general purpose of the K-12 Teaching Application Support team is to design Internet-based teaching software applications. The project will include the development of a framework that all other applications will rely on for support. The project will result in a set of three teaching applications: MTSS, GW, and USA. These applications will provide children in elementary school grades third through sixth the opportunity to exercise their computer skills while learning about important lessons. MTSS will emphasize the teaching of core mathematical skills and strengthening mathematical problem-solving techniques. GW and USA will provide an interactive way to learn about both world and United States geography, respectively. The application structure is seen in Figure 1 below. The applications will focus on teaching these skills that have been identified as problem areas for students Teachers and administrators will be allowed access to student progress reports and will be able to customize lessons. The lessons will be able to be varied in both subject matter and difficulty at the teacher’s discretion.
The proposed approach for designing and implementing this application is to create web-based software that will allow students to access a server from their own computer, otherwise called a client. The communication between the client and the server will be accomplished via the Internet. Depending on the information provided by the client, the server will generate a custom web page for each individual client; i.e., administrator, teacher, parent, or student. A database will be developed in order to generate example problems, homework problems, practice quizzes and performance quizzes. In order to aid students in developing their problem solving skills, a problem-solving algorithm will be implemented to walk students through the steps of solving problems. The geographical software will also provide educational games for students to use to practice world and United States geography. Developments of a software framework which will support web tools that will allow students to keep track of their score via user accounts and allow teachers and administrators access to customize lessons, quizzes, and problems and will allow them to evaluate a student’s performance. This will be accomplished by utilizing dynamic web pages written using PHP, SQL, and HTML.
4 Operating Environment
The MTSS, GW, and USA applications and SASF framework will run on LAMP (Linux – Apache – MySQL – PHP) architecture. The client software needs to function on both PC-compatible and Macintosh-compatible machines, which are both used in the school computer laboratory environment. The web application code will be written in PHP language, which runs as a module on the Apache web server. The software will integrate with a database called MySQL to interact between the client and the problem database. This will be run in the Linux operating system. This allows a powerful open-standards environment for the web applications to run. The applications will be running on a three-tiered system as a means of providing interaction between clients, software, and the database, as seen in Figure 2 below.
[pic]
Figure 2. Three-tiered interaction between software and client.
5 Intended Users and Uses
This section identifies the intended users and uses and the characteristics of each. There is a hierarchy of user levels within the educational software. The specified application interface is personalized depending on the group membership of the authenticated user.
1 Intended Users
The intended users of range over a broad group of people and include the following in Table 2 below.
Table 2. User Group and Description
|User Group |User Description |
|System administrators |School staff in technical positions in maintaining school hardware and software needs |
|School administrators |School staff in managerial positions |
|Curriculum coordinators |School faculty in charge of generating course content |
|Teachers |School faculty directly involved with teaching students course material |
|Students |Third through sixth graders using the Ongo8 educational software |
|Parents |Guardians of students in grades third through sixth |
|Guests |Anyone outside of the persons mentioned above who have permission to test the educational software |
|Developers |Members of the Ongo8 senior design project team and future application designers and maintainers |
2 Intended Uses
The application framework will be run in a web-based environment. Table 3 below shows the access levels of the major user groups.
Table 3. User Group and Uses for the Application
|User Group |User Uses for the Application |
|System administrators |System administrators will maintain the system the framework is running on and provide technical support to other |
| |users. |
|School administrators |School administrators will use the data to see how students are doing, and compare this to the national average. |
|Curriculum coordinators |Curriculum coordinators will use the data to see how a certain teaching method worked as compared to the previous |
| |tested methods and add general problems to the database. |
|Teachers |Classroom teachers will use the data to see how a particular student is doing, and possibly view the class average. |
| |Teachers can also add more student users, parent users, and class-specific problems to the database. |
|Students |Students can view their own scores and run applications. |
|Parents |Parents of enrolled students can see their child’s score and the class average. |
|Guests |Non-school affiliated visitors can browse example student records and view class averages. They can also run the |
| |applications without being tracked. |
|Developers |Software developers can do testing and development of SASF as well as utilize SASF methods. |
6 Assumptions and Limitations
Similar to many other projects, there are always a series of assumptions and limitations that need to be taken into account. This subsection of the report intends to spell out those assumptions and limitations with regard to the MTSS software project.
1 Assumptions
Assumptions were made for the Ongo8 project that is based around the client and those of the development team.
1 Client-Centric Assumptions
The assumptions the team has set for the client are the following:
• All client computers are connected to the Internet, with sufficient connection speed to support the project.
• Clients are operating Internet Explorer (Version 5.0 or later) or Netscape (Version 5.0 or later).
• Client computers have enough processing power to run Internet-based applications.
• Computer expertise will be available locally to assist clients in troubleshooting problems with local software and internet connections and to assist the students when they are using the system.
• No students using the software will have disabilities involving sight, dexterity or reading comprehension.
• The students will have been exposed to the relevant topics prior to their use of the software. This software shall be a supplement to classroom instruction.
• The applications may be used at home with parent supervision and in a classroom environment with teacher supervision.
• Not all students will have access to computers in their homes.
• During development, support for the software will be provided via k12spprt@iastate.edu. This email address can be used to contact the Ongo8 team.
2 Team-Centric Assumptions
The assumptions the team has set for the working environment of the team are the following:
• Team members will have permission to access the server database.
• Final builds of the applications will be hosted on a computer managed by the Department of Electrical and Computer Engineering.
• The teams will have access to a development environment on a separate machine from the production environment.
• The framework will have a high level of stability.
• The applications will not use proprietary web browser extensions or enhancements.
• The framework will be used by future developers to create additional educational applications.
2 Limitations
Limitations were made for the Ongo8 project that is based around the client and those of the development team.
1 Client-Centric Limitations
The limitations the team has set for the client are the following:
• Internet connections and speeds are limited and may not be consistent or reliable.
• Computer/processor speeds of the client machines are limited.
• Younger students may not have prior experience using computers or know how to type. Students should be able to interact with the program in a way appropriate for their age level.
• The total number of users from all participating school districts will be no more than 40,000.
2 Team-Centric Limitations
The assumptions the team has set for the working environment of the team are the following:
• New team members may not be familiar with PHP or MySQL.
• The size of the database is limited by MySQL.
• The implementation of portions of the problem solving algorithms may be impractical.
• The PHP language is under development; it is possible that updates must be made to adapt to feature deprecation.
• A limited number of applications will be running on the framework at any one time to prevent overloading the server.
7 Expected End Product Description
The expected end product upon completion of the K-12 Application Support project will be a web-based application suite to be used by students and teachers of community school districts. With an emphasis on supplementing mathematical problem solving and geography skills, the application suite will be a learning tool teachers can use to gauge the efficiency of their students’ progress in these subject matters. It will contain three applications in order to provide an online interactive environment for teachers and students. These applications will be based on the fourth, a framework application, which will tie them all together. Students will be able to log in and use any of the three applications. By entering MTSS, students will be able to work on solving mathematical word problems. In GW and USA, students will learn about geography and then solve problems on selected topics. As the software nears deployment to the client, the Ongo8 team will be available under the k12spprt@iastate.edu email address for any concerns that come up and the ability to simulate the problem with their own version of the software. The end product should be thoroughly tested software that provides benefits to both teachers and students.
Product Accomplishments and Current Status
This section identifies the work that has been accomplished in the past, the work accomplished on this project this semester, the required activities for future semester teams, the current project and end product status, and recommendations for continued effort.
1 Previous Accomplishments
This section has been divided into subsections pertaining to the entire Ongo8 team and individual sub teams.
1 Overall
This is the first semester Ongo08 has attempted to function as a single group. We have no previous accomplishments as a group on record at this point.
2 MTSS
The next subsections detail the previous work that has been accomplished for the MTSS team since its incorporation in spring semester 2001.
1 Spring 2001
With the project and the technical approach well defined, the spring 2001 MTSS team devoted the vast majority of their time to researching the implementation of MTSS. The primary area of research was the ASP language. Several practice pages were developed 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 agreed upon. The following list contains the significant goals accomplished by the MTSS team for the spring 2001 semester:
• Team members learned the ASP programming language
• Experimenting using ASP with database
• Several different architectures and routes was planned out for the project
• One of the architects was agreed upon
2 Fall 2001
After the first semester, hours upon hours had been dedicated to research and meetings, but nothing of ultimate use to the project had been developed. With the glaring lack of measurable productivity at the forefront, the Ongo08 team decided 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 several ASP pages that will add, read, and update fields in the database.
• Developed 8 problem pages that present basic mathematical story problems to students. The problems include graphics and multiple parts.
• Recorded the students' answers to the developed problems, compare the students' answers with correct answers stored in a text file, store the final percentage in the database, and the students' answers in a text file.
• Developed coordinator pages and functions that will allow teachers/coordinators to login/logout, add students, and edit student profiles.
• Developed a text-based menu that will provide an intuitive interface to the MTSS ASP pages.
3 Spring 2002
With the completion of the initial prototype, the main 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 completely redesigned as a more effective and efficient approach was taken as described in the Technical Design section.
• Delete student - This option allows the teachers/computer coordinators to delete students from the database.
• Add/edit/delete teachers - These options allow a computer coordinator to create teachers, edit and delete teachers and their students.
4 Fall 2002
The 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 to replace ASP as the scripting language, while MySQL was to replace Microsoft Access for the backend database. This represented a significant turning point in the project – for all the code written needed to be changed to adopt the new and preferred technologies. At the same time, it was felt 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
• Debugging 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 ready for demonstration to the teachers for testing and evaluation.
5 Spring 2003
The main focus of the MTSS team in spring 2003 was to begin the conversion of the ASP code to PHP using a free, third party software. The accomplishments during this semester were cut short by circumstances that were beyond the control of the team. For example, the team had planned a lot of its semester work to make changes to the software based on the recommendations of the ACS teachers. However, the intended meeting with the teachers, which was scheduled to take place sometime in March, never took place, resulting in the team having to abandon that activity for the semester. Another unforeseen delay was caused by the decision to adopt a new PHP implementation framework for MTSS. 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)
• Update the ASP code to have a version ready for demonstration to teachers
• Testing of all web pages created to date
• Addition of new fraction problems to the database
6 Fall 2003
The successful conversion of MTSS from ASP code to PHP was a major achievement in fall 2003. Also, the database was successfully converted from Microsoft Access to MySQL database backend. Above and beyond, the MTSS team was planning to contact the ACS teachers at the very beginning of the semester, but unfortunately due to some unforeseen circumstances, it did not happen. The initiative to contact the ACS teachers was to get feedbacks from them regarding the implementations and functionalities of MTSS. Unforeseen circumstances such as debugging and coding also made the team to spend more time on programming instead of getting the 100 fraction problems done on time. At the end, only 75 fraction problems were added into the database in this semester.
• Debugged and deployed ASP version
• Restructure 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 total)
• Development of a testing matrix for keeping track of bugs in the software
7 Spring 2004
The following list summarizes the goals of the Spring 2004 MTSS team:
• Debug PHP version
• Restructure MySQL database to comply with the framework
• 50 problems to be added into database for every month
• Development of a new testing matrix for keeping track of software bugs before sending out the software to clients
• Completed framework integration for login and authentication
• Documentation completed
8 Fall 2004
During the Fall 2004 semester, the main goal was to continue the research that was started last 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, a quizzing application would to be completed by the end of the semester that will give teachers the ability to create/edit/maintain quizzes. Here is a summary of what the Fall 2004 MTSS team accomplished:
• Created a category matrix to organized the problems
• Added 20 new problems in the database
• Worked on converting text file to DB
• Create and improvise an effective problem solving algorithm report
• Finish coding for various parts of the quizzing application
9 Spring 2005
The following list describes the significant accomplishments made by the Spring 2005 MTSS team.
• Research Problem Solving Techniques - This task was only partially completed because the team came across a new contact with which to teach the problem solving algorithm 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.
• Gradebook Functionality - The goal of this task was to implement software that would allow students the ability to take quizzes, allow for the grading of quizzes, and for grades to be maintained in a database where it will be used by other teams of the K-12 Teaching support software to modify and display.
3 GW
The past accomplishments for the GW team are outlined in the following sections.
1 Spring 2001
The 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 3 shows this original prototype.
[pic]
Figure 3. Globey’s World Prototype
Successes: Creating the standalone application 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.
2 Fall 2001/Spring 2002
After realizing the limitations of Visual Basic and the portability of the application, it was decided to implement GW with the web-based LAMP technologies mentioned earlier. Figure 4 shows a screenshot of the original web-based design of GW.
[pic]
Figure 4. Globey’s World web application, in MySQL and PHP
Successes: Imported stand-alone application to web technologies, including the creation of a MySQL database of country data accessed over the web via webpages written primarily in PHP.
Failures: Database riddled with typographical errata; minimal interaction with school administrators and teachers; aside from comparison page, a general lack of mathematical-related content. Overall presentation could use more polish. Did not leave database and machine passwords readily available for future team members.
3 Fall 2002
With a basic framework in place, the fall 2002 team worked on adding polish to the overall feel of GW. Figure 5 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. They also identified changes to the database that needed to be made in the future. Finally, the team leaders of all the Ongo-08 sub-teams created a cookbook for future teams to use as a reference.
[pic]
Figure 5. Globey’s new look
Successes: The updated graphics look more professional; database errors were fixed, and math concepts were brainstormed. Cookbook idea helped future team members sidestep password and system difficulties that were encountered.
Failures: Took too long to locate all the necessary passwords. As a result, the team fell behind schedule.
4 Spring 2003
The primary accomplishments of this team were spell-checking the country database, creating an outline for the help section, and fixing the country comparison page. A large portion of the team’s effort was spent updating the country database entries to ensure uniformity was used 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. A prototype screenshot (Figure 6) of the country comparison page was created because the previous incarnation 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.
[pic]
Figure 6. Prototype of new country comparison page
With the help of the Department of Electrical and Computer Engineering Computer Support Group, various security upgrades were installed on the project developmental 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 now has uniformity between all entries. The country comparison page works again. The project web server is now more secure.
Failures: Downtime during the server upgrade caused the team to fall behind schedule.
5 Fall 2003
The goals of this team were to make GW more attractive and user friendly. The world and region pages were redesigned to contain new maps that were more geographically accurate to better assist the students’ learning process. The maps also were 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 of this semester 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, whose functionality was improved to be more user friendly with 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 Figures 6 and 7.
|[pic] |[pic] |
|Figure 7. New country comparison page |Figure 8. Old country comparison page |
This team also spent some time coordinating with the USA team in making the two sites look similar 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 this team was the creation of two scripts to assist the development process. The first, which is meant to backup all of the GW data, does 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. It 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.
6 Spring 2004
The two primary goals of this 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. GW was changed from a frames layout to tables. A style sheet was also implemented 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 since an effort had been 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 Ongo8. The team also added an additional level of functionality to GW by creating a region page. Previously, a student could click 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 can 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 can be seen in Figures 8 and 9.
[pic]
Figure 8. Screenshot of Globey’s World Homepage
[pic]
Figure 9. Globey’s World Region Page
7 Fall 2004
The 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 again. Each application added a link to the suite page, allowing users to choose an application and then return to the list and choose another. A screenshot of this page is shown in Figure 10.
[pic]
Figure 10. Single Sign-on Page for Ongo8
The main focus this semester was the implementation of the quizzing framework designed by SASF. Each sub-team 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 11.
[pic]
Figure 11. Quizzing Front Page for Ongo8
4 USA
The USA sub team was initially formed in the fall of 2002. It is a spin-off of the GW project that deals with teaching students about US geography in much the same manner as the topic of world geography is presented. The following subsections describe the events of the USA team from this initial semester of work to spring 2005.
1 Fall 2002
The Fall 2002 semester began for the USA team with conception of design and documentation needed to start such an endeavor. Team members devised a database schema for the state information and proposed a general design layout of the USA application.
2 Spring 2003
The spring 2003 semester had the USA team taking on the task of populating the database with state information. The team had to do this by had from printed almanacs due to the lack of an electronic source database. Once complete, the USA application was functional in providing students the ability to use it as a reference tool about the states. Navigation to the facts about the states was conceptualized and implemented with the use of an interactive United States map. The Figure 9 below shows the first attempt of offering navigation amongst the states’ information pages.
3 Fall 2003
The fall 2003 semester brought with it visual design improvements for the USA application, as seen in Figure 10 below. The team also took this semester to check the database information for errors, as it was possible due to the manual population that had taken place during the previous semester. The team also worked with GW for the conceptualization and implementation of a similar comparison tool feature for the application, except for dealing with states instead of countries. Figure 11 below shows the USA version of the comparison tool at work.
[pic]
Figure 10. New USA first screen with updated map.
[pic]
Figure 11. Comparison tool in the USA application.
4 Spring 2004
The spring 2004 semester began with small changes to the look of the USA application. The team realized that Alaska and Hawaii were currently missing on the main navigation page and were thus added into the interactive graphic. The team then focused its attention to beginning the work behind an authentication login screen. 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 Ongo8 applications, including USA, this authentication would make sure individual student profiles were kept separate.
5 Fall 2004
The fall 2004 semester team used their time to expand upon the current status of the USA application as a reference tool and began to address the need for interactive features to better gear the application towards the intended audience of third through sixth grade students. Two games were implemented with a state theme in enforcing knowledge of state flags and state names. Both games utilized the blank United States map that is similar to that of the main navigation page, seen in Figure 12.
[pic]
Figure 12. Blank US map used for game implementation.
6 Spring 2005
The spring 2005 semester was used to further implement interactive games for the USA application. 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 away the need for manual data entry of the state information in the database backend. The team found a few leads about the database source, but nothing was found to be a definite fix to the problem.
5 SASF
The SASF sub team was initially formed in the fall of 2003. Previously, the May03-01 team, a single-year project team, was responsible for the framework. They 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’s team checked their files into CVS on the sd6 server as a repository named Mercury. The Ongo08d group does not know the successes and failures of this project team. After this, the fall 2003 team made several important achievements.
1 Fall 2003
The accomplishments of the Ongo08d sub team for fall 2003 include the following:
• Project initialization
o The group tracked down and obtained the existing skeleton code from the May03-01 sub team.
o The group reviewed the skeleton code and determined that it did not meet the requirements of a first release of the framework.
• Feature list prioritization
o The group received a list of features from the other three Ongo08 sub teams and discussed possible features to be implemented in the framework with the team’s advisors and generated a prioritized feature list. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The following is the feature list:
1. Basic authentication functionality for the users
2. Registration functionality to add/delete/modify users in database
• Grade books only teachers would be able to view
• Ability to modify/add/delete questions by the teacher
• Quizzing functions with a library of math based questions
• Teacher/parent able to login and view student's progress
• Timing feature for quizzes & documentation of number of tries
3. Different classifications of problems (different difficulty levels)
• Creation of CVS repository
o The group placed the repository on the sd6.eng.iastate.edu in the /home/framework folder
o The group checked the May03-01 skeleton code into the repository as Mercury.
o The group created a new folder for the current semester’s files, called Venus.
o Appendix A contains further information on accessing the sd6.eng.iastate.edu server to store or retrieve files pertinent to the Ongo08 sub team by using the WinSCP3 application.
• Creation of authentication library (Figure 14)
o The group created a library with methods for authenticating users in the applications. The following method can be used by the applications to authenticate users:
1. authenticate(MySQL connection, string username, string password)
• Creation of registration library (Figure 14)
o The group created a library with methods for registering users with the system. The following methods can be used to register, unregister, or update users with the system:
1) registerUser(connection, object user)
2) unregisterUser(connection, string username)
3) updateUser(connection, string username, object newUser)
▪ Creation of User Class (Figure 13)
▪ Allows for the authentication and registration of all users. Without this class neither of these libraries would function.
• Creation of test cases for the above two libraries
o The group created test cases for both the authentication and registration libraries.
o These test cases are described further in the “Testing and Modifications” section found later in this document
• Documentation
o The group created instructions on how to access the framework files.
o The group created an overall framework document, included in a separate document, to be given to the other Ongo08 sub teams as a reference for the framework libraries. The document is included on the CD to be delivered to Dr. Lamont and Professor Patterson.
[pic]
Figure 13: Class Diagram
[pic]
Figure 14: Library File Diagram
2 Spring 2004
The accomplishments of the SASF sub team for spring 2004 include:
• Project initialization
o Obtained materials from the previous term, fall 2003.
o Reviewed PHP and written framework code for new members.
o Taught PHP to new members of application groups.
o Taught integrating framework methods.
• Feature list prioritization
o The group received a list of precompiled features from the previous framework team. Based upon this previous prioritized feature list an updated copy is seen below. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The table below shows the spring 2004 list.
Table 4. 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 |Grade books only teachers would be able to view |TBA |
|4 |Ability to modify/add/delete questions by the teacher |spring 2004 |
|5 |Quizzing functions with a library of math based questions |spring 2004 |
|6 |Teacher/parent able to login and view student's progress |TBA |
|7 |Timing feature for quizzes & documentation of number of tries |TBA |
|8 |Different classifications of problems (different difficulty levels) |TBA |
• Collection of necessary quizzing functionality
o The group met and discussed with the application groups to determine the methods required/requested.
o Upon meeting with all three groups the framework team found the base set of functions necessary to implement every action requested by all applications.
• Database requirements document
o From the discussions with the groups, the framework team created and revised a list of functions, SQL tables, and uses for all actions requested.
o The list was distributed to all groups and was revised based upon needs and wants the groups expressed.
o The final database requirements documented was completed and distributed to the application developer groups.
• Creation of quizzing library
o The group created a library with methods for adding, removing, and modifying quizzes/questions/images.
o The library is tested and is now found in the current stable distribution of the framework.
• Creation of SQL database tables
o The group created a series of SQL tables to store data within for quizzing functionality.
o These tables include (as shown in Figure 15):
▪ Quiz Table
▪ Quiz Problems Table
▪ Problems Table
▪ Problem Choices Table
▪ File Catalog Table
• Creation of test cases for the quizzing library
o The group created test cases for the quizzing library to allow for stability and error testing.
o These functions can be found within the CVS repository under /home/framework/repository/venus/test
• Previous library code improvements
o Improvements were made to the existing library code to allow for greater flexibility and ease of implementation.
▪ Stored the server address into the globals file
▪ Allowed for greater flexibility within the authentication and registration library functions
• This helped in the event that a server change was necessary
• A user would not have to go through each file to change the server name
o Improved authentication to work properly
• Documentation
o The group created a project focus matrix to determine every groups goals and focus for a given term.
o The group created an overall framework document, included in a separate document, to be given to the other Ongo08 sub teams as a reference for the framework libraries. The document is included on the CD to be delivered to Dr. Lamont and Professor Patterson.
• Application support
o The group initiated and supported the groups during their integration of the framework into their applications.
[pic]
Figure 15: Quizzing Tables Diagram
3 Fall 2004
The accomplishments of the Ongo08d sub team for fall 2004 include the following:
• Project initialization
o Obtained materials from the previous term, spring 2004.
o Reviewed PHP and written framework code for new members.
o Taught PHP to new members of application groups.
o Taught integrating quizzing framework methods.
• Feature list prioritization
o The group received a list of precompiled features from the previous framework team.
o Based upon this previous prioritized feature list an updated copy is seen below. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The following is the feature list, shown in Table 5.
Table 5: Fall 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 |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 |
|6 |Improve authentication so it is more secure and can store a greater number of user fields |TBA |
|7 |Answer conversion functionality for text answers |TBA |
|8 |Timing functionality for quizzes |TBA |
|9 |Garbage collection utility to remove unreferenced data from tables |TBA |
|10 |Additional security to guarantee that users can not modify quizzes/problems of other users |TBA |
|11 |Optimize code so that it uses less resources |TBA |
|12 |Large-scale testing to guarantee that framework will work in multiple environments under multiple conditions |TBA |
|13 |Improved developer documentation |TBA |
|14 |End-user documentation |TBA |
• Collection of necessary grading functionality
o The group met and discussed with the application groups to determine the methods required/requested.
o Upon meeting with all three groups the framework team found the base set of functions necessary to implement every action requested by all applications.
• Database requirements document
o From the discussions with the groups, the framework team created and revised a list of functions, SQL tables, and uses for all actions requested.
o The list was distributed to all groups and was revised based upon needs and wants the groups expressed.
o The final database requirements documented was completed and distributed to the application developer groups.
• Creation of grading/overall library
o The group created a library with methods for adding, removing, and modifying the process of keeping track and recalling results of a quiz that a student took.
• Creation of SQL database tables
o The group created a series of SQL tables to store data within for grading/overall functionality.
o These tables include (as shown in Figure 6, on page 24):
• School
• Administrator
• Course coordinator
• Teacher
• Parent
• ParentsToStudents
• Student
• SectionsToStudents
• Section
• SectionQuizzes
• QuizRecords
• ProblemsAnswered
• Creation of test cases for the quizzing library
o The group created test cases for the grading library to allow for stability and error testing.
o These functions can be found within the CVS repository under /home/framework/repository/venus/test
• Previous library code improvements
o The improvements made to the existing library code allowed for greater flexibility and ease of implementation
o These benefits included:
▪ An improved method of obtaining errors from the framework was created. In particular, the ability to return an error saying exactly what value passed into a framework function was invalid was added.
▪ A quizCreator field was added to the quiz table to allow the creator of the quiz to be remembered.
▪ A quizPrivate field was added to the quiz table to allow a quiz to not be viewable by anyone except for the owner and creator of the quiz.
▪ Additional global variables, representing the different applications, were added to the globals file, allowing a more standard way of storing the subject of a quiz and problem.
▪ A getUserByCriteria method, which allowed searching for users, was created.
• Documentation
o The group updated a project focus matrix to determine every group’s goals and focus for the given term.
o The group created an overall framework document, included in the appendices of this status report and also existing as a separate document, to be given to the other Ongo08 sub teams as a reference for the framework libraries.
• Application support
o The group initiated and supported the groups during their integration of the quizzing framework into their applications.
o The group wrote documentation for ease of use of quizzing framework.
4 Spring 2005
The accomplishments of the Ongo08d sub team for spring 2005 include the following:
• Project initialization
o Obtained materials from the previous term, fall 2004.
o Reviewed PHP and written framework code for new members.
o Taught PHP to new members of application groups.
o Taught integrating grading framework methods.
• Feature list prioritization
o The group received a list of precompiled features from the previous framework team.
o Based upon this previous prioritized feature list an updated copy is seen below. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The following is the feature list, shown in Table 6.
Table 6: Spring 2005 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 |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 |
|6 |Improve authentication so it is more secure and can store a greater number of user fields |Spring 2005 |
|7 |Answer conversion functionality for text answers |TBA |
|8 |Timing functionality for quizzes |Spring 2005 |
|9 |Garbage collection utility to remove unreferenced data from tables |TBA |
|10 |Additional security to guarantee that users can not modify quizzes/problems of other users |TBA |
|11 |Optimize code so that it uses less resources |TBA |
|12 |Large-scale testing to guarantee that framework will work in multiple environments under multiple conditions |TBA |
|13 |Improved developer documentation |TBA |
|14 |End-user documentation |TBA |
|15 |Ability to classify problems by purpose and difficulty |Spring 2005 |
• Collection of necessary functionality for timing, classification, and authentication
o The group met and discussed with the application groups to determine the methods required/requested.
o Upon meeting with all three groups the framework team found the base set of functions necessary to implement every action requested by all applications.
• Creation of functionality
o The group created new code delivering the required functionality.
o This functionality includes:
o The ability to time quizzes
o A rewrite of the authentication code to provide security and functionality
o The ability to classify problems by difficulty and purpose
• Creation of test cases for the new code
o Individuals of the group created test cases for code they developed.
o The group created test cases for all newly developed code to allow for stability and error testing.
• Documentation
o The group updated a project focus matrix to determine every group’s goals and focus for the given term.
o The group updated an existing overall framework document.
• Application support
o The group initiated and supported the groups during their integration of the quizzing framework into their applications.
o The group responded to and assisted with troubleshooting of numerous issues uncovered by the other subteams.
• Server support
o The group performed troubleshooting and analysis on the project’s server and determined there was hardware failure, resulting in unpredictable server crashes.
o The group worked with the Computer Support Group (CSG) to create a virtual server on one of CSG’s physical servers.
o The group assisted with the migration of files and applications between servers.
[pic]
Figure 16: Overall Tables Diagram
2 Present Accomplishments
The following list describes the significant accomplishments made during the current school session fall 2005.
1 Overall
Progress has been made in problem definition, manual creation, end product testing, end product documentation and reporting as an overall team.
1 Uniformity between Sub Teams
This semester it was decided to combine the documentation from all the Ongo08 sub-teams, so the individual components were integrated into documents that covered the whole software suite. Broadening the scope to include all of the sub team projects allowed the team to remove redundant information that had previously been stated similarly in the individual sub teams’ documentation. This also provided a way of making the applications more uniform and gave members of the sub-teams a better idea of the whole software package. A major goal for the semester was to create uniformity between MTSS, USA, and GW. Therefore, in addition to the documentation, uniform styling and links for the applications were created.
2 Problem Definition
Ongo08 defined the project goals for the fall 2005 semester and held a software-training course to define the problem for this semester.
• Problem Definition - The project goals for the fall 2005 semester were defined. A list of the project goals and expected end products was developed and given to all members of Ongo08. The project goals clearly define the tasks at hand and how to accomplish each task. Deadlines and scheduling for the goals and tasks were also outlined.
• Software Training Course - A training session teaching the basics of PHP, MySQL, and CSS was held on October 16, 2005. As a result all team members became more acquainted with the overall K-12 Teaching Application Support Software, and more familiar with PHP, MySQL, and CSS by completing tutorials prepared and presented by the Ongo8d team.
3 Manual Creation
The entire Ongo08 team worked together on creating a manual (see Appendix B) for the K-12 Teaching Application Software during the fall 2005 semester. The manual was completed and reviewed by the team as well as the project advisors.
• Writing the Users’ Manual – A manual was created to aid users in learning the overall use of the K-12 Teaching Application Software. The manual included complete definitions of all functions of the software, along with step-by-step instructions for all functionality. This manual was also used in testing purpose to make sure the software would be easy to use with instructions and to find bugs in the software.
• Reviewing the Users’ Manual – To have a manual of high quality produced, the manual was reviewed by the team and advisors. To ensure that the manual was of high quality, the advisors walked through the software using the manual.
4 End Product Testing
End product testing was performed on the teaching application and a list of bugs (see Appendix A) was compiled.
• Test Planning – Each member of the Ongo8 team took on the task of looking through their own application and chose another from the remaining two. This allowed for team members to become familiarized with the other applications found in the software suite.
• Actual Testing – Upon completing the testing, a list of bugs for each application was compiled. Work will be done to repair these bugs in the last portion of this semester and the list will be maintained so this work can continue in future semesters.
• Test Results Evaluation – Lists of have been compiled of all bugs in each application to evaluate, test and fix.
5 End Product Documentation
Creating maintenance and support documentation has been completed. The project reports, manual, and bug list written this semester will be available for review by future teams. These documents, as well as any files created during the fall 2005 semester will be available on the website.
6 Project Reporting
Progress on the K-12 Teaching Application in fall 2005 was documented in emails, the required documentation, and the presentation.
• Semester Plan - A document clearly defining the goals and schedule this semester was completed.
• Status Report - A comprehensive status report was produced documenting the background of the project, the work accomplished so far, and the forecasted future completion date. This report will inform advisors and Ongo08 team members of the latest developments with the project.
• Weekly E-mail Reporting - The communications coordinator for Ongo08 kept the advisors posted on the developments in the project through weekly emails. Through the weekly emails, the teams were able to evaluate the status of the project.
• Presentation to Senior Design Class – Ongo08 has presented their project to the CprE/EE 491 class on November 8, 2005. The team used the presentation as practice for the end of semester Industrial Review Panel presentation. Presentation feedback was gathered from the advisors and students in the CprE/EE 491 class.
• Industrial Review Panel (IRP) Presentation – The IRP presentation will be given on Wednesday, December 7, 2005.
2 MTSS
This section contains information on the present accomplishments of the MTSS sub-team.
1 PSA Implementation
MTSS worked this semester on the problem solving algorithm and a method for its implementation.
• Refine PSA – Refining the PSA is only partially completed. MTSS has met with Ann Thompson, a contact in the Curriculum and Instruction Department at Iowa State University, to discuss some approaches for different learning styles. Some of this work has been put on hold due to other priorities in the project such as creating a manual, fixing bugs, and cleaning up files and documentation on the server, but documentation will be done to keep a record of the current progress made so far for the PSA.
• Define Method for Implementation of PSA – The defined method for implementing the PSA is only partially completed as most work this semester has been put towards documentation, creating a manual, and identifying and fixing bugs. Some general ideas and their pro and cons for the PSA have been discussed in the previous semester, spring 2005. Several proposed implementations have been presented to our project advisors and a preliminary implementation plan has been chosen.
• Planning for Implementation – The PSA has been selected and a preliminary implementation scheme has been chosen. The remaining task is the implementation of the problem solving algorithm into MTSS. This should be done during the spring or fall 2006 semesters.
2 Equivalent Answers to Questions Implementation
The need for equivalent answers to problems to be marked as correct has been discussed several times in meetings with the project advisors. A method for implementation has been discussed as well as the priority of this implementation.
• Refine Understanding of Equivalent Answers – In meetings with the project advisors MTSS has discussed the proposed equivalent answers capability that should be adopted. The current plan is to look into fraction, decimal, and word answers that can be figured as equivalent for a given problem.
• Define Methods For Implementation – Possible methods for implementation have been suggested to the project advisors and evaluated. A single method for implementation has not yet been chosen.
• Planning for Implementation – Pending the selection of a method for implementation it is unrealistic to plan for the implementation of this function.
3 USA and GW
This section will describe the current semester’s accomplishments for USA and GW.
1 Game Research and Planning
As the GW and USA applications stand, they make good reference tools for students to use in gathering geographical information. It is the team’s intent to make these applications more interactive with the implementation of games. While USA currently has two working games, the team has plans to expand implementation of similar type games to the GW application as well as create more in both applications. It has been brought up to even include other school subjects such as math, spelling, and the knowledge of national landmarks into these future games.
2 Database Research
Currently, the GW application uses the CIA database to gather its information about the various countries around the globe. There does not exist such an electronic database for the USA application as of yet. Through research this semester, the team focused on trying to find an electronic source for U.S. geography data. Upon finding a trustworthy source, both applications will be updated to have automatic update features so that the information shown is the most up to date for the students.
4 SASF
This section will describe the current semester’s accomplishments for SASF.
1 Code Revision
The grading functionality that was designed and created during Spring 2005 was thoroughly tested and validated before being released to the other Ongo08 sub-teams. In addition, features were added to the grading functionality at the request of the other sub-teams. Additional fields were added to the quizzing table that would allow a quiz to both remain private and be controlled by the person who created the quiz. Also, additional global variables were created representing the applications being developed. This allowed for greater commonalities in the table entries being made by the quiz creators, and greater ease when using these table entries.
2 Software Releases
Several changes were made to the way that both Ongo08d released its framework to the other sub-teams and the way the other sub-teams made their applications accessible to the clients. In past semesters, the other sub-teams had to download the framework code from the Ongo08d website, extract and reference that code stored in their own directories, and create their own databases to store their data. This semester, a new method of framework distribution has been defined. All other sub-teams reference the code that is stored in the framework sub-team’s directory. Two code locations exist, one for stable code and one for testing code, and all data is stored in a common database. Also in previous semesters, each sub-team had a different web link to access their application. This semester, a single sign-on page was created which allowed a user to go to one page to access any of Ongo08’s applications, with links to each individual application on that page.
3 Grading Functionality
The primary goal for Fall 2005 was threefold: first, to create a set of functions and SQL table entries to allow for the timing of quizzes; second, to create the functions and SQL table entries to allow individual problems to be classified by purpose (homework problems, quiz problems, etc.); and third, to rewrite the authentication code to allow logout capabilities and to increase security. Based on meetings held in this and past semesters with the other sub-teams, a list of proposed functions and calls were generated. From these functions a set of tables was created that holds the information the applications required. These proposed functions and tables were presented to the other sub-teams for approval.
4 New Testing Functions
Testing methods for the new release of the framework, were created by the developers of the framework for the framework team to be able to quickly view if the scripts had any errors or issues that could cause the code to become unstable.
5 Additional Documentation
Additional documentation of the framework was created in a format that can be easily updated and maintained in future semesters. Updates were made to the existing ‘cookbook’, from which the other software developers can ascertain how to use a given function. Along with the presently existing deliverables (project plan, project poster, project Power-Point presentation, and a status report), this ‘cookbook’ provides do-it-yourself documentation and enhances the application support for the framework.
3 Future Required Activities
This section includes information about what is required in terms of activities and deliverables for future sessions. It is divided into separate semesters and looks ahead three semesters. The summary does not include Gantt charts for work as the exact dates of each activity and deliverable should be decided upon by the team. Estimated resources should closely match the exact resources occurring this semester and are shown in the resources section of this document.
1 All Future Semesters
The following activities are recommended for completion by each semester of this project.
• Review existing code
Objective: To look at code that was written by the previous group
Approach: Review what has been written and what its purposes are
Results: To have members learn what coding has been done and how it was done
• Continue code documentation
Objective: To lower the learning curve of using the framework
Approach: Follow the format of the framework documentation and update the documentation accordingly throughout the semester
Results: More complete documentation of the framework
• Support feature list for Ongo08
Objective: To support the required features for the existing applications
Approach: Use the PHPBB application to have other sub teams file feature or support requests to the team. The team will then delegate the tasks to be done if the feature is accepted for the framework, and propose a deadline of the next stable release with any accepted feature.
Results: Future and ongoing support of new common features between applications
• Write test cases for new code
Objective: To test the reliability and stability of the code
Approach: Each member performs their own testing on a selection of the code (which they have not written) to test for any possible bugs in the code.
Results: The framework should be more stable and reliable after exhaustive testing
2 Spring 2006
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:
• Answer conversion functionality for text answers
• Garbage collection utility to remove unreferenced data from tables
• Alternate quiz timing functionality and analysis
• Distribution for real-world client testing of current feature set
3 Fall 2006
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:
• Additional security to guarantee that users can not modify quizzes/problems of other users
• Optimize code so that it uses less resources
• Large-scale testing to guarantee that framework will work in multiple environments under multiple conditions
4 Spring 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:
• Improved developer documentation
• Additional functionality from spring and fall 2006
4 Recommendation for Continued Effort
Four possible recommendations that exist for the next phase of this ongoing project are the following:
1) Continue the project as originally envisioned
2) Alter the range of the project in a logical direction before continuing
3) Abandon the project
4) Devise the basis specs for another application
The Ongo08 team has decided to recommend the first alternative: continuing with the project as originally envisioned. The project is on track now that a system has been put into place providing documentation and source control for all of the team members. CVS is controlling the versions of all the files on a remote server that all team members can utilize. The code will be there at the start of the semester for future teams so the members will not have to extend the time and effort to locate the files. A CD will also be provided to future members that contains all deliverables, extra documentation, and source code from this semester’s team.
Documentation of Current Efforts and Results
This section of the report intends to document the work done in the current semester separated into the different components of project development, namely project definition activities, research activities, design activities, implementation activities and testing and modification activities.
1 Project Definition Activities
Project definition activities have been divided into subsections for the entire team and one for each subgroup.
1 Overall
Project definition activities for this semester included a revising and consolidation of the project plan, meeting with Ann Thompson, and formal PHP training.
The greatest portion of the project definition activities was in further development of the project plan. In a change from previous semesters, the four sub teams combined their efforts in creating one common document. It was generally believed that, while combining the project plan represented a greater, more coordinated effort this semester, doing so would reduce the workload in following semesters. The entire Ongo8 team divided up the requirements of the document amongst the sub teams and then into individual team member responsibilities. Final compilation took place during the week before the project plan was due. Combining the project plan as a collaborative effort will not only allow future teams to reap the benefits of a consolidated project plan, but also gave each team the opportunity to meet and work with members from other teams.
The scheduled PHP training covered the basics of the programming language. In attendance were all of the newer members of the team, plus several senior members, who provided support and additional discussion. During the training, the team examined the basics of the language and looked at several examples of code relevant to the project. While all of the intricacies of PHP were not covered fully during this training, it is expected that members will use the knowledge gained during training as a foundation as they gain experience with using PHP during the course of the semester.
2 MTSS
All activities identified in this portion of the project maintained the goal of educating new members of the team on skills that would be used during the implementation of the project, or educating about the past, present, and future plans for the MTSS project.
The meeting with Ann Thompson was helpful in defining the direction of future work of the Ongo08 project. During this meeting, many ideas were discussed, which includes the following:
• Feedback mechanisms (user interface issues)
• Complexity of the problems involved
• Mechanisms for two-way feedback
• Methods for generation of false answers
• Age-appropriateness of the user interface
• Possible addition of features
While this meeting was held after the project plan was completed, the feedback from this meeting will be used to shape established goals and future project plans.
3 USA and GW
The main activities for USA and GW are geared toward the merging of the two previous groups. This merging meant that both GW and USA members had to become proficient with the two applications. The main focus was unifying both applications so that they could look more like two entities of one suite. This later became the same theme for the rest of the Ongo08 project so that it could look like a comprehensive suite with a similar look and feel to each of the individual applications. While working on the uniformity, bugs from previous semesters were found and this also became one of the fundamental goals of the GW and USA team.
4 SASF
The SASF team’s definition of work this semester has dealt with organization, which was identified
2 Research Activities
Research activities have been divided up into subsections for each subgroup.
1 MTSS
The research activities for the MTSS team were based on human computer interaction this semester. The team made an excellent contact last semester in the Curriculum and Instruction Department, Ann Thompson. A meeting with Professor Thompson was held last semester where the current ideas on the PSA were discussed as well as MTSS as a whole. Another meeting with Professor Thompson was held to continue the discussion about MTSS as a whole and its relationship to teacher and student users. Professor Thompson alleviated our fears that students at the targeted levels would have troubles navigating the website and manipulating the technology of MTSS. Professor Thompson also addressed three main issues in her discussion with MTSS, general implementation issues, problem creation issues, and problem solution issues.
• General Implementation
Professor Thompson had a few suggestions for MTSS to consider concerning the overall implementation of MTSS.
o Use short questions that won’t take long for a students to answer.
o Break each problem into small parts before asking for the solution, include a question about the intent of the problem.
o Limit number of questions per page to keep students attentive and make pages easy to read, possibly repeating the original problem on each page.
o Group answer spaces with the question, not together at the end of the page.
o Force students to think about the problem and become interest in the problem and not just the solution.
• Problem Creation
Problem creation is an issue MTSS has discussed greatly over the last two semesters, especially the pros and cons of a few techniques we were considering. Discussing these techniques with Professor Thompson provided MTSS with some excellent feedback and ideas.
o Can be as complicated as necessary, as long as the tool itself is useful and effective teachers will use it.
o Provide a large problem database for teachers to add to, giving them the ability to use the software without creating the problems themselves.
o Allow teachers to use problem templates for easier creation of problems.
• Problem Solution
The implementation of problem solutions is another issue brought up by Professor Thompson. She discussed possible improvements to the current problem solution implementation in MTSS.
o Randomly generate, or have teachers create, a multiple choice list to each problem part.
o Use text fields and have teachers electronically correct problems.
o Use paper to answer questions and have teachers correct problems by hand.
o Ask students to answer questions in the form of a drawing, either by hand or electronically, teachers would have to correct.
o Randomly order sub-problem answers so they aren’t in the same order every time.
Professor Thompson’s input was valuable in that it gave the team the point of view of both a teacher, and someone who is knowledgeable about the acts of teaching and problem solving. With this input the team will be able to better address the needs of its future users and better target the implementation to most appropriately encourage problem solving.
2 USA and GW
The USA and GW projects have come to a functional point of development where uniformity and reliability have become very important. This semester both applications have had little research past continuing to search for a reliable electronic database source of information.
3 SASF
The SASF team spent time researching the code that existed on the server and the location of the code. The team also did research on using a CVS repository to store the code to keep track of changes.
3 Design Activities
This section contains design activities divided into sections for each subgroup.
1 MTSS
The MTSS team has worked more closely with the other K-12 Teaching Application teams this semester than ever before. The design activities addressed by MTSS this semester all relate to the K-12 Teaching Application as a whole and are addressed in that section.
2 USA and GW
The GW/USA team design efforts have been closely related to the uniformity of the entire suite between all of the applications. The team has worked to make both the GW and USA applications look very similar in order to tie them together visually.
3 SASF
The SASF team has created templates for the other sub teams to use to create uniformity in the applications. The team has also devised a structure for the server so future semesters will easily find code.
4 Implementation Activities
This section contains implementation activities divided into sections for each subgroup.
1 MTSS
During the fall 2005 semester MTSS is working on implementing the cascading style sheets (CSS) written by the Framework sub-group. Last semester the need for a more unified look and feel throughout the teaching application became apparent. Framework was given the task of creating cascading style sheets to be implemented by all sub-groups to make the entire site feel more continuous. The CSS have been completed by Framework and will be implemented by MTSS later on this semester.
2 USA and GW
GW and USA have worked on both applications’ comparison pages, cascading style sheets provided by the Framework team, and implementing consistent icons in both applications. The main implementation will be the work done to make all applications feel as though they belong in the same suite visually.
3 SASF
The SASF team has created templates for each sub team to use. The SASF team has also helped the sub teams as they implement code into their projects. The SASF team has also implemented a CVS repository to store code in a more convenient manner.
5 Testing and Modification Activities
This section contains testing and modification activities have been divided up into sections for each subgroup. Figure 17 shows the testing scheme that the Ongo8 team has adopted for testing and development of the application suite.
1 MTSS
The testing and modification activities of MTSS have continued throughout the development of the software and the life of the team. At this point in development MTSS is performing alpha testing continuously, and problems discovered are being logged and corrected. This semester a list was made of all outstanding problems with MTSS. That list will be addressed later on this semester. While it is impractical to solve all the problems discovered this semester the list created will allow the students to continue work on these problems next semester. While these problems are being addressed the Beta testing planned for this semester has been postponed.
2 USA and GW
Lists of bugs and code issues have been created for all of the applications. These issues will be continually addressed throughout the rest of the semester and until each issue has been resolved. Most of the issues were formatting errors or minor problems with page layout. We have also addressed issues involving the most practical way of presenting the information to the children who will be using the applications.
3 SASF
At the start of the semester the SASF team did testing of code that was written last semester. Also as code is written by the SASF team, it is tested first by the person that wrote the code and next by another member of the group. This ensures that all code that is implemented by the sub teams will work properly. This semester the SASF team has also helped the sub teams find bugs with their applications.
Resources and Schedules
The resource requirements section is composed of resource requirements and financial requirements.
1 Resource Requirements
The resource requirements for this project can be broken up into two categories: personnel requirements and financial requirements.
1 Personnel Requirements
The tables below, Table 7 and Table 8, show the estimated and actual personnel requirements for the fall 2005 semester. The team leader will monitor time expenditures and adjust member assignments to try to maintain equality. The attributes of the table and their descriptions include:
• Meetings – Time spent in meetings with faculty advisors, client contacts, or other team members
• Project Reporting – Time spent working on project documentation, poster, presentation, and weekly status reports
• Project Initialization – Time spent doing preliminary work on the project and learning PHP
• Coding and Testing – Time spent going through existing code, writing test cases, and creating a feature list
• Research –Total anticipated time spent on the project
|Team#/ |Member |
|Name | |
|Ongo8b&c |Samantha |
|Globy’s World/ |Olson |
|Uncle Sam | |
|Ongo8d |Nichole |
|Framework |Dugan |
|TOTAL |201 |144 |243 |224 |226 |208 | |
| |David Wire |39 |20 |14 |15 |10 |98 |
| |Sara Murphy |26 |14 |16 |13 |15 |84 |
| |John Saterfiel |26 |12 |15 |15 |13 |81 |
| |Michael Fong |26 |10 |17 |8 |9 |70 |
| |Aaron Hurd |26 |13 |15 |9 |10 |73 |
|Ongo08a Total |182 |84 |91 |75 |74 |506 | |
| |Laurie Bidrawn |39 |15 |14 |10 |6 |84 |
| |Maria Oivas |0 |0 |0 |0 |0 |0 |
| |Nate Evans |26 |8 |13 |15 |10 |72 |
| |Jennifer Carlson|39 |21 |9 |8 |5 |82 |
| |Dustin Fee |26 |14 |15 |12 |9 |76 |
|Ongo08b&c Total |169 |74 |61 |60 |24 |400 | |
| |Nate Gordon |26 |12 |16 |20 |10 |84 |
| |Parikshit Advani|26 |14 |12 |10 |9 |71 |
| |Ryan Adamson |26 |10 |18 |10 |11 |75 |
| |Chun-Pang Kuk |26 |8 |15 |13 |8 |70 |
|Ongo08d Total |143 |54 |75 |72 |46 |390 |
2 Financial Requirements
Table 9 shows the estimated financial budget during the fall 2005 semester. The budget includes items such as parts and materials required to conduct the project and estimated labor costs based upon departmental senior undergraduate wages. The attributes of the table and their descriptions include:
Item: A description of the item grouped into the categories of parts and materials and labor:
• W/O labor: Cost of the item not figuring in labor charges
• With labor: Cost of the item figuring in labor charges
The actual financial requirements are shown in Table 10 below. The discrepancies between the estimated and actual financial requirements are likely due to over estimations in time commitments to be spent on various tasks.
Table 9: Estimated Financial Requirements
|Team# / Name |Item |W/O Labor |With Labor |
|Ongo8a |Labor at $10.50 per hour | | |
|MTSS | | | |
| |Tiffany Schweer | |$1176.00 |
| |Sara Murphy | |$1123.50 |
| |John Saterfiel | |$1092.00 |
| |David Wire | |$966.00 |
| |Michael Fong | |$976.50 |
| |Aaron Hurd | |$945.00 |
| |Subtotal |$0.00 |$6279.00 |
|Ongo8b&c |Parts and Materials | | |
|Globy’s World/ | | | |
|Uncle Sam | | | |
| | Miscellaneous Binding |$5.00 |$5.00 |
| | Copying |$10.00 |$10.00 |
| |Labor at $10.50 per hour | | |
| | Samantha Olson | |$1008.00 |
| | Laurie Bidrawn | |$997.50 |
| | Maria Oivas | |$924.00 |
| | Jennifer Carlson | |$976.50 |
| | Dustin Fee | |$924.00 |
| |Subtotal |$15.00 |$4845.00 |
|Ongo8d |Parts and Materials | | |
|Framework | | | |
| | Miscellaneous Binding |$5.00 |$5.00 |
| | Copying |$10.00 |$10.00 |
| |Labor at $10.50 per hour | | |
| | Nichole Dugan | |$1071.00 |
| | Nate Gordon | |$1008.00 |
| | Parikshit Advani | |$976.50 |
| | Ryan Adamson | |$934.50 |
| | Chun-Pang Kuk | |$924.00 |
| |Subtotal |$15.00 |$4929.00 |
|Total |$30.00 |$16053.00 |
Table 10: Actual Financial Requirements
|Team# / Name |Item |W/O Labor |With Labor |
|Ongo8a MTSS |Parts and Materials | | |
| | Miscellaneous Binding |$5.00 |$5.00 |
| | Copying |$10.00 |$10.00 |
| |Labor at $10.50 per hour | | |
| |Tiffany Schweer | |$1,050.00 |
| |David Wire | |$1,029.00 |
| |Sara Murphy | |$882.00 |
| |John Saterfiel | |$850.50 |
| |Michael Fong | |$735.00 |
| |Aaron Hurd | |$766.50 |
| |Subtotal |$15.00 |$5,328.00 |
|Ongo8b&c |Parts and Materials | | |
|Globy’s World/ | Miscellaneous Binding |$5.00 |$5.00 |
|Uncle Sam | Copying |$10.00 |$10.00 |
| |Labor at $10.50 per hour | | |
| | Samantha Olson | |$903.00 |
| | Laurie Bidrawn | |$882.00 |
| | Maria Oivas | |$0.00 |
| | Nate Evans | |$756.00 |
| | Jennifer Carlson | |$861.00 |
| | Dustin Fee | |$798.00 |
| |Subtotal |$15.00 |$4,215.00 |
|Ongo8d |Parts and Materials | | |
|Framework | Miscellaneous Binding |$5.00 |$5.00 |
| | Copying |$10.00 |$10.00 |
| |Labor at $10.50 per hour | | |
| | Nichole Dugan | |$945.00 |
| | Nate Gordon | |$882.00 |
| | Parikshit Advani | |$745.50 |
| | Ryan Adamson | |$787.50 |
| | Chun-Pang Kuk | |$735.00 |
| |Subtotal |$15.00 |$4,110.00 |
|Total |$45.00 |$13,653.00 |
3 Schedules
Figure 18 shows the actual schedule, of both project work and deliverables, for fall semester 2005.
[pic]
Figure 18. Fall 2005 Schedule.
Closing Materials
This section contains a brief summary of the lessons learned thus far, risks and risk management, general information about the Ongo08 team, and a closing summary.
1 Lessons Learned
This senior design project has presented many challenges, obstacles, frustrations, and learning opportunities for the team members. At the end of the semester, team members were left with a lot of new skills and valuable lessons. A brief summary of some of the team’s most valuable lessons follows.
Things that went well:
• Worked hard to create useful documentation for subsequent semesters so future groups can make more progress early in the semesters.
• Divided tasks among team members to lighten the work load for single individuals to ensure that all team members were involved in the project, and give members the change to learn new skills.
• Created useful documentation for subsequent semesters so future groups can make more progress early in the semesters.
• Documented errors that appear in the current version of the application.
• Combined the end status report with little to no problems.
Things that did not go well:
• Maintaining consistency through out the document, and the teams reaching common goals even though the origination of all three teams may have been different.
• Miscommunication problems when working on the user manual due to many team member perspectives due to the first time working as a complete team in the semester.
Technical knowledge gained by the team:
• The team learned about PHP coding standards.
• The team learned about MySQL coding standards.
• The team learned about source control tools, mainly CVS.
• The team learned about problem solving methods and ways to help kids learn math.
Non-Technical knowledge gained by the team:
• The team learned about how important it is to spend the time initially in a project to generate a complete project plan and schedule.
• The team learned about the importance of documentation, especially in an ongoing project where future students will need to reuse and enhance the current team’s work.
• The team learned how to write instructions for people not familiar with a software tool.
• The team learned how to negotiate and compromise between the various groups.
• The team learned the importance of good communication and leadership.
2 Risks and Risk Management
This section details the potential risks that were anticipated at the beginning of the semester, the anticipated risks that were encountered during the semester, the unanticipated risks that were encountered during the semester, and finally the resultant changes that were made to risk management as a result of encountering unanticipated risks.
1 Anticipated Risks
Below are several major issues/risks and their planned management that the group anticipated at the beginning of the semester that could have occurred in the course of the project’s duration:
• Risk: The PC with the project’s software is stolen, it crashes, or the software is maliciously tampered with or otherwise modified.
Mitigation: Since the project is entirely software based, it is imperative that the source files are kept secure. In addition to limiting access to the machine to only Ongo8 and CSG, the department that maintains the server, the group members will regularly back up the source code and databases to an offsite location.
• Risk: Due to unforeseen circumstances, a group member leaves the project.
Mitigation: The overall team has seventeen members. These team members are divided between three sub teams, so in the event that a team member is lost, the remaining members will handle the increased workload. If the person leaving were a critical member, the team would work with him/her to ensure that his/her knowledge and responsibilities were adequately disseminated among the remaining group members. If more than one group member must leave the team, the team will decide whether a member from another project group could volunteer for double duty with or switch groups all together to maintain proper productivity levels. If the team member were to disappear all of a sudden with no warning the team would try and gain access to his/her log book to see what the team member has accomplished. Overall the team will try to maintain good documentation and communication so that in the event of loosing a team member it will not greatly affect the group.
• Risk: A bad update to the software makes it cease to function correctly.
Mitigation: CVS will be used to update and combine code for the entire Ongo8 team. Functions pertinent to this risk are the following:
Archive- allowing team members to rollback from the current project all the way to the first version since CVS began.
Version Numbers- allowing team members to give a tag to each version of the framework.
• Risk: The loss of contact with a client.
Mitigation: The team will work with the faculty to ensure that there are multiple school districts that are interested in using the project. Insuring that there is more than one school district will insure that the project still teachers and administrators to help test, and help the vision of the current application.
• Risk: The testing methods fail.
Mitigation: The group will need to determine the cause of the failure and redesign the testing structure accordingly. This might require team members to rewrite scripts to be more structurally sound instead of efficient.
2 Anticipated Risks Encountered
One anticipated risk was encountered this semester. A team member was lost due to a schedule change. As this team member was only in the first semester, they had not become an established team member yet, so no documentation was generated or gathered from this individual. The sub team from which this person was to work simply redistributed the work amongst those team members that remained.
3 Unanticipated Risks Encountered
No unanticipated risks were encountered during the semester.
4 Changes in Risk Management
As no significant unanticipated risks were encountered this semester, no changes have been made to the way the group manages risks. The anticipated risks mentioned above will still be applicable to future semesters.
3 Project Team Information
Client:
Ames Community Schools
Administrative Offices
1921 Ames High Drive
Ames, IA. 50010
Phone: 515-268-6600
Faculty Advisors:
Dr. John Lamont Prof. Ralph Patterson, III
324 Town Engineering 326 Town Engineering
Ames, IA. 50011-3230 Ames, IA. 50011-3230
Phone: 515-294-3600 Phone: 515-294-2428
Fax: 515-294-6760 Fax: 515-294-6760
jwlamont@iastate.edu repiii@iastate.edu
CprE/EE 492 Team Members:
Parikshit Advani Laurie Bidrawn
1202 Scott Ave. 1223 Frederiksen Ct
Ames, IA 50010 Ames, IA 50010
515-441-0945 515-572-7858
parik5@iastate.edu lbidrawn@iastate.edu
Computer Engineering Computer Engineering
Nicole Dugan Nathan Gordon
4009 Brickman Ave. 2219 Friley Pearson
Ames, IA 50010 Ames, IA 50012
515-480-4244 515-572-5487
nburgett@iastate.edu nlgordon@iastate.edu
Computer Engineering Computer Engineering
Sara Murphy Samantha Olson
1236 Frederiksen Ct. 1236 Frederiksen Ct.
Ames, IA 50010 Ames, IA 50010
515-572-7785 515-572-7785
murphys@iastate.edu solson@iastate.edu
Computer Engineering Computer Engineering
John Saterfiel Tiffany Schweer
7312 Frederiksen Ct. 2233 Fredericksen Ct.
Ames, IA 50010 Ames, IA 50010
515-572-7972 512-736-8393
yabblo7@iastate.edu teckid16@iastate.edu
Computer Engineering Computer Engineering
David Wire
4719 Mortensen Rd Apt 307
Ames, IA 50014
515-292-5361
dlwire@iastate.edu
Computer Engineering
CprE/EE 491 Team Members:
E. Ryan Adamson Jennifer Carlson
5514 Friley Niles-foster 6221 Fredericksen Ct
Ames, IA 50012 Ames, IA 50010
515-572-5127 515-572-7796
edot@iastate.edu cjen@iastate.edu
Computer Engineering Computer Engineering
Dustin Fee Michael Fong
2101 Oakwood Rd. #208 3021 Regency Court #83
Ames, IA 50013 Ames, IA 50010
515-292-2466 515-233-3579
dfee@iastate.edu mcfong@iastate.edu
Computer Engineering Computer Engineering
Aaron Hurd Chun-Pang Kuk
1232 Fredericksen Ct 620 S. 4Th St #309.
Ames, IA 50010 Ames, IA 50014
515-572-7687 515-771-8227
ahurd@iastate.edu domkuk@iastate.edu
Computer Engineering Computer Engineering
Maria-Cristina Olivas
1132 Sunset
Keley, IA 50134
515-451-6631
mcolivias@iastate.edu
Electrical Engineering
4 Summary
The K-12 Teaching Application Support and Software team will design and implement Internet-based teaching software applications. The project will include the development of a framework that all other applications will rely on for support in addition to a set of three teaching applications: Mathematical Teaching Software System (MTSS), Globey’s World, and Uncle Sam’s America. These applications will provide children in elementary school grades 3-6 the opportunity to exercise their computer skills while practicing and enforcing skills in related school subjects. MTSS will emphasize the teaching of core mathematical skills and strengthening mathematical problem-solving techniques. Globey’s World and Uncle Sam’s America will provide an interactive way to learn about both world and United States geography, respectively. The applications will have lessons that are available to students. These applications will also allow tracking of student progress and customization of lessons. Lessons will be variable based on both subject matter and difficulty.
Appendix A
This appendix contains the list of the problems that were identified by the fall 2005 Ongo8 team members. The problems are separated in sections for each application. The document will be used to check off those problems that have been fixed and who performed the corrections.
|MTSS | |
|Issue |Date Discovered |Discovered By |Date Corrected |Corrected By | |
|Home should be named Home Page on titles and buttons |10/21/2005 |JS | | | |
|Homepage says 'You have a JavaScript compatible browser' - does this need |10/21/2005 |SM | | | |
|to tell people they need a JavaScript enabled browser to run MTSS? | | | | | |
|Homepage: make k12spprt@iastate.edu a link |10/21/2005 |DW, SM | | | |
|home page gives k12spprt@iastate.edu as error report address, Support |10/21/2005 |DW, MF | | | |
|section gives mtss@iastate.edu, needs to be consistent | | | | | |
|Feedback should be implemented or removed |10/21/2005 |JS | | | |
|What is the difference between feedback and support? |10/21/2005 |JS, SM | | | |
|change feedback and support so both use same mechanism as feedback, |10/21/2005 |DW, MF | | | |
|however two options are given. | | | | | |
|new user and feedback pages need headings |10/21/2005 |SM | | | |
|About MTSS is outdated |10/21/2005 |DW, JS, SM, TS | | | |
|Help page is skimpy |10/21/2005 |JS | | | |
|Help is provided in each problem function, is there need for a specific |10/21/2005 |MF | | | |
|help page? | | | | | |
|Instructions for problem finding need more details about options |10/21/2005 |JS | | | |
|Problems need to have the question and answer areas sequential instead of |10/21/2005 |JS | | | |
|separated | | | | | |
|After you have answered a question and gone to the results page you do not|10/21/2005 |DW, JS | | | |
|get an overall score for all the questions, should be a total score for | | | | | |
|problem field | | | | | |
|should be a list of problems to solve for students, they should not be |10/21/2005 |DW, TS | | | |
|searching for problems to solve | | | | | |
|if extra white space is added after the solution, or between parts of the |10/21/2005 |MF | | | |
|solution to the problem, the answer is marked wrong. | | | | | |
|4/2 turns into mixed fraction 2 0/2 is wrong |10/21/2005 |MF | | | |
|No way for a student to chart his or her progress or check grades again. |10/21/2005 |JS, SM | | | |
|Grammar issues on all pages |10/21/2005 |DW, SM | | | |
|Grammar: Instructions for solving a problem |10/21/2005 |SM | | | |
|Grammar: create problem instructions |10/21/2005 |SM | | | |
|Grammar: edit an existing problem instructions |10/21/2005 |SM | | | |
|Grammar: a large number of problem texts |10/21/2005 |DW, SM | | | |
|Need a way to get back to main k-12 page |10/21/2005 |DW | | | |
|Clicking on a problems button on the main screen should be changed to |10/21/2005 |JS | | | |
|something telling you that you're in the problems area now. | | | | | |
|dropdown list for problems button |10/21/2005 |DW, SM | | | |
|cover more subjects in the creating problems list, currently only geometry|10/21/2005 |SM | | | |
|and fractions perhaps make user defined | | | | | |
|when searching for problems remove don't care and matching radio buttons, |10/21/2005 |DW, SM | | | |
|if the description is empty, don't care | | | | | |
|no way to return to page you were on after clicking feedback without going|10/21/2005 |DW | | | |
|'Back' or going somewhere else first | | | | | |
|logout from k-12 main page |10/21/2005 |TS | | | |
|Logging out needs to be fixed |10/21/2005 |DW, SM, MF | | | |
|Support” and “About MTSS” pages have dotted lines as the borders, while |10/19/2005 |JC | | | |
|the “Help” page uses a solid line. | | | | | |
|“Feedback” link returns error “Object not found!” |10/19/2005 |JC | | | |
|School Track Meet: Question 1: How many seconds does it take Derrick to |10/19/2005 |JC | | | |
|run the 50 yards dash? | | | | | |
|Perhaps have a “Back” button to return to the other selected problems |10/19/2005 |JC | | | |
|after getting a solution to a problem. | | | | | |
|Mixed Fraction: A mixed fraciton is one that consists of a whole number as|10/19/2005 |JC | | | |
|well as a fraction. For example, 1 1/2 is a mixed fraction and could mean | | | | | |
|you have a one candy bar and also a half of a candy bar left. You get a | | | | | |
|mixed fraction by converting an improper fraction. An example of an | | | | | |
|improper fraction is 5/3. To convert[,] divide… | | | | | |
|If mixed fractions are entered with spaces, such as 13 / 4 instead of |10/19/2005 |JC | | | |
|13/4, they are automatically marked as wrong. Not a bug, just something | | | | | |
|to think about. | | | | | |
|Socks and Shoes: “There are 52 people in a hall. 16 of them are wearing |10/19/2005 |JC | | | |
|[only] socks and 21 of them are wearing [only] shoes,[;] 3 people are | | | | | |
|wearing both [socks and shoes].” Answer implies that 16 wearing only | | | | | |
|socks and 21 wearing only shoes, but it isn’t clear in the problem. | | | | | |
|Root Beer: …The formula requires that three chemicals be mixed together, |10/19/2005 |JC | | | |
|[each of] which are stored in one-gallon jugs. There is a red chemical, a | | | | | |
|blue chemical[,] and a green chemical. To make one batch of the best root | | | | | |
|beer, the professor must mix one[-]third of a jug of the red chemical with| | | | | |
|two-thirds [of a] jug of blue and four[-]thirds green. He starts with | | | | | |
|three jugs of each chemical and makes two batches of root beer. | | | | | |
|Marbles: Meng has total [of] 39 of marbles. The ratio of blue marbles to |10/19/2005 |JC | | | |
|that of the total is 1:3. Question 1: How many blue marbles [does] he | | | | | |
|[have] has? | | | | | |
|Mrs. Crocker bakes some pies: Mrs. Crocker decided to bake some pies for |10/19/2005 |JC | | | |
|200 guests in [at] her party. So [S]he baked 9 apple pies, 10 blueberry | | | | | |
|pies and 7 pumpkin pies. Each pie is [was] equally cut into 8 pieces… | | | | | |
|For uniformity, capitalize “Bakes Some Pies” in title of previous. |10/19/2005 |JC | | | |
|Tables and Plates: The question asks how big of a table do you need to |10/20/2005 |DF | | | |
|hold so many plates and bowls judging from the surface area of all the | | | | | |
|plates and bowls combined. I understand what this question is trying to | | | | | |
|do, but I think even a 3rd-6th grader will see the obvious problem that | | | | | |
|the plates and bowls are round so we cannot just rely on surface area of | | | | | |
|plates/bowls alone to see how much room we need, but how much space they | | | | | |
|occupy and how each plate or bowl is arranged. Although kids this age | | | | | |
|understand this concept, adding this part into the problem makes it too | | | | | |
|difficult for this application. I just don’t like this question, it could| | | | | |
|be removed. | | | | | |
|Thirst for More: Question 4: (4) If Jake put 4 one inch [ice] cubes into |10/20/2005 |DF | | | |
|the blue glass [how much water can he pour into the glass]? | | | | | |
|Fire Trucks: (1) What is the volume of the blue truck [in cubic feet]? |10/20/2005 |DF | | | |
|Wallpaper: Cut out last sentence. Change to: [The walls in the room are |10/20/2005 |DF | | | |
|just as tall as the wallpaper rolls are wide.] | | | | | |
|Regular Pentagon, Equilateral Triangle, Square, Rectangle, Rhombus, Kite, |10/20/2005 |DF | | | |
|Regular Hexagon, Scalene Triangle : Answer the following questions that | | | | | |
|are related to [the] “regular pentagon” [below]. Or ……that are related to | | | | | |
|[a] regular pentagon. Each of those questions just need a connector word | | | | | |
|to sound right in my opinion. | | | | | |
|Truck Full of Fridges: Question 3: (3) Is there any space left over when |10/20/2005 |DF | | | |
|the truck has as many fridges in it as possible? ///is there any space | | | | | |
|left over?/// Take out last part of sentence as it is already stated at | | | | | |
|beginning of sentence. | | | | | |
|Carpet: The word “role” is used multiple times when it should actually be |10/20/2005 |DF | | | |
|changed to “roll”. | | | | | |
|Planting Grass: The first sentence states: Katie’s lawn is shown in the |10/20/2005 |DF | | | |
|picture above. There is no picture. | | | | | |
|Cylinder Fun: You know that the radius [(R) of the] cylinder [below] is 6 |10/20/2005 |DF | | | |
|and the length [(L)] of the cylinder is 2. | | | | | |
|Cylinder Area: You have a cylinder with a radius [(R) of 6] and a length |10/20/2005 |DF | | | |
|[(L)] of 3.5. The cylinder is closed on the ends. | | | | | |
|Cylinder Area, Question 1: (1) Calculate the [surface] area of the |10/20/2005 |DF | | | |
|[outside of the] cylinder [including the closed ends], given that PI is | | | | | |
|3.14 | | | | | |
|Triangle: (2) What is the [surface] area of the [outside of the] box? |10/20/2005 |DF | | | |
|Right Triangle: You have in front of you a right triangle with a base |10/20/2005 |DF | | | |
|[(b)] of 16 and a height [(h)] of 4. | | | | | |
|Basketball Volume: You have in front of you a basketball. The radius [(R)]|10/20/2005 |DF | | | |
|of the ball is 5. ///The diameter of the basketball hoop is 12./// Cut| | | | | |
|out last sentence as nowhere in the problem does this come into play. It | | | | | |
|is unnecessary. | | | | | |
|Consistency for problems and how fractions are either spelled out or using|10/23/2005 |SO/LB | | | |
|numbers. | | | | | |
|Spelling and grammatical errors in problems. |10/23/2005 |SO/LB | | | |
|Jessica's Birthday - do you mean the pan is too large? |10/23/2005 |SO/LB | | | |
|When returning the default of problems available, maybe have the |10/23/2005 |SO/LB | | | |
|categories that the problem fits into besides just description | | | | | |
|After doing a problem, there's no direction on where to go from there and |10/23/2005 |SO/LB | | | |
|I couldn't click the Solve or Problems buttons on navigation. | | | | | |
|Clickable links under MTSS Support with subject line filled into the |10/23/2005 |SO/LB | | | |
|email. | | | | | |
|Test problem was available to the guest user when all returned. Maybe want|10/23/2005 |SO/LB | | | |
|that this one is only there if debug? | | | | | |
|For those problems that were also introducing and just testing one skill, |10/23/2005 |SO/LB | | | |
|there was commonly a description of what the skill is. For the Least | | | | | |
|Common Denominator, there was no explanation. | | | | | |
|What does "Problems" mean? |10/23/2005 |Team D | | | |
|Solving problems doesn't make a lot of sense, even with instructions |10/23/2005 |Team D | | | |
|I'm assuming the calculator with the no over it means "no calculators", |10/23/2005 |Team D | | | |
|but maybe it should be explained | | | | | |
|Consistancy problems between screens |10/23/2005 |Team D | | | |
|USA |
|Issue |Date Discovered |Discovered By |Date Corrected |Corrected By |
|Homepage: link should not be entire sentence |10/21/2005 |SM | | |
|Graphs should start at zero and scale properly |10/21/2005 |SM | | |
|On games, when in answer is not correct, make it an entire sentence |10/21/2005 |SM | | |
|subtitle 'A Division of Iowa State University's K-12 Teaching Applications|10/21/2005 |DW | | |
|Support' should be consistent throughout all. Either there or not. | | | | |
|proper scale on alaska and hawaii would probably be a good idea |10/21/2005 |DW | | |
|from alaska history ...called "Seward\'s Folly". In… html error |10/21/2005 |DW | | |
|what does NA; mean in economy for Timer/Lumber of Alaska? |10/21/2005 |DW | | |
|State Info link brings up Iowa with no way to change the state viewed. |10/21/2005 |DW | | |
|Make graphs scale well and start at 0, or make it obvious they do not |10/21/2005 |DW | | |
|start at 0. | | | | |
|Name that state shows the abbreviation for the state in the bar at the |10/21/2005 |DW | | |
|bottom of the screen | | | | |
|Put proper punctuation in the correct and incorrect comments |10/21/2005 |DW | | |
|Some states occur much more often than others in name that state and state|10/21/2005 |DW | | |
|that flag | | | | |
|On the Name That State game, when it tells you to find a state and you |10/20/2005 |DF | | |
|click the wrong state, it just informs you that was an incorrect answer | | | | |
|and gives a new state to find. I think it would be more helpful to let | | | | |
|the student know they were incorrect and give them 2 more tries or | | | | |
|something like that before moving on. | | | | |
|As Dr. Lamont pointed out for the State That Flag game, Name That State |10/20/2005 |DF | | |
|has problems with the states being randomly selected. When I played it | | | | |
|was once again California that came up most of the time. | | | | |
|Along the lines of Lamont’s comment number (14), the flags shown are |10/20/2005 |DF | | |
|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?). | | | | |
|Perhaps the units used for total area, water area, birth rate, death rate,|10/20/2005 |DF | | |
|etc should be displayed on the chart when comparing states. | | | | |
|Is there really a need for small, medium, large chart sizes on the compare|10/20/2005 |DF | | |
|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 understand they really don’t need to be| | | | |
|there. | | | | |
|The introduction page should be changed to explain the part about |10/23/2005 |LB | | |
|contacting by email for support and questions rather than just "I want to | | | | |
|email someone about Uncle Sam's America" | | | | |
|State capitals on the US map are all there except for Alaska and Hawaii. |10/23/2005 |LB | | |
|US map also contains other cities, do we want these or just keep to |10/23/2005 |LB | | |
|capitals? | | | | |
|Instead of "Back to Uncle Sam's America" (which I didn't know where this |10/23/2005 |LB | | |
|was going to take me) put "Back to Country view/US map" | | | | |
|Flag icon space for District of Columbia is an "x." Should have a |10/23/2005 |LB | | |
|placeholder, or US flag. | | | | |
|Comparison pages: Add error/info messages about how many states left to |10/23/2005 |LB | | |
|select, how many are selected, or error when already have 10 or not | | | | |
|enough. | | | | |
|The selection problems for the states is randomly happening. Sometimes the|10/23/2005 |LB | | |
|wrong states are compared and sometimes they are the ones selected - | | | | |
|general look into this error. | | | | |
|Need a way to get back reasonably if a user uses the back button on the |10/23/2005 |LB | | |
|comparison pages. Errors out when used. | | | | |
|Name that State isn't colorful. Maybe add the ability to show what state |10/23/2005 |LB | | |
|it was? Some text wraps on the top, and sometimes not. Put more space for | | | | |
|text above the map. | | | | |
|More space needed for flag game text above map as well. |10/23/2005 |LB | | |
|State info on the side is only for Iowa, was there a reason? |10/23/2005 |Team D | | |
|Data to compare drop down has underscores in it |10/23/2005 |Team D | | |
|Compare can only select one at a time, Globey's allows you to do multiple |10/23/2005 |Team D | | |
|In the Name that state game, it might not take too long for kids to learn |10/23/2005 |Team D | | |
|that they just have to match the URL for last and next. The name changes | | | | |
|as the game is played. | | | | |
|Same with the other game with the flags |10/23/2005 |Team D | | |
|Globey's World |
|Issue |Date Discovered |Discovered By |Date Corrected |Corrected By |
|more information link requires re-authentication |10/21/2005 |DW, JS, MF | | |
|Check grammar on website in general |10/21/2005 |DW | | |
|help pop-up window |10/21/2005 |DW | | |
|when zoomed in on a region countries outside the region are still shown, |10/21/2005 |JS | | |
|could be confusing | | | | |
|cannot select greenland from anywhere |10/21/2005 |DW | | |
|national anthems will not play under Mozilla, works with IE, browser |10/21/2005 |JS | | |
|compatibility | | | | |
|some national anthems do not exist, better to put N/A than the media bar |10/21/2005 |DW, MF | | |
|no definitions given in help page about comparison feature |10/21/2005 |JS | | |
|Antartica page has no map or flag, just dead links and incorrect |10/21/2005 |JS | | |
|information | | | | |
|Update out of date information (Iraq) |10/21/2005 |JS | | |
|Several pages give database errors retrieving data |10/21/2005 |DW, JS, MF | | |
|Typo on russian GDP, should be 1.2 trillion not million |10/21/2005 |JS | | |
|Antartica is not a grouped region |10/21/2005 |DW, JS | | |
|when many countries are compared and chart size is selected as small the |10/21/2005 |MF | | |
|country names are messed up | | | | |
|chart scale is poorly implemented |10/21/2005 |MF | | |
|Globey’s World Help – World page is the only help page without bullets. |10/19/2005 |JC | | |
|On the Globey’s World Help – World page, it is hard to see the country |10/19/2005 |JC | | |
|that is lit up. Perhaps a bigger image or more zoomed-in image would be | | | | |
|better. Or even better, we could adjust the contrast on the image. | | | | |
|When I click “I would like to know more information about Globey’s World” |10/19/2005 |JC | | |
|on the opening GW page, it just gives me a log-in window, and the normal | | | | |
|log-in doesn’t work. | | | | |
|Team member names need to be updated on Senior Design website. |10/19/2005 |JC | | |
|There is a lot of white space on the World page above and below the map of|10/19/2005 |JC | | |
|the world. | | | | |
|When on the country page and selecting the “Region” link, it always takes |10/19/2005 |JC | | |
|you back to North America. Would it make more sense to go to the region | | | | |
|where the country belongs? | | | | |
|I don’t know if it’s clear within the “Region” page that they need to push|10/19/2005 |JC | | |
|the button for “Select New Country” once they have selected from the | | | | |
|drop-down menu. I don’t know if it would be better to say “Go to New | | | | |
|Country” or something else instead. Really, this one isn’t that big of a | | | | |
|deal probably. | | | | |
|Perhaps there should be links at the bottom of country fact sheets that |10/19/2005 |JC | | |
|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 |10/19/2005 |JC | | |
|“Number of Regions,” it says: England - 47 boroughs, 36 counties*, 29 | | | | |
|London boroughs**, … | | | | |
|Also in this example, as well as for the “Date Founded,” the entries cut |10/19/2005 |JC | | |
|off mid-word at the end of the data in the section. | | | | |
|In Country View, selecting “Globe” from the list gave error under “Bodies |10/19/2005 |JC | | |
|of Water”: Warning: mysql_fetch_array(): supplied argument is not a valid | | | | |
|MySQL result resource in /var/www/html/ongo8/globey/demo/cp.php on line | | | | |
|194 | | | | |
|Similarly for “Languages” on this page. |10/19/2005 |JC | | |
|Also on “Bodies of Water” and “Languages” for Western Sahara, West Bank, …|10/19/2005 |JC | | |
|Number of Regions under “Ukraine” is incomplete |10/19/2005 |JC | | |
|The United Kingdom page lists languages as “Arabic, French, Sangho.” Hmm…|10/19/2005 |JC | | |
|When I first selected “Compare,” it put the countries on the chart in the |10/19/2005 |JC | | |
|order of selection. When I changed the chart size, it puts them in | | | | |
|alphabetical order. | | | | |
|If I close the program, it brings me back to the start page without having|10/19/2005 |JC | | |
|to re-login. | | | | |
|Home link on the home page not needed |10/23/2005 |SO | | |
|Place the world view closer to the top of the page |10/23/2005 |SO | | |
|Some countries information not shown on comparison page. This happens |10/23/2005 |SO | | |
|because the number is too small to be shown graphically. Maybe place the | | | | |
|actual number above the graph too | | | | |
|Change “pick up to 10” on comparison page |10/23/2005 |SO | | |
|No way to tell where you are in the program |10/23/2005 |Team D | | |
|Graphics don't work on side on comparison page |10/23/2005 |Team D | | |
|In comparison, what does the y axis on the chart stand for |10/23/2005 |Team D | | |
Appendix B
This appendix contains the current version of the K-12 Teaching Application Support user manual intended for teachers and administrators when considering the application suite in their .
K-12 TEACHING APPLICATION SUPPORT
Introduction
Thank you for considering the evaluation of the K-12 Teaching Application Software, which was developed by an ongoing senior design team in the Department of Electrical and Computer Engineering at Iowa State University with guidance from the Department of Curriculum and Instruction at Iowa State University. The current software is a collection of online (Internet-based) tools that can be used to both educate and quiz 3rd-6th grade students. All of the applications are tied to a single login page located at . The logins and associated passwords for your school district are listed in the cover email.
The current version of the software lacks automatic quiz grading. Future enhancements will include finishing the online quizzes, creating a detailed online grading book for monitoring and recording progress, developing a problem solving evaluation capability, and providing various “making learning fun” activities such as learning via fun, educational games.
Overview
1 MTSS
This program is a mathematical application that can be used to aid students in developing their problem-solving skills. It can also assist teachers in evaluating the problem solving skills of their students. Based upon the login used, different classes of users will have different capabilities. The three classes of users are: (1) students, (2) teachers, and (3) administrators. Students will be able to select, view and solve math problems as well as quizzes. Teachers will be able to create, edit, delete math problems and quizzes, and review student progress. In addition to having the same as teachers, administrators will have the additional ability to add new users to the application. In the future, additional administrative functions will be added. For each class of user, the program has a different, but similar, navigation bar on the left side of the screen.
2 Globey’s World
Globey’s World is the world geography application of the project. The intent of Globey’s World is to assist in the instruction of world geography in a visually interactive, appealing, and fun manner for the students. In the future, it will also include some practical applications of mathematics as a component.
Globey’s World was designed with three ‘layers’ of visualization: (1) the world view, (2) the region view, and (3) the country view. Each view is a different Internet page. The world view, presents the earth in the complete “flat” view normally seen in a text book. On the world page, the user can select a region (typically a continent), which then will be displayed on the screen. On a region page, the user can select a country, whose page then will be displayed. On each country page, a map of the country, its flag, and a large amount of data about that country will be displayed.
3 Uncle Sam’s America (USA)
Uncle Sam's America is quite similar to Globey’s World, but it is based on United States geography. The operation is similar with one exception. There is no region page. Selecting a state on the US map takes the user directly to the state’s page. The database includes geographical information, such as population, land area, state flag, state song (“click” on the state flag), natural resources, and manufactured products for each state. This information is available by selecting the "State Info" icon on the left side of the screen.
Comparisons of a specific attribute among two to ten states can be made in a process similar to that used in Globey’s world. Currently, two mini-games are also available to challenge a student's knowledge of American geography; they are available under the "Games" menu. Additional games are planned.
Instructions
1 Logging in to the System
Browse to the URL, . You will get a login prompt that looks as shown in Figure 1.
Enter the username and password provided for you.
[pic]
Figure 1
Select from one of the three applications. The screen to select the applications is shown in Figure 2.
[pic]
Figure 2
Mathematical Teaching Software System (MTSS)
Administrator Instructions:
Login with the administrator user name and password.
Click the “Mathematical Teaching Software System” link
[pic]
To create a problem:
Click the “PROBLEMS” link on left hand side of page.
Click the “Create” link under “PROBLEMS.”
For detailed help, click the “Show Instructions” button.
[pic]
Specify the Problem Features
i. Enter the problem description, a brief description of the problem.
ii. Select problem grade level(s). This is the grade level(s) of students who will be shown this problem.
iii. Select the problem topic from the dropdown list.
iv. The concept dropdown list will now be available. Select the concept this problem emphasizes from the dropdown list.
v. Select the problem difficulty level from the dropdown list
vi. Select whether or not the students are expected to use calculators on this problem.
Specify the Problem Statement
i. Enter the word description of the problem. The word description should contain all elements necessary to solve the questions in this problem.
Questions and answers
i. Select the number of questions to ask.
ii. For each question do the following:
1. Type the word question.
2. Select the type of question.
3. Each type of question will be presented with different fields for answers.
[pic]
Images
i. Choose whether or not to include an image.
ii. If yes is chosen, you can browse your local computer to find the image.
Click the “Generate Preview” button.
A new window appears containing a preview of the problem created.
i. If this problem is OK
1. Click “Submit New Problem.”
2. A page will be displayed showing that the problem has been successfully submitted.
3. Click “Close this window.”
ii. If you wish to change the problem before submitting, click “Close Window.”
To Edit a Problem:
a. Click the “PROBLEMS” button on the left hand side of page.
b. Click the “Edit” button under “PROBLEMS.”
[pic]
c. For detailed help, click the “Show Instructions” button.
d. Search for problems
i. Description
Select “Do Not Care” if you do not want to search with the problem description as a criterion.
Select “Matching” if you want to search for a specific problem description.
a. Type the desired description in the Description field.
ii. Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
iii. Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
iv. Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
v. Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
vi. Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
i. If the search was successful, a list of satisfying problems will be returned
ii. If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Select problem to edit by clicking on one of the returned problems.
g. Specify the Problem Features
i. Enter the problem description, a brief description of the problem.
ii. Select problem grade level(s). This is the grade level(s) of students who will be shown this problem.
iii. Select the problem topic from the dropdown list.
iv. The concept dropdown list will now be available. Select the concept this problem emphasizes from the dropdown list.
v. Select the problem difficulty level from the dropdown list
vi. Select whether or not the students are expected to use calculators on this problem.
h. Specify the Problem Statement
i. Enter the word description of the problem. The word description should contain all elements necessary to solve the questions in this problem.
i. Questions and answers
i. Select the number of questions to ask.
ii. For each question do the following:
1. Type the word question.
2. Select the type of question.
3. Each type of question will be presented with different fields for answers.
[pic]
j. Images
i. Choose whether or not to include an image.
ii. If yes is chosen, you can browse your local computer to find the image.
k. Click the “Generate Preview” button.
l. A new window appears containing a preview of the problem created.
If this problem is OK
Click “Submit New Problem.”
A page will be displayed showing that the problem has been successfully submitted.
Click “Close this window.”
If you wish to change the problem before submitting, click “Close Window.”
Delete a Problem
a. Click the “PROBLEMS” button on the left hand side of the page.
b. Click the “Delete” button under “PROBLEMS.”
[pic]
c. For detailed help, click the “Show Instructions” button.
d. Search for problems
i. Description
1. Select “Do Not Care” if you do not want to search with the problem description as a criterion.
2. Select “Matching” if you want to search for a specific problem description.
b. Type the desired description in the Description field.
ii. Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
iii. Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
iv. Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
v. Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
vi. Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
If the search was successful, a list of satisfying problems will be returned
If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Check the problems to delete.
g. To deselect all problems, click “Uncheck All.”
h. To delete all selected problems, click “Delete.”
Solve Problems
a. Click the “PROBLEMS” button on the left hand side of page.
b. Click the “Solve” button under “PROBLEMS.”
[pic]
c. For detailed help click Show Instructions button
d. Search for problems
Description
1. Select “Do Not Care” if you do not want to search with the problem description as a criterion.
2. Select “Matching” if you want to search for a specific problem description.
c. Type the desired description in the Description field.
Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
i. If the search was successful, a list of satisfying problems will be returned
ii. If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Select the problem to solve by clicking on one of the returned problems.
g. Enter the answers to the questions and click “Submit for Grading.”
h. Click “OK” in the pop-up if you are sure you wish to submit, otherwise click “cancel.”
i. Your answers will be listed on the next page along with an explanation of the symbols used.
To create a new user
Click NEW USER from the panel on the left.
[pic]
Enter the user’s First Name in the text box.
Enter the user’s Last Name in the text box.
Enter any notes regarding the user in the Note text box.
The administrator’s ID should appear in the Owner text box.
From the Permissions drop down box select what type of user is being created. Types of users:
Developer
Administrator
Coordinator
Teacher
Student
Parent
Guest
Enter the user’s Username in the text box.
Enter the user’s Password in the text box.
Enter a Password Hint for the user in the text box.
Enter the preferred activation date in the Activation Date text boxes.
Enter the preferred expiration date in the Expire Date text boxes.
If the user is a student enter the their identification number in the Student ID text box.
Enter the user’s email in the Email text box.
Once all the information is filled in and is correct hit the Register button at the bottom of the page.
If the information is not correct and needs to be filled out again hit the Reset button at the bottom of the page to clear the form.
1. Additional Help
a. Click the “SUPPORT” button on the left menu to e-mail any questions or concerns to the developers
Teacher Instructions:
1. Login with the teacher user name and password.
2. Click the “Mathematical Teaching Software System” link
[pic]
3. To create a problem:
a. Click the “PROBLEMS” link on left hand side of page.
b. Click the “Create” link under “PROBLEMS.”
c. For detailed help, click the “Show Instructions” button.
[pic]
d. Specify the Problem Features
i. Enter the problem description, a brief description of the problem.
ii. Select problem grade level(s). This is the grade level(s) of students who will be shown this problem.
iii. Select the problem topic from the dropdown list.
iv. The concept dropdown list will now be available. Select the concept this problem emphasizes from the dropdown list.
v. Select the problem difficulty level from the dropdown list
vi. Select whether or not the students are expected to use calculators on this problem.
e. Specify the Problem Statement
i. Enter the word description of the problem. The word description should contain all elements necessary to solve the questions in this problem.
f. Questions and answers
i. Select the number of questions to ask.
ii. For each question do the following:
1. Type the word question.
2. Select the type of question.
3. Each type of question will be presented with different fields for answers.
[pic]
Creating a Problem (picture 2)
g. Images
i. Choose whether or not to include an image.
ii. If yes is chosen, you can browse your local computer to find the image.
h. Click the “Generate Preview” button.
i. A new window appears containing a preview of the problem created.
i. If this problem is OK
1. Click “Submit New Problem.”
2. A page will be displayed showing that the problem has been successfully submitted.
3. Click “Close this window.”
ii. If you wish to change the problem before submitting, click “Close Window.”
4. To Edit a Problem:
a. Click the “PROBLEMS” button on the left hand side of page.
b. Click the “Edit” button under “PROBLEMS.”
[pic]
Editing a Problem
c. For detailed help, click the “Show Instructions” button.
d. Search for problems
i. Description
1. Select “Do Not Care” if you do not want to search with the problem description as a criterion.
2. Select “Matching” if you want to search for a specific problem description.
d. Type the desired description in the Description field.
ii. Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
iii. Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
iv. Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
v. Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
vi. Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
i. If the search was successful, a list of satisfying problems will be returned
ii. If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Select problem to edit by clicking on one of the returned problems.
g. Specify the Problem Features
i. Enter the problem description, a brief description of the problem.
ii. Select problem grade level(s). This is the grade level(s) of students who will be shown this problem.
iii. Select the problem topic from the dropdown list.
iv. The concept dropdown list will now be available. Select the concept this problem emphasizes from the dropdown list.
v. Select the problem difficulty level from the dropdown list
vi. Select whether or not the students are expected to use calculators on this problem.
h. Specify the Problem Statement
i. Enter the word description of the problem. The word description should contain all elements necessary to solve the questions in this problem.
i. Questions and answers
i. Select the number of questions to ask.
ii. For each question do the following:
1. Type the word question.
2. Select the type of question.
3. Each type of question will be presented with different fields for answers.
[pic]
j. Images
i. Choose whether or not to include an image.
ii. If yes is chosen, you can browse your local computer to find the image.
k. Click the “Generate Preview” button.
l. A new window appears containing a preview of the problem created.
i. If this problem is OK
1. Click “Submit New Problem.”
2. A page will be displayed showing that the problem has been successfully submitted.
3. Click “Close this window.”
ii. If you wish to change the problem before submitting, click “Close Window.”
5. Delete a Problem
a. Click the “PROBLEMS” button on the left hand side of the page.
b. Click the “Delete” button under “PROBLEMS.”
[pic]
c. For detailed help, click the “Show Instructions” button.
d. Search for problems
i. Description
1. Select “Do Not Care” if you do not want to search with the problem description as a criterion.
2. Select “Matching” if you want to search for a specific problem description.
a. Type the desired description in the Description field.
ii. Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
iii. Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
iv. Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
v. Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
vi. Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
i. If the search was successful, a list of satisfying problems will be returned
ii. If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Check the problems to delete.
g. To deselect all problems, click “Uncheck All.”
h. To delete all selected problems, click “Delete.”
6. Solve Problems
a. Click the “PROBLEMS” button on the left hand side of page.
b. Click the “Solve” button under “PROBLEMS.”
[pic]
Solving a Problem
c. For detailed help click Show Instructions button
d. Search for problems
i. Description
1. Select “Do Not Care” if you do not want to search with the problem description as a criterion.
2. Select “Matching” if you want to search for a specific problem description.
a. Type the desired description in the Description field.
ii. Topic
1. Select the topic of the problems you wish to search for or [All] to search for all problem topics.
iii. Concept
1. If you selected something other than [All] for the Topic, you are able to select the concept which the problem practices and search for this value.
iv. Difficulty Level
1. Select the difficulty level of the problem from the drop down list, or [All] for all difficulty levels.
v. Allow Calculator
1. Select Yes, No, or [All] to specify whether the use of a calculator is allowed.
vi. Grades
1. Select the grades of problems you are searching for as well as “OR” or “AND.” “OR” will return problems satisfying any ONE of the grades selected while “AND” will return problems satisfying only ALL of the grades selected.
e. Click “Search”
i. If the search was successful, a list of satisfying problems will be returned
ii. If the search was unsuccessful, “NO MATCHES TO YOUR QUERY” is returned. Return to the Edit page and try again.
f. Select the problem to solve by clicking on one of the returned problems.
g. Enter the answers to the questions and click “Submit for Grading.”
h. Click “OK” in the pop-up if you are sure you wish to submit, otherwise click “cancel.”
i. Your answers will be listed on the next page along with an explanation of the symbols used.
2. Additional Help
b. Click the “SUPPORT” button on the left menu to e-mail any questions or concerns to the developers
Student Instructions:
3. Login with the student username and password.
4. Click the “Mathematical Teaching Software System” link on the main page. (See image below, left.)
5. Getting to the Problem(s):
a. Click the “PROBLEMS” button in the menu on the left side of the screen (See image below, right.)
b. Click the “Solve” button that appears under PROBLEMS
c. Enter the search criteria in the search box to find the problem(s) you want
[pic] [pic]
6. Searching for a Problem(s)
a. Using the search box, find a desired problem:
|Description |Contains the name of the problem desired. |
|Topic |Specific topic under which to search. |
|Concept |Specific concept area within the topic. |
|Difficulty Level |The difficulty level of the problem desired: easy, medium or hard |
|Allow Calculator |Search for problems were a calculator is allowed or not allowed |
|Grades |for what grade level(s) do you want the problems? There can be problems that are multiple grade |
| |levels so you would select the AND button for those else for a general query you would select the OR|
| |button |
b. Select the desired problem from the list that appears from your query
7. Working a Problem
a. Problems which allow calculators will have a picture of a calculator. Problems do not allow calculators will have a picture of a calculator crossed out
b. Read the story problem presented. (See example, below.)
[pic]
c. The questions to be answered appear below the problem. Answer choices appear below each question.
d. Some questions require answers to be submitted on paper to the teacher.
e. Once all of the questions in a problem have been answered, click the “Submit for Grading” button at the bottom of the problem.
f. A page will be displayed with the results of the problem, giving the answers for each question and displaying points awarded. (See screenshot, next page.)
[pic]
g. To do another problem go back to the home page for MTSS by clicking the button on the left menu called HOME then follow Part 3: Getting the Problem(s)
8. Additional Help
c. Click the “SUPPORT” button on the left menu to e-mail any questions or concerns to the developers
Globey’s World (GW)
Globey’s World is the world geography application of the project. The intent of Globey’s World is to assist in the instruction of world geography in a visually interactive, appealing, and fun manner for the students. In the future, it may also include some practical applications of mathematics and games as components.
Background
Globey’s World was designed with three ‘layers’ of visualization: (1) the world view (see fig. GW1), (2) the region view (see fig. GW2), and (3) the country view (see fig. GW3). Each view is a different Internet page. The world view, presents the earth in the complete “flat” view as normally seen in a text book. On the world page, the user can select a region (typically a continent), which then will be displayed on the screen. On a region page, the user can select a country from that region, whose page then will be displayed. On each country page, a map of the country, its flag, and a large amount of data about that country will be displayed. This data includes sections on facts and figures, economy, geography, and political information.
Fig. GW1
[pic]
Fig. GW2
[pic]
Fig. GW3
[pic]
Fig.GW4
[pic]
How to use
Navigation
When a user enters Globey’s World, several helpful icons (links) are displayed on the left edge of the screen to assist the user (see fig. GW4). These icons are the primary means of navigation. The function of these icons is as follows:
1. Home (house icon): returns the user to the application’s home page.
2. World page (globe icon): provides a direct link to the world page.
3. Region page (arrowed globe icon): provides a direct link to the region page.
4. Country page (U.S. icon): provides a direct link to the country page.
5. Comparison page (scales icon): the graphic with the two flags (Brazil and Australia) – provides a direct link to the comparison page.
6. Help (question mark icon): opens a new window containing the help section.
7. Suite home page (arrow icon): will return the user to the suite’s home page where the user can navigate to other applications.
Once you are in the region or country page other regions or countries may be selected by using the pull-down menu on the appropriate page.
Comparing Country Attributes
The comparison page (see Fig. GW5) allows the user to compare a specific attribute (population, land area, etc) in the database for two to ten countries in a graphical bar chart form. After the quantity to be compared is selected using the pull-down menu on the left, the user selects a list of countries whose data will be compared. The countries are selected by moving them into the right section by using the right arrow ‘-->’. Only countries in the right section will be compared when the ‘Compare’ button is pressed.
Fig. GW5
[pic]
Uncle Sam’s America (USA)
Uncle Sam's America is quite similar to Globey’s World, but it is based on United States geography. Users of USA are able to view maps, flags, and various facts about each of the fifty states. By clicking on any state in the United States map, the user will be directed to an individual state view in much the same manner that clicking on a country does in Globey’s World. USA also offers interactive features in the form of games about the states and comparison capabilities.
Background
Uncle Sam’s America was designed with two ‘layers’ of visualization: (1) the United States view (see fig. USA1) and (2) the state view (see fig USA2). The United State map view is used as a navigation panel of the entire United States and is the basis for moving between state views. The state view provides further details about a particular state including a map of the state, the state flag, and a table of information pertaining to the state such as the state bird, population, and land area.
[pic]
Fig USA1. The United States map view.
[pic]
Fig USA2. The state detailed view.
How to Use
Navigation
The basic navigation panel of Uncle Sam’s America includes icons on the left hand side (see fig. USA3). The functions of these icons are the following:
[pic]
Fig USA3. The main home page to the application.
1. Home (house icon): the user to this application’s home page.
2. Country (US icon): takes the user to the US map page.
3. State Info (Iowa icon): takes the user the state page with Iowa as the default.
4. Compare (Scales icon): takes the user to the comparison setup page.
5. Games (Chess game icon): takes the user to the game selection page.
6. Return (Arrow icon): takes the user to the suite’s home page from which a different application may be selected.
The navigation bar on the left is available at any page in the application.
Accessing a State View
Finding information about a state requires the user to be on the United States map view. This view is available once the application is started or by clicking the Country option on the navigation panel. The United States map that is displayed is interactive and has links for each of the states pictured. Simply clicking in the general area of a state will bring forth a state view, as reference in fig. USA1.
Accessing the Comparison View
Comparisons of up to ten states can be done while on the comparison view. The drop down menus provided on this page offer users the ability to personalize the comparison they would like to do. Steps to perform a comparison are listed below and seen in fig. USA4.
[pic]
Fig USA4. Making a comparison between Alabama and Alaska and adding California.
1. Data to compare: the ability to select data information that can be compared amongst states.
2. Chart size: the ability to change the size of the resulting chart in small, medium, and large sizes.
3. State list: the ability to select up to ten states at a time.
a. States can be selected one at a time by clicking each individual state and then clicking the arrow button pointing to the right.
b. States can be selected in multiples by holding down the Ctrl key while clicking various state names and then clicking the right pointing arrow button.
4. States to compare: the ability to see those states that have been selected for comparison.
a. States can be selected for removal one at a time by clicking each individually and then clicking the arrow button pointing to the left.
b. States can be selected for removal in multiples by holding down the Ctrl key while making selections and then clicking the arrow button pointing to the left.
5. Compare button: starts the process to compare the selected data for the selected states and takes the user to another page displaying the chart.
Accessing the Game View
Uncle Sam’s America offers users two interactive games to test knowledge of US geography. These games can be accessed by the game navigation option. The user will be presented by a view seen in fig. USA5.
[pic]
Fig USA5. The game view.
1. Play Name that State: where questions are presented in the upper left corner asking for the user to click the corresponding state.
2. Play State that Flag: where a state flag is shown in the upper left corner asking for the user to click to corresponding state.
Troubleshooting
If you encounter a problem exiting the help function, it is likely that the help function opened a new window in front of the original application window. Check the bottom of the browser screen and, if this is the case, close the help window.
We would welcome your teachers and students using this software and providing us with feedback including any problems encountered and suggestions for future enhancements. feedback can be submitted via email to k12spprt@iastate.edu. Suggestions for additional applications would also be welcome. Once again, thank you for trying and evaluating this software. The involved students and faculty hope that your school district will find it useful.
Appendix C
Appendix C includes information on how to use WinSCP3 to remotely access the framework files and is written in the form of step-by-step instructions.
Using WinSCP3
1) Go to and download the latest version of the WinSCP3 software application.
2) Upon installation, open the application, click on new, and type in the following information:
Hostname: ongo8.ece.iastate.edu
Username: framework
Password: ********
Protocol: SFTP (Allow SCP fallback)
See figure 8 below for an application screen example.
[pic]
Figure 8: WinSCP3 Session Screen Example
3) Click on Stored sessions after the above information has been entered. This action will save the session so the information does not need to be reentered login.
4) Once authenticated, open the repository folder, then Venus, or whatever the current release of the framework is.
Appendix D
Appendix D is the grading framework documentation delivered to the other Ongo08 sub teams. It contains an overview of the grading functionality, installation instructions, and descriptions of globals, functions, libraries, and references. It is assembled in such a way as to provide an easily updated and maintained format for future teams.
This document was originally delivered at the end of the fall 2004 semester, and has been modified since.
Software Application Support Framework
Grading Database Requirements Document
Ongo8d
[pic]
Client:
Ongo08 Sub Teams
Faculty Advisors:
Dr. John Lamont
Professor Ralph Patterson
CprE/EE 492 Team Members:
Mark Klein, CprE
Jason Wilkinson, CprE/ComS
CprE/EE 491 Team Members:
Nate Gordon, CprE
Nichole Burgett, CprE/ComS
Parikshit Advani, CprE
1 April 200
Introduction
The purpose of the document is to give a general understanding of the implementation and methods used by the framework team (Ongo 08d) in their PHP library code. All questions should be directed to the framework team, and all assumptions made by non-framework teams (Ongo 08a, Ongo 08b, and Ongo 08c) should be checked with by Ongo 08d team representatives before implementation of said assumptions.
This document will be updated each term when new functionality is added to the framework. After agreeing upon the contents of this document, the framework will then begin creating code to meet these objectives. Once the code is ready for implementation, the contents of this document will become part of the framework cookbook. The cookbook should be used by the other teams as a guide to implementing the framework.
Problem Statement
This section contains the general problem and the solution decided upon, by the framework team.
General Problem Statement
The Ongoing 08 team consists of a series of applications and a framework. The framework is to be a library of calls, functions, and tables the applications can call to do basic routines shared by all of the applications. Since most of the applications were built by different sub-teams and different developers, each application is a little different. It is the framework’s responsibility to make the applications uniform in how they access the database, call specified routines, and respond to errors.
General Solution-Approach Statement
The Ongoing 08 team needs a list of set functions and tables to construct their applications around. In order to facilitate their needs, the framework team (Ongo 08d) has met and gathered information from each team including, but not limited to: application design, external file usage, method handling, and question types. From the meetings, a list of functions and SQL tables has been compiled. Contained within this document are the tables and functions to be considered for review by the application sub-teams.
The Ongoing 08 sub-teams (MTSS, Uncle Sam’s America, and Globey’s World) can now utilize this document by looking at the functions, tables, and definitions under proposal. Each function and table entry definition should help a team member to understand both why and how to use it.
Function Definitions
The following are a list of tentative desired functions for the framework. Included within each function is a listing of the prototype, description, and what the call will return. No distinction over whether to use objects or arrays has been made yet.
School Functions
The functions below are associated with the School table and will allow the programs to retrieve school information based upon certain search criteria or by a known SchoolID. They will also allow the addition of new schools as well as modifying and deleting existing schools.
getSchoolsByCriteria
Call: array getSchoolsByCriteria(object SchoolInfo)
Description: The getSchoolsByCriteria function can be called as the above notation describes. Additionally, the getSchoolsByCriteria function will allow for fields to be omitted, if the call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of School objects.
getSchool
Call: object getSchool(int SchoolID)
Description: The getSchool function can be called as the above notation describes. Unlike, the getSchoolsByCriteria function. The SchoolID must be passed in order to find a matching table entry.
Return: A row from School table as an object.
addSchool
Call: int addSchool(object SchoolInfo)
Description: The addSchool function can be called as the above notation describes. The addSchool function will add a school to the SQL table when invoked. During the call the object of SchoolInfo is required.
Return: The SchoolID of the school just created, or NULL if unsuccessful.
updateSchool
Call: boolean updateSchool(object SchoolInfo)
Description: By passing the SchoolID and the SchoolInfo, you can call the updateSchool function. The updateSchool function will find the proper school by use of the SchoolID and add the new information contained in the object SchoolInfo that was passed.
Return: Boolean value.
deleteSchool
Call: boolean deleteSchool(int SchoolID)
Description: When passed the SchoolID, the deleteSchool will search through the table and erase the row corresponding to that SchoolID. Once the school has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted school information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
Administrator Functions
The functions below are associated with the Administrator table and will allow the programs to retrieve administrator information based upon certain search criteria or by a known AdministratorID. They will also allow the addition of new administrators as well as modifying and deleting existing administrators.
getAdministratorsByCriteria
Call: array getAdministratorsByCriteria(object AdministratorInfo)
Description: The getAdministratorsByCriteria function can be called as the above notation describes. Additionally, the getAdministratorsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Administrator objects.
getAdministrator
Call: object getAdministrator(int AdministratorID)
Description: The getAdministrator function can be called as the above notation describes. Unlike, the getAdministratorsByCriteria function. The AdministratorID must be passed in order to find a matching table entry.
Return: A row from Administrator table as an object.
addAdministrator
Call: int addAdministrator(object AdministratorInfo)
Description: The addAdministrator function can be called as the above notation describes. The addAdministrator function will add a administrator to the SQL table when invoked. During the call the object of AdministratorInfo is required.
Return: The AdministratorID of the administrator just created, or NULL if unsuccessful.
updateAdministrator
Call: boolean updateAdministrator(object AdministratorInfo)
Description: By passing the AdministratorID and the AdministratorInfo, you can call the updateAdministrator function. The updateAdministrator function will find the proper administrator by use of the AdministratorID and add the new information contained in the object AdministratorInfo that was passed.
Return: Boolean value.
deleteAdministrator
Call: boolean deleteAdministrator(int AdministratorID)
Description: When passed the AdministratorID, the deleteAdministrator will search through the table and erase the row corresponding to that AdministratorID. Once the administrator has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted administrator information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
Coordinator Functions
The functions below are associated with the Coordinator table and will allow the programs to retrieve course coordinator information based upon certain search criteria or by a known CoordinatorID. They will also allow the addition of new course coordinators as well as modifying and deleting existing course coordinators.
getCoordinatorsByCriteria
Call: array getCoordinatorsByCriteria(object CoordinatorInfo)
Description: The getCoordinatorsByCriteria function can be called as the above notation describes. Additionally, the getCoordinatorsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Coordinator objects.
getCoordinator
Call: object getCoordinator(int CoordinatorID)
Description: The getCoordinator function can be called as the above notation describes. Unlike, the getCoordinatorsByCriteria function. The CoordinatorID must be passed in order to find a matching table entry.
Return: A row from Coordinator table as an object.
addCoordinator
Call: int addCoordinator(object CoordinatorInfo)
Description: The addCoordinator function can be called as the above notation describes. The addCoordinator function will add a coordinator to the SQL table when invoked. During the call the object of CoordinatorInfo is required.
Return: The CoordinatorID of the coordinator just created, or NULL if unsuccessful.
updateCoordinator
Call: boolean updateCoordinator(object CoordinatorInfo)
Description: By passing the CoordinatorID and the CoordinatorInfo, you can call the updateCoordinator function. The updateCoordinator function will find the proper coordinator by use of the CoordinatorID and add the new information contained in the object CoordinatorInfo that was passed.
Return: Boolean value.
deleteCoordinator
Call: boolean deleteCoordinator(int CoordinatorID)
Description: When passed the CoordinatorID, the deleteCoordinator will search through the table and erase the row corresponding to that CoordinatorID. Once the coordinator has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted coordinator information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
Teacher Functions
The functions below are associated with the Teacher table and will allow the programs to retrieve teacher information based upon certain search criteria or by a known TeacherID. They will also allow the addition of new teachers as well as modifying and deleting existing teachers.
getTeachersByCriteria
Call: array getTeachersByCriteria(object TeacherInfo)
Description: The getTeachersByCriteria function can be called as the above notation describes. Additionally, the getTeachersByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Teacher objects.
getTeacher
Call: object getTeacher(int TeacherID)
Description: The getTeacher function can be called as the above notation describes. Unlike, the getTeachersByCriteria function. The TeacherID must be passed in order to find a matching table entry.
Return: A row from Teacher table as an object.
addTeacher
Call: int addTeacher(object TeacherInfo)
Description: The addTeacher function can be called as the above notation describes. The addTeacher function will add a teacher to the SQL table when invoked. During the call the object of TeacherInfo is required.
Return: The TeacherID of the teacher just created, or NULL if unsuccessful.
updateTeacher
Call: boolean updateTeacher(object TeacherInfo)
Description: By passing the TeacherID and the TeacherInfo, you can call the updateTeacher function. The updateTeacher function will find the proper teacher by use of the TeacherID and add the new information contained in the object TeacherInfo that was passed.
Return: Boolean value.
deleteTeacher
Call: boolean deleteTeacher(int TeacherID)
Description: When passed the TeacherID, the deleteTeacher will search through the table and erase the row corresponding to that TeacherID. Once the teacher has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted teacher information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
Parent Functions
The functions below are associated with the Parent table and will allow the programs to retrieve parent information based upon certain search criteria or by a known ParentID. They will also allow the addition of new parents as well as modifying and deleting existing parents.
getParentsByCriteria
Call: array getParentsByCriteria(object ParentInfo)
Description: The getParentsByCriteria function can be called as the above notation describes. Additionally, the getParentsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Parent objects.
getParent
Call: object getParent(int ParentID)
Description: The getParent function can be called as the above notation describes. Unlike, the getParentsByCriteria function. The ParentID must be passed in order to find a matching table entry.
Return: A row from Parent table as an object.
addParent
Call: int addParent(object ParentInfo)
Description: The addParent function can be called as the above notation describes. The addParent function will add a parent to the SQL table when invoked. During the call the object of ParentInfo is required.
Return: The ParentID of the parent just created, or NULL if unsuccessful.
updateParent
Call: boolean updateParent(object ParentInfo)
Description: By passing the ParentID and the ParentInfo, you can call the updateParent function. The updateParent function will find the proper parent by use of the ParentID and add the new information contained in the object ParentInfo that was passed.
Return: Boolean value.
deleteParent
Call: boolean deleteParent(int ParentID)
Description: When passed the ParentID, deleteParent will search through the table and erase the row corresponding to that ParentID. Once the parent has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted parent information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
ParentsToStudents Functions
These functions will access the ParentsToStudents table and allow the ability to get the students associated with a particular parent. The students are chosen from exiting students in the Students table and the parents are chosen from existing parents in the Parents table. The addition and deletion of students to a particular parent is also supported.
getStudentsOfParent
Call: array getStudentsOfParent(int ParentID)
Description: When passed the ParentID, the getStudentsOfParents function will return the Student objects of all the students who are children of the parent.
Return: An array of Student objects.
getParentsOfStudent
Call: array getParentsOfStudent(int StudentID)
Description: When passed the StudentID the getParentsOfStudents function will return an array of Parent objects corresponding to the parents of whom the student is a child.
Return: An array of Parent objects.
deleteParentToStudent
Call: boolean deleteStudentFromSection(int ParentID, int StudentID)
Description: Implemented if you are attempting to remove a ParentToStudent relationship. If either field is set to NULL, then all matches of the other field will be removed.
Return: Boolean value.
addParentToStudent
Call: boolean addStudentToSection(int ParentID, int StudentID)
Description: Adds a ParentToStudent relationship.
Return: Boolean value.
Student Functions
The functions below are associated with the Student table and will allow the programs to retrieve student information based upon certain search criteria or by a known StudentID. They will also allow the addition of new students as well as modifying and deleting existing students.
getStudentsByCriteria
Call: array getStudentsByCriteria(object StudentInfo)
Description: The getStudentsByCriteria function can be called as the above notation describes. Additionally, the getStudentsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Student objects.
getStudent
Call: object getStudent(int StudentID)
Description: The getStudent function can be called as the above notation describes. Unlike, the getStudentsByCriteria function. The StudentID must be passed in order to find a matching table entry.
Return: A row from Student table as an object.
addStudent
Call: int addStudent(object StudentInfo)
Description: The addStudent function can be called as the above notation describes. The addStudent function will add a student to the SQL table when invoked. During the call the object of StudentInfo is required.
Return: The StudentID of the student just created, or NULL if unsuccessful.
updateStudent
Call: boolean updateStudent(object StudentInfo)
Description: By passing the StudentID and the StudentInfo, you can call the updateStudent function. The updateStudent function will find the proper student by use of the StudentID and add the new information contained in the object StudentInfo that was passed.
Return: Boolean value.
deleteStudent
Call: boolean deleteStudent(int StudentID)
Description: When passed the StudentID, deleteStudent will search through the table and erase the row corresponding to that StudentID. Once the student has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted student information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
SectionsToStudents Functions
These functions will access the SectionToStudents table and allow the ability to get the students associated with a particular section. The students are chosen from exiting students in the Students table and the sections are chosen from existing sections in the Sections table. The addition and deletion of students to a particular section is also supported.
getStudentsInSection
Call: array getStudentsInSection(int SectionID)
Description: When passed the SectionID, the getStudentsInSection function will return an array of Student objects consisting of all the students in the section.
Return: An array of Student objects.
getSectionsOfStudent
Call: array getSectionsOfStudent(int StudentID)
Description: When passed the StudentID the getSectionsOfStudent function will return an array of Section objects corresponding to the sections of which the student is a member.
Return: An array of Section objects.
deleteSectionsToStudents
Call: boolean deleteSectionsToStudents(int SectionID, int StudentID)
Description: Implemented if you are attempting to remove a student from a section. If either field is set to NULL, then all matches of the other field will be removed.
Return: Boolean value.
addSectionsToStudents
Call: boolean addSectionsToStudents(int SectionID, int StudentID)
Description: Adds a student to a section.
Return: Boolean value.
Section Functions
The functions below are associated with the Section table and will allow the programs to retrieve section information based upon certain search criteria or by a known SectionID. They will also allow the addition of new sections as well as modifying and deleting existing sections.
getSectionsByCriteria
Call: array getSectionsByCriteria(object SectionInfo)
Description: The getSectionsByCriteria function can be called as the above notation describes. Additionally, the getSectionsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the subject field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Section objects.
getSection
Call: object getSection(int SectionID)
Description: The getSection function can be called as the above notation describes. Unlike, the getSectionsByCriteria function. The SectionID must be passed in order to find a matching table entry.
Return: A row from Section table as an object.
addSection
Call: int addSection(object SectionInfo)
Description: The addSection function can be called as the above notation describes. The addSection function will add a section to the SQL table when invoked. During the call the object of SectionInfo is required.
Return: The SectionID of the section just created, or NULL if unsuccessful.
updateSection
Call: boolean updateSection(object SectionInfo)
Description: By passing the SectionID and the SectionInfo, you can call the updateSection function. The updateSection function will find the proper section by use of the SectionID and add the new information contained in the object SectionInfo that was passed.
Return: Boolean value.
deleteSection
Call: boolean deleteSection(int SectionID)
Description: When passed the SectionID, the deleteSection will search through the table and erase the row corresponding to that SectionID. Once the section has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted section information from the weekly sd6 backup file stored offsite.
Return: Boolean value.
Section Quizzes Functions
These functions will access the SectionQuizzes table and allow the ability to get the quizzes associated with a particular section. The quizzes are chosen from exiting quizzes in the Quiz table. The addition and deletion of quizzes to a particular section is also supported. See the Quizzes Functions sections for information on modifying a quiz.
getSectionQuiz
Call: object getSectionQuiz (int SectionID)
Description: When passed the SectionID, the getSectionQuiz function will search through the table and return the Section Quiz objects associated with a SectionID.
Return: A row from the Section Quiz table as an object.
getSectionQuizzesByCriteria
Call: object getSectionQuizByCriteria(object SectionQuizInfo)
Description: The getSectionQuizByCriteria function can be called as the above notation describes. Additionally, the getSectionQuizByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting a field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of Section objects.
deleteSectionQuiz
Call: boolean deleteSectionQuiz(int SectionQuizID)
Description: Implemented if you are attempting to remove a section quiz from a section.
Return: Boolean value.
addSectionQuiz
Call: boolean addSectionQuiz(object SectionQuizInfo)
Description: If an addition of a quiz to a section is necessary, call this function. Be sure to pass all values in the call. A new row will be created in the Section Quiz Table.
Return: Boolean value.
updateSectionQuiz
Call: boolean addSectionQuiz(object SectionQuizInfo)
Description: If an addition of a quiz to a section is necessary, call this function. Be sure to pass all values in the call. A new row will be created in the Section Quiz Table.
Return: Boolean value.
Quiz Records Functions
These functions will access the QuizRecords table and allow the ability to get the results of a quiz that a student took. The quizzes are chosen from existing quizzes in the Quiz table and the students are chosen from the existing students in the Student table.
getQuizRecord
Call: object getQuizRecord(int QuizRecordID)
Description: When passed the QuizRecordID, the getQuizRecord function will search through the table and return the row associated with that QuizRecordID.
Return: An object of QuizRecordInfo corresponding to a QuizRecordID.
getQuizRecordsByCriteria
Call: array getQuizRecordsByCriteria(object QuizRecordInfo)
Description: The getQuizRecordsByCriteria function can be called as the above notation describes. Additionally, the getQuizRecordsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the Timestamp field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of QuizRecordInfo objects.
deleteQuizRecord
Call: boolean deleteQuizRecord(int QuizRecordID)
Description: Implemented if you are attempting to remove a quiz record.
Return: Boolean value.
addQuizRecord
Call: boolean addQuizRecord(object QuizRecordInfo)
Description: Adds the results of a taken quiz to the database. Be sure to pass all values in the call. A new row will be created in the QuizRecords Table.
Return: Boolean value.
updateQuizRecord
Call: boolean updateQuizRecord(object QuizRecordInfo)
Description: If an update to a quiz record is necessary, call this function. Be sure to pass all values in the call.
Return: Boolean value.
Problems Answered Functions
These functions will access the ProblemsAnswered table and allow the ability to get the results of a quiz that a student took. The problems are chosen from existing problems in the Problems table and the quiz records are chosen from existing quiz records in the Quiz Records table.
getProblemAnswered
Call: object getProblemAnswered(int ProblemAnsweredID)
Description: When passed the ProblemAnsweredID, the getProblemAnswered function will search through the table and return the row associated with that ProblemAnsweredID.
Return: An object of ProblemAnsweredInfo corresponding to a ProblemAnsweredID.
getProblemsAnsweredByCriteria
Call: array getProblemsAnsweredByCriteria(object ProblemAnsweredInfo)
Description: The getProblemsAnsweredByCriteria function can be called as the above notation describes. Additionally, the getProblemsAnsweredByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, omitting the Corrent field indicates it is a wildcard. The same can be done for all other parameters.
Return: Array of ProblemAnsweredInfo objects.
deleteProblemAnswered
Call: boolean deleteProblemAnswer(int ProblemAnswerID)
Description: Implemented if you are attempting to remove a problem answer.
Return: Boolean value.
addProblemAnswered
Call: boolean addProblemAnswered(object ProblemAnswerInfo)
Description: Adds the results of an answered problem to the database. Be sure to pass all values in the call. A new row will be created in the ProblemsAnswered Table.
Return: Boolean value.
updateProblemAnswered
Call: boolean updateProblemAnswered(object ProblemAnswerInfo)
Description: If an update to a problem answer is necessary, call this function. Be sure to pass all values in the call.
Return: Boolean value.
Table Definitions
This section specifically deals with defining the MySQL tables and the table variables within them. The tables include: Schools, Teachers, Parents, ParentsToStudents, Students, Sections, Administrators, CourseCoordinators, SectionStudents, SectionQuizzes, QuizRecords, and ProblemsAnswered. A description of the Users table can be found in the Authentication and Registration documentation, and a description of the Quizzes, QuizProblems, Problems, ProblemChoices, and Files tables can be found in the quizzing documentation. Each table is listed by name and then the fields are listed with short descriptions of each field and their accepted values.
Each table represents a different object, with the same name as the table. To create a new object, you would either call the constructor for that object, or call the setName method where Name is the name of the table field you want to set. In the same way, to retrieve values from an object, you would call the getName method where Name is the name of the table field you want to retrieve.
Schools Table
The schools table will hold information about individual schools. Sections, grades, students, etc. will be tied to schools through this table’s SchoolID number.
1 SchoolID
The unique ID number of the school. This is used to identify which teachers, students, etc. belong to which school.
Type: Unsigned Int
2 Name
The school’s name.
Type: String
3 Address
The school’s address.
Type: String
4 City
The school’s city.
Type: String
5 State
The school’s state.
Type: String
6 Zip
The school’s zip code.
Type: Unsigned Int
7 Description
A short description of the school
Type: Text
Teachers Table
The teachers table will hold information about individual teachers. Sections, students, etc. will be tied to teachers through this table’s TeacherID number.
8 TeacherID
The unique ID number for this teacher. This allows sections to be tied back to individual teachers.
Type: Unsigned Int
9 SchoolID
Which school this teacher belongs to.
Type: Unsigned Int
10 Username
The username used by this teacher to log in.
Type: String
Parents Table
The parents table will hold information about the parents of students.
11 ParentID
The unique numeric ID assigned to this parent.
Type: Unsigned Int
12 Username
The username used by this parent to log in.
Type: String
13 PhoneNumber
The phone number of this parent.
Type: String
ParentsToStudents Table
The ParentsToStudents table will hold information which students have which parents. This table structure allows for a many-to-many relationship of students to parents (ie, one student can have multiple parents, and one parent can have multiple children).
14 ParentsToStudentsID
A unique numeric ID for this parent-child relationship.
Type: Unsigned Int
15 ParentID
The numeric ID of the parent.
Type: Unsigned Int
16 StudentID
The numeric ID of the student.
Type: Unsigned Int
Sections Table
The sections table will hold information about individual sections. A ‘section’ is analogous to a class in a school setting; however, the word ‘section’ was used to avoid ambiguity.
17 SectionID
The unique numeric ID of this section. Students, quizzes, and grades can be tied to individual sections by this ID.
Type: Unsigned Int
18 TeacherID
The numeric ID of the teacher teaching this section.
Type: Unsigned Int
19 Subject
The subject of this section.
Type: Global: MTSS_sub, Globey_sub, USA_sub
20 Name
The name of this section.
Type: String
21 Classification
The classification (grade) of the students in the section.
Type: Unsigned Int
Students Table
The school table will hold information about individual students. A student’s grades will be tied to back to him or her through this table’s StudentID number.
22 StudentID
The unique ID number assigned to this student. Grades can be tied back to individual students by this ID number.
Type: Unsigned Int
23 Username
The username used by the student when logging in.
Type: String
24 Classification
The classification of the student (the grade the student is in).
Type: Unsigned Int
Administrators Table
The Administrators table will hold information about administrators.
25 AdministratorID
The unique ID number assigned to this administrator.
Type: Unsigned Int
26 SchoolID
The ID number of the school to which this administrator belongs.
Type: Unsigned Int
27 Username
The username used by this administrator to log in.
Type: String
Coordinators Table
The Coordinators table will hold information about course coordinators.
28 CoordinatorID
The unique ID number assigned to this coordinator.
Type: Unsigned Int
29 SchoolID
The ID number of the school to which this coordinator belongs.
Type: Unsigned Int
30 Subject
The subject this coordinator coordinates.
Type: Global: MTSS_sub, Globey_sub, USA_sub
31 Username
The username used by this coordinator to log in.
Type: String
SectionsToStudents Table
The SectionStudents table will hold information about which students are in which sections. This table structure allows for one student to be in multiple sections, and one section to contain multiple students.
32 SectionStudentID
A unique ID number for this section-student relationship.
Type: Unsigned Int
33 StudentID
The student’s numeric ID.
Type: Unsigned Int
34 SectionID
The numeric ID of the section to which the student belongs.
Type: Unsigned Int
SectionQuizzes Table
The SectionQuizzes table will hold information about which students are able to take which quizzes. This table structure allows for one student to take multiple quizzes, and one quiz to be taken by multiple students.
35 SectionQuizID
A unique ID number for this section-student relationship.
Type: Unsigned Int
36 QuizID
The numeric ID of the quiz.
Type: Unsigned Int
37 SectionID
The numeric ID of the section to which the quiz belongs.
Type: Unsigned Int
38 DateTimeAvailable
The date and time at which this section will be able to take the quiz.
Type: String of form 'YYYY-MM-DD HH:MM:SS'
39 DateTimeDue
The date and time at which this quiz is due for this section.
Type: String of form 'YYYY-MM-DD HH:MM:SS'
40 QuizNumber
The number that this quiz will be taken by this section in relation to other quizzes taken in this section.
Type: Unsigned Int
41 RetryQuiz
Whether or not the quiz can be retaken by a student.
Type: Boolean
42
43 RetryProblems
Whether or not a student can retry a problem.
Type: Boolean
44 QuizFeedback
Whether or not a student will get feedback once they complete a quiz.
Type: Boolean
45 ProblemFeedback
Whether or not a student will get feedback once they complete a problem.
Type: Boolean
QuizRecords Table
The QuizRecords table will hold information about individual quizzes taken by students. This table structure will allow one quiz to be taken multiple times by the same student. Each time a quiz is taken, an entry is generated in this table.
46 QuizRecordID
The unique numeric ID assigned to this instance of a quiz being taken.
Type: Unsigned Int
47 StudentID
The numeric ID of the student that took the quiz.
Type: Unsigned Int
48 QuizID
The numeric ID of the quiz that was taken.
Type: Unsigned Int
49 SectionID
The numeric ID of the section for which this quiz was taken.
Type: Unsigned Int
50 Timestamp
The time and date at which this quiz was taken.
Type: String of form 'YYYY-MM-DD HH:MM:SS'
51 PointsAwarded
The number of points awarded for this attempt at the quiz.
Type: Unsigned Float
ProblemsAnswered Table
The ProblemsAnswered table will hold information about the problems answered on a quiz.
52 ProblemAnsweredID
The unique numeric ID assigned to this problem-answer relationship.
Type: Unsigned Int
53 QuizRecordID
The numeric ID of the quiz attempt on which this problem was answered.
Type: Unsigned Int
54 ProblemChoiceID
The choice number chosen for the answer.
Type: Unsigned Int
55 ProblemID
The numeric ID of the problem answered.
Type: Unsigned Int
56 AnswerGiven
The text of the answer given, if not a multiple-choice question.
Type: String
57 Correct
Whether or not this answer was counted as correct.
Type: Bool
58 PointsAwarded
The number of points awarded for this answer.
Type: Unsigned Float
Table Diagram
This section contains a useful diagram describing the table relationships in the database. This diagram attempts to represent as fully as possible the relationships and fields within each table.
[pic]
Conclusion
Project Team Information
Client Information
Ames Community Schools
Administrative Offices
1921 Ames High Drive
Ames, IA 50010
Phone: 515-268-6600
Faculty Advisor Information
|Dr. John Lamont |Professor Ralph Patterson, III |
|324 Town Engineering |326 Town Engineering |
|Ames, IA 50011-3230 |Ames, IA 50011-3230 |
|Phone: 515-294-3600 |Phone: 515-294-2428 |
|Fax: 515-294-6760 |Fax: 515-294-6760 |
|jwlamont@iastate.edu |repiii@iastate.edu |
CprE/EE 492 Member Information
|Mark Klein |Jason Wilkinson |
|Computer Engineering |Computer Engineering / Computer Science |
|614 Billy Sunday Rd #107 |6214 Frederiksen Ct. |
|Ames, IA 50014 |Ames, IA 50010 |
|515-292-5249 |515-572-7729 |
|mdklein@scl. |jdwilk@iastate.edu |
| | |
CprE/EE 491 Member Information
|Nate Gordon |Nichole Burgett |
|Computer Engineering |Computer Engineering / Computer Science |
|2219 Friley Pearson |1636 12th St. |
|Ames, IA 50012 |Boone, IA 50036 |
|515-297-1747 |515-432-2408 |
|nlgordon@iastate.edu |nburgett@iastate.edu |
|Parikshit Advani | |
|Computer Engineering | |
|119 Stanton Avenue #422 | |
|Ames, IA 50014 | |
|515-441-0945 | |
|parik5@iastate.edu | |
Summary
This document highlights the necessary functions and tables the framework should create in order to provide the other ongoing teams with useful support. Since the sub teams have worked largely independent of each other it was necessary for the framework team to make the library of functions as dynamic as possible, allowing for a greater flexibility.
This document will serve as a general guide for the present Ongoing 08 and future Ongoing 08 teams when they are constructing and utilizing the functions explained here in. If functions are found to be unnecessary and not useful to any Ongoing 08 team, it should be removed from this document and from the framework itself.
As a reminder, this document is tentative and subject to change within the future. Presently, this is the course for which the framework team (Ongo 08d) will strive for.
-----------------------
Figure 17. Testing Cycle Diagram.
[pic]
Figure 1. Conceptualization of application suite organization.
Figure 9. Initial USA navigational map.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- k 12 online homeschooling free
- k 12 rankings by state
- k 12 online homeschooling
- k 12 portal home
- k 12 parent log in
- k 12 parent portal cps
- k 12 homeschool texas
- michigan k 12 school district data
- k 12 online homeschooling missouri
- fox k 12 school district
- k 12 student log in
- k 12 educational software companies