K-12 Teaching Application Supportseniord.ece.iastate.edu/projects/archive/ongo08a/... · Web viewThe statistical analysis modules will provide invaluable insight to the teachers and

MTSS Status Report April 2005

K-12 Teaching Application SupportMathematical Teaching Software System

Project Ongo08a

Status Report

Client:Ames Community Schools

Faculty Advisors:Dr. John Lamont

Prof Ralph Patterson III

CprE/EE 492 Team Member:

Tuan CaoDoug Doan

CprE/EE 491 Team Members:

David WireTiffany Schweer

Sara MurphyJohn Saterfiel

REPORT DISCLAIMER NOTICEDISCLAIMER: 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.

Copyright 2005 Ongo08a Team


April 1, 2004Table of Contents

REPORT DISCLAIMER NOTICE..........................................................................1

List of Figures......................................................................................................4List of Tables.......................................................................................................5List of Definitions................................................................................................61. General Overview............................................................................................72. Introductory Materials.....................................................................................7

2.1 EXECUTIVE SUMMARY....................................................................................72.1.1. Need for the Project...............................................................................82.1.2. Project Description................................................................................82.1.3. Results to Date......................................................................................92.1.4. Work Remaining....................................................................................9

2.2 ACKNOWLEDGEMENTS....................................................................................92.3 PROBLEM STATEMENT..................................................................................102.4 OPERATING ENVIRONMENT...........................................................................112.5 INTENDED USERS AND USES.........................................................................112.6 ASSUMPTIONS AND LIMITATIONS...................................................................11

2.6.1. Assumptions........................................................................................112.6.2. Limitations...........................................................................................12

2.7 EXPECTED END PRODUCT AND OTHER DELIVERABLES..................................12

3. Project Accomplishments and Status.........................................................133.1 PREVIOUS ACCOMPLISHMENTS.....................................................................13

3.1.1 Spring 2001..........................................................................................133.1.2 Fall 2001...............................................................................................143.1.3 Spring 2002..........................................................................................153.1.4 Fall 2002...............................................................................................153.1.5 Spring 2003..........................................................................................163.1.6 Fall 2003...............................................................................................163.1.7 Spring 2004..........................................................................................173.1.8 Fall 2004...............................................................................................17

3.2 PRESENT ACCOMPLISHMENTS.......................................................................183.3 FUTURE REQUIRED ACTIVITIES.....................................................................193.4 CURRENT PROJECT AND END PRODUCT STATUS...........................................203.5 RECOMMENDATION FOR CONTINUED WORK..................................................21

4. Documentation of Current Efforts and Results..........................................214.1 PROJECT DEFINITION ACTIVITIES..................................................................21

2


4.2 RESEARCH ACTIVITIES.................................................................................234.3 DESIGN ACTIVITIES.......................................................................................274.4 IMPLEMENTATION ACTIVITIES........................................................................284.5 TESTING AND MODIFICATION ACTIVITIES.......................................................29

5. Resources and Schedule..............................................................................295.1 RESOURCE REQUIREMENTS..........................................................................30

5.1.1 Personnel Effort Budget.......................................................................305.1.2 Other Resource Requirements.............................................................315.1.3 Financial Requirements........................................................................31

5.2 SCHEDULES.................................................................................................335.2.1 Project Schedule..................................................................................335.2.2 Project Deliverables..............................................................................33

6. Closure Materials..........................................................................................346.1 LESSONS LEARNED......................................................................................346.2 RISK AND RISK MANAGEMENT......................................................................356.3 PROJECT TEAM INFORMATION......................................................................37

Appendix A........................................................................................................40SCREENSHOTS OF MTSS...................................................................................40SCREENSHOTS OF QUIZZING/GRADING APPLICATION...........................................43

Appendix B........................................................................................................45MTSS WISH LIST...............................................................................................45

Problem Solving Algorithm............................................................................45Statistics........................................................................................................45User Administration.......................................................................................45Problems.......................................................................................................45

Appendix C........................................................................................................47PROBLEM SOLVING ALGORITHM RESEARCH........................................................47

The Problem Solving Process.......................................................................47

3


List of FiguresFigure 1: Project Schedule...............................................................................33Figure 2: Deliverables.......................................................................................34

4


List of TablesTable 1: List of Acronyms and Definitions........................................................6Table 2: Estimated Personnel Resource Distribution....................................30Table 3: Actual Personnel Resource Distribution..........................................31Table 4: Estimated Other Resource Requirements........................................31Table 5: Actual Other Resource Requirements..............................................31Table 6: Estimated Financial Requirements...................................................32Table 7: Actual Financial Requirements.........................................................32

5


List of DefinitionsTable 1: List of Acronyms and Definitions

Acronym Definition

ACS Ames Community Schools

ASPActive server pages (a Microsoft web technology allowing a

server to calculate and generate web pages)

CGI Common gateway interface

GUI Graphic user interface

HTMLHyper Text Markup Language (any regular web page is

written in HTML)

IBM-compatiblePersonal computers that run a Microsoft Windows operating

system

IIS Internet information server

MTSS Mathematical Teaching Software System

MySQL A variant of Structured Query Language (SQL)

PHP

PHP Hypertext Preprocessor (a recursive acronym) is an

open source web technology allowing a server to calculate

and generate web pages.

SQLStructured Query Language (used to talk to the central

database)

VB Visual Basic computer language

VBScript Visual Basic scripting designed for HTML use

6


1. General OverviewThe purpose of this status report is to record the progress and status of the

Mathematical Teaching Software System (MTSS) project throughout the

semester. Basically, this report is divided into the following sections:

Introductory Materials

Project Accomplishment and Status

Documentation of Current Efforts and Results

Resources and Schedules

Closure Materials

2. Introductory MaterialsThis section of the report intends to familiarize the reader with the project. It is

divided into the following subsections:

1. Executive Summary

2. Acknowledgements

3. Problem Statement

4. Operating Environment

5. Intended Users and Uses

6. Assumptions and Limitations

7. Expected End Product and Other Deliverables

2.1 Executive Summary

The subsections of this executive summary are

1. Need for the project

2. Project Description

3. Results to date

4. Work yet to be completed

7


2.1.1. Need for the Project

The purpose of Mathematical Teaching Software System (MTSS) project is to

help students in grades third through sixth improve their mathematical skills,

supplementing classroom teaching/learning in the area of mathematics, focusing

on the improvement of problem solving skills. MTSS has the potential to go

beyond ACS standardized tests and serve as a corner stone in the development

of mathematical problem solving skills that students will need throughout their

high school and college careers as well.

2.1.2. Project Description

MTSS will provide the supplementary instruction that ACS 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

8


recognizing when to use those operations in a practical application. Also it

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.1.3. Results to Date

Even though the MTSS project has been in progress for a while, the software is

still very much in its infancy. The program as it stands at the moment serves as a

workbook that allows (a) administrators to add new users, (b) teachers to create,

edit and delete problems and quizzes, and (c) students to view and solve

problems and quizzes, and view their grading statistics.

2.1.4. Work Remaining

A lot of software work still remains to be completed for the project. User

administration and management, viewable statistics for teacher and students,

tracking student performance, narrowing the many alternatives of the general

problem solving algorithm that is easiest to implement and meets all the

requirements down to one, and implementing that algorithm so that it is

automated. Appendix A contains a ‘wish-list’ of the features that the current

MTSS team feels should be available in the final product.

2.2 Acknowledgements

The MTSS team wants to extend its thanks to Dr. John Lamont and Prof. Ralph

Patterson, the project’s faculty advisors, for guiding the group throughout the

project planning process. Many of the improvements seen in the PHP version of

the software (after making the transition from ASP) are just implementations of

the recommendations suggested by the faculty advisors. Their continued

support and advice are imperative to the success of the project.

9


2.3 Problem Statement

The general purpose of Mathematical Teaching Software System (MTSS) is to

design an Internet-based teaching software application. This application will

provide children in elementary school grades 3-6 the opportunity to practice core

mathematical problems while exercising computer skills and strengthening

mathematical problem-solving techniques. MTSS will provide mathematical

lessons to students. Teachers and administrators will be allowed access to

student progress reports and will be able to customize lessons. In turn, the

lessons can 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, 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, 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 real-life problems. The research and

design for the problem solving algorithm is still underway. Developments of a

software framework which will support web tools that will allow students to keep

track of their scores via user accounts and allow teachers and administrators

access to customize lessons, quizzes, and problems. These developments will

also allow teachers and administrators to evaluate a student’s performance. This

will be accomplished by utilizing dynamic web pages written using PHP, SQL,

and HTML.

10


2.4 Operating Environment

The MTSS application will run on LAMP (Linux – Apache – MySQL – PHP)

architecture. The client software needs to function on both PC-compatible and

Macintosh-compatible machines. The web application code will be written in PHP

language, which runs as a module in 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.

2.5 Intended Users and Uses

The primary users for MTSS will be the elementary students in grades 3-6, their

teachers and administrators. Other users may include parents and relatives of

students. This application is intended to be used as a supplemental instruction

tool for 3rd-6th grade mathematics teachers. Example problems, homework

problems, practice quizzes and performance quizzes will be provided. Students’

performance will be recorded including scores, time, and number of attempts.

The software will utilize an algorithm to guide the students through general

problem solving techniques.

2.6 Assumptions and Limitations

Similar to any 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.

2.6.1. Assumptions

The following assumptions were made regarding MTSS:

All client computers are connected to the Internet.

Clients are operating Internet Explorer (Version 5.0 or later) or Netscape

(Version 5.0 or later).

Team members will have permission to access the server database.

11


There will be a PHP framework developed to support a set of Internet

educational activities. Ongo08d will provide this framework.

The students have been exposed to the mathematical topics prior to their

initial use of the software. This software shall be a supplement to

classroom instruction.

There will be adequate supervision by someone with computer experience

to assist the students when they are operating the system.

The problem solving algorithm needed to assist students with problem

solving can be computerized.

No students using the software will have disabilities involving sight,

dexterity, and reading comprehension.

The application may be used at home with parent supervision and in a

classroom environment with teacher supervision.

2.6.2. Limitations

Challenges and limitations to development include the following:

New team members may not be familiar with PHP and/or MySQL.

Internet connection and Internet bandwidth are limited and may not be

consistent.

Computer/processor speeds of the client machines are limited.

Size of the database may be limited.

Implementation of problem solving algorithm may become extremely time

consuming for both teachers and development team.

2.7 Expected End Product and Other Deliverables

The end product is a suite of PHP pages that will dynamically build problem and

quiz pages for students depending on the problem category and difficulty desired

by the teachers or administrators. The pages will then guide the students

through the steps of problem solving method with assistance from

teachers/parents. A web solution also allows the pages of generated HTML to

be viewed on any platform. Teachers will be able to create/modify/delete quizzes,

12


grades, view results of work, and compare results from all participating students.

These students do not necessarily need to be in the same classroom with the

teacher. The end product would not only give students problems to solve, it will

help build the problem solving skills of students who are using this software by

aiding them through the algorithm which demonstrates the process of solving a

problem. The software will take the student through the process step by step

until the student understands how to solve the problem. Since this solution is a

“web-based” solution, students will have the opportunity to work on problem

solving skills from home with their parents. This can indirectly have a large effect

on parent involvement with the education process.

3. Project Accomplishments and StatusThis section of the report summarizes the works that have been done on this

project since its inception. It is divided into the following subsections:

Previous accomplishments

Present accomplishments

Future required activities

Current project and end product status

Recommendation for continued work

3.1 Previous Accomplishments

This subsection documents the works done by the previous members of the

MTSS team, from Spring 2001 to Fall 2004.

3.1.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

13


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

3.1.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.

14


Developed a text-based menu that will provide an intuitive interface to the

MTSS ASP pages.

3.1.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.

3.1.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.

15


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.

3.1.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

3.1.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

16


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 and the

remaining will be added 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

3.1.7 Spring 2004

The following list summarizes the projected goals of the present MTSS team, as

well as the status of each at the time of writing of this report.

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

3.1.8 Fall 2004

During this 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:

17


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

3.2 Present Accomplishments

The following list describes the significant accomplishments made during the

current school session Spring 2005. It summarizes the results for each activity

pointing out both successes and failures.

Problem Definition Completion - The project goals for Spring 2005

semester were defined. A list of the project goals and expected end

products was developed and given to all member of the MTSS team.

Software Training Course - A training session teaching the basics of PHP

and MySQL was held on February 13, 2005. As a result all team members

became more acquainted with the overall K-12 Teaching Application

Support Software, and more familiar with PHP and MySQL by completing

tutorials prepared and presented by the Ongo8d team.

Research Problem Solving Techniques - This task is only partially

completed because the team has come across a new contact regarding

teaching of the problem solving algorithm. The result thus far is a document

outlining 3 problem solving algorithms. Detailed information regarding each

algorithm has been outlined and presented in the document. Although an

initial decision has been made to use the generic problem solving algorithm.

The final decision will be made once input has been made from the teams

contact.

Gradebook Functionality - The goal of this task was to implement software

that would allow students the ability to take quizzes, and allow the quizzes

to be graded and that grade to be maintained in a database where it will be

used by other teams of the K-12 Teaching support software to modify and

18


display. This task has partially been completed and will be completed by

April 15, 2005.

Semester Plan - A document clearly defining the goals and schedule this

semester was completed.

Project Poster - A poster highlighting the project details and project plan

was developed and is displayed in the front of Coover Hall on the Iowa

State University Campus.

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.

Weekly E-mail Reporting - The communications coordinator for Ongo08

kept the instructor posted on the developments in the project through

weekly emails.

3.3 Future Required Activities

Future MTSS teams will be responsible to continue and to build on the work that

done by all previous teams as well as the present team in particular. More

specifically, the following activities are absolutely essential.

Evaluate feedback from ACS teachers and make changes as appropriate

Narrow down all the problem solving algorithm alternatives and pick the

most appropriate one

Implement the new and effective problem solving algorithm into the

software

Implement new features and new interface such as user administration,

problem set management, statistics, games, tutorials etc.

Checking and updating the testing matrix as the software is further

developed.

Providing testing support and response as quickly as possible to the

clients.

19


3.4 Current Project and End Product Status

This subsection describes how the MTSS software project has developed this

semester, and where exactly it stands at this moment of writing this report.

At the beginning of this semester, the MTSS team had a functional program

written using PHP and 160 fraction problems with the shared quizzing application

for that was created from last semester. The main objectives of this semester is

to implement a quizzing GUI and the gradebook functionality with the code that

was provided by the framework subgroup and pick one of the three problem

solving algorithms, then devise a plan on how to implement it. Currently, the

team is working on a new and effective problem solving algorithm to aid the

student through solving a problem (see Appendix C).

However, there were three potential obstacles for the process to go on smoothly,

namely

In order to get feedback, a working version of MTSS had to be put out

as quickly as possible and

The PHP framework that would have accelerated the transition so that

each group of Ongo08 can have their completed version of framework

to work with

The problem solving algorithm found out to be extremely hard to

implement in the sense that converting those definition and algorithm

into actual codes. Hence we had to develop a new one.

In order to deal with the first problem, the PHP code needed to be maintained

and to be tested occasionally. Currently a demo application has been put out and

has been seen by some school representatives. The feedback was all very

positive, but we need to get the demo to the teachers and students so we can get

some good feedback from the true users of the application.

20


For the second problem, the framework team would have accelerated the

transition because everything was related to the database therefore a complete

version of framework would be helpful to the process of coding this program.

For the third problem the team is still trying to find a simple but effective definition

of the problem solving algorithm. The team has found a couple of versions of the

algorithm and it is listed in Appendix C.

3.5 Recommendation for Continued Work

The final version of the framework will be carefully examined once it becomes

available in order to verify that it will meet the requirements of MTSS.

Additionally, it would be beneficial to routinely evaluate feedback from ACS

teachers involved with the MTSS project to confirm the software has the desired

functionality. Changes will have to be made to the code as per the

recommendations of the users (teachers and students), and for the integration

into the framework. The problem solving skills is one of the hardest thing for a

student to grasp, so if MTSS can be completed and meet all the requirements

that was placed upon it, it will make it easier for teachers to get the ideas across

to their students.

4. Documentation of Current Efforts and ResultsThis section of the report intends to document the work done in the current

semester separated into the different components of project development,

namely (1) project definition activities, (2) research activities, (3) design activities,

(4) implementation activities and (5) testing and modification activities.

4.1 Project Definition Activities

The project definition activities this semester included initial definition of the

project, a course covering the basics of PHP and MySQL, a course covering the

framework of the project, and a course covering the framework of the gradebook.

21


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 initial definition was handled in a combination of two meetings. In the first

meeting information was presented regarding the background of the MTSS

project. Past accomplishments were presented, and the cliental were also

introduced to the current members of the team. The scope of the project for the

spring 2005 semester was described to the entire team resulting in defining two

goals for the current semester. The first was to create an algorithm to implement

into the MTSS software detailing a way to implement the steps teachers uses to

help students learn how to solve word problems. This algorithm known as the

Problem Solving Algorithm was highlighted as the main goal for the semester.

The second goal defined for the project was to implement a portion of software

that is used to keep track of students’ scores and other progress tracking

information. This portion of the project was deemed the gradebook. During the

second meeting the team split into two sub-teams to handle the goals for the

semester. Four of the six students were assigned to the Problem Solving

Algorithm, and the other two students were assigned to the gradebook, and any

other small portions of code that may need to be implemented. During the

second meeting the goals, scope, and project schedule were determined and

work began on the project plan.

A course introducing PHP, and MySQL was scheduled for January, 23, 2005.

This course was presented by 492 students who had already been involved with

the project for one semester. New students were given modules to complete

which walked them through examples of syntax and important functions of PHP

and MySQL.

22


The second training course consisted of two topics. This course presented the

framework of the database that supports the entire K-12 Teaching Support

Software project. A number of modules were used to present basic functions to

maintain for example, the adding and deleting of students. The documentation

for these functions can be found at http://seniord.ee.iastate.edu/ongo08d. Along

with the framework of the database, the functionality designed to implement the

gradebook and status tracking tools were presented.

Once the project definition activities had been completed, all team members had

the needed information to begin work on the current semester goals for the

project.

4.2 Research Activities

The research activities for the MTSS team were based on the Problem Solving

Algorithm. The first task was for the team to gain a scope of how students solve

problems. The research focused on what problem solving techniques have been

used by area schools, and what problem solving techniques have been taught

world wide in various disciplines. The students of MTSS were given example

problems from the client ACS. From these questions the team was able to get a

general sense of the types of things teachers want their students to be thinking

about as they solve problems. Common questions were:

Can a figure be used to help solve this problem?

Can the trial and error method be used to help solve this problem?

What are the conditions of the problem?

What information is implied about this problem?

Have you seen a similar problem before that may be able to help solve

this problem?

What are you asked to find?

23

http://seniord.ee.iastate.edu/ongo08d


Included with the material from ACS was a four-step method that was deemed,

Teaching the Strategies. The steps to this problem solving algorithm are as

follows:

1. Find Out - Determine what the problem means and what question

must be answered to solve it. This step means that the student must

be able to fully understand the problem, and must be able to

understand what the important information is and what information is

not important. If need be student must be able to break the problem

up into smaller problems.

2. Choose a Strategy- There are a number of ways to solve problems

either using visuals, or known thermos, or work backwards from what

you know. This step in Teaching Strategies allows the student to use

one or more to solve the problem.

3. Solve It – Using the strategies the student chose above, work through

the problem until an answer is found. If no answer can be found from

the strategies chosen, find a new strategy and work to solve the

problem.

4. Look Back- Reread the problem and see if the answer found meets

the conditions of the problem. Is the answer logical and reasonable?

In doing research online to find variations to a problem solving algorithms it was

found that Math Counts also uses the exact same strategies as ACS. Math

Counts is a national enrichment, coaching, and competition program that

promotes middle school mathematics achievement. As part of their coaching

packet they include documentation on teaching how to solve problems. Math

Count’s documentation listed the exact same steps as listed above by ACS.

There were two journals that the team thought would be helpful in their search to

find various problem solving algorithms. The journals were Teaching

Mathematics and its Applications, and Teaching Children Mathematics. Team

24


members read through a number of articles, but found that most of the articles

contained information regarding creative ways to teach different concrete

concepts in math. No articles that the team ran across dealt directly with breaking

the idea of problem solving up into steps.

One team member also talked with a professor from a course on campus. The

course is aimed at teaching Curriculum and Instruction students how to teach

math to elementary students. Although this seemed to be a good place to gain

knowledge on how teachers may teach students to solve problems, the focus of

the class was more on teaching Curriculum and Instruction students techniques

for teaching elementary students the basics in math, such as long division and

multiplication. Not much if any class time was given to methods of solving word

problems.

The team received an email from Dr. Thomas H. Saterfiel, the Senior Vice

President of Corporate Development at ACT Corporation, discussing some

concerns that he had with implementing a problem solving algorithm into a

software application. Dr. Saterfiel stated:

“One of the key elements in problem solving is that no one can advance in

a problem solving effort unless it is in a given context. For example the

problem solving effort to resolve a science issue is not the same thing as a

problem solving effort in verbal communications.”

This concern was presented to the advisors of the project, Dr. John Lamont and

Prof. Ralph Patterson, but they directed the team to find a problem solving

algorithm that could be used to solve any kind of problem. With this direction the

team continued its research on various problem solving algorithms, while

focusing on finding problem solving methods used in other disciplines.

25


The internet was full of steps to problem solving. Many departments within a

university have web sites devoted to teaching their students good problem

solving skills. Most of these sites contained the same concept as listed above

just in a more detailed sense. Most of the time the methods just broke the

second and third steps into a more defined process so that it could teach

students how to solve problems based on algebraic equations. In the world of

business the idea of problem solving is based more on critical thinking, or

creative thinking, although fundamentally the same it all boiled down to the same

concept as the four steps of the problem solving method listed above.

The four steps listed above where compared with the research from the Fall 2004

semester. There were two algorithms defined, the General Problem solving

algorithm and the Current Problem Solving Model. The general problems solving

algorithm was very similar to the four-step model listed above except that it had

broken up the middle steps more. The team thought that this would be the best

model to use. The research from Fall 2004, which includes the General Problem

Solving Algorithm, can be found in Appendix C.

The next step that the team took was to look at each step of the problem solving

algorithm separately. Each member of the problem solving algorithm sub-team

took a step and researched the possible ways that each step could be

implemented. Below is a list of the steps and the possible methods of

implementation.

1. Identify the Problem

Drop-down menu

Partial-text recognition

Full-text recognition

2. Define the Problem

Use natural language parser and some AI to determine what the

right answer is.

26


Have the teacher input all the answers and the questions

themselves through templates.

Information needed to generate automated question to prompt the

student to the correct answer is entered with the question.

3. Explore the Solution

Walk the student through a chosen method to solve the problem

Teacher input information into the program that allows for it to walk

students to choose a method of implementation.

4. Act on Strategies

Once the students choose a strategy the program can walk them

through the steps to solve the problem.

Have the students enter an answer or an initial guess and have the

program check to see if it is correct. If the answer is correct the

program does nothing, if the answer is not correct the program

gives the student the answer and works through the problem

backwards to show them how the answer was found.

5. Look Back and Evaluate the Solution

Ask question to make the student think about the answer before

entering it. Ask questions relating to the units of the answer, or that

question the sign of the number.

Ask the user for the answer and if the answer is wrong display the

correct answer.

This list of possible ways to implement the problem solving algorithm is

only a start. The team plans to use the next month to continue to find

creative ways to implement the defined steps of the algorithm.

4.3 Design Activities

Over the course of the Spring 2005 semester a number of different problems

solving algorithms have been researched. Some of these problem solving

algorithms have been presented to the project advisors. A problem solving

27


algorithm will be selected this semester and the design will be completed for

implementation in the Fall 2005 semester.

A design for the quizzing GUI has also been made, which allows students to take

quizzes that were already created by the teacher using last semester’s quizzing

application. The student will be able to take the quiz over the internet with the

help of teachers or parents. The quiz will then be graded and the grade will be

recorded in the gradebook. The grading of the quiz is another design that will be

accomplished this semester. Using the gradebook functionality that has been

implemented by the framework sub-team, a grading module was created that will

record the scores of each quiz in the gradebook.

4.4 Implementation Activities

The implementations of the framework’s authentication and quizzing functions

have been completed. The grade book implementation and the quizzing GUI will

be completed by the end of the Spring 2005 semester. Using framework’s code

for the quizzing, a GUI was implemented (Figure A.7 in Appendix A). It will allow

the teacher to present the answer to a question in five different ways: 1)

Numerical text, 2) Word text, 3) Multiple choice, 4) Check box and 5) True/False.

The student will then answer the questions by entering a number or a word, click

a choice, check answer(s) or click true/false. The answer will then be sent to the

grading module and there it will be graded and the scores be recorded in the

gradebook.

The gradebook is where all the statistics of the student’s scores will be recorded.

It will be display like a spreadsheet, where a student will be able to see all the

scores of the quizzes/homework that they have taken. The teachers will be able

to see the scores of all their students in each of their sections. The teacher will

have the ability to change a grade, to omit an assignment in case of an excused

absent and other ability that will come up as we design it. MTSS’s portion of the

gradebook was the quizzing GUI, the grading of the quizzes, and the computing

of the statistics. The grading module will tell the students which question was

correct, which was wrong, how many points is each question worth, their score

28


and their grade. The students will then be able to view statistic of all their

quizzes in a spreadsheet set-up, which will be created by another sub-team of

Ongo08.

4.5 Testing and Modification Activities

Alpha testing has been performed by the Ongo08a project team, testing the

MTSS as a whole and investigating possible problems. During alpha testing each

team member tested the system by using at as a teacher and student user;

performing all of the actions that these users would be likely to perform. It was

hoped that this alpha testing would be exhaustive however it was brought to our

attention by Dr. Lamont that the guest user account was not supported by MTSS,

this user account has now been included and is similar to a student account. At

this point in time no other malfunctions have been discovered in the software.

Beta testing with the client school districts is expected to go forward later on this

semester and at the latest sometime in the Fall 2005 semester.

Two sub-groups were formed to separate the task of researching and coding.

The coding group is currently implementing the quizzing functionality. Progress

has been made on this task, as shown in Figure 1, however there are still some

bugs to work out of the GUI as well as some features that were included in the

design that have not yet been included in the implementation. A problem solving

algorithm is currently being selected by the research group. Later on this

semester the implementation will be designed and the problem solving algorithm

will move into the coding or implementation phase in the Fall 2005 semester.

5. Resources and ScheduleThe purpose of this section of the report is to provide details about actual

estimated and utilized resources as well as the project schedules.

29


5.1 Resource Requirements

Three separate components make up the estimated resource requirements,

namely (1) personnel effort budget, (2) other resources budget, and (3) financial

budget.

5.1.1 Personnel Effort Budget

The original estimated personnel effort budget for this semester is included in

Table 2.

Table 2: Estimated Personnel Resource Distribution

Member Class MeetingPresentations & Demonstrations

Documentation & Reporting

Coding & Testing

ResearchTotal (hrs)

Tuan Cao 15 40 10 10 30 5 110Doug Doan 15 30 10 15 5 35 110Tiffany Schweer 30 40 5 30 5 35 145David Wire 30 30 5 30 25 5 125Sara Murphy 30 30 5 25 5 30 125John Saterfiel 30 30 5 25 5 25 120Total (hrs) 150 200 40 125 75 135 625

The required hours have been reduced somewhat from the original estimate,

mainly because the time require for documentation and reporting was

overestimated, and also the semester is not over. Table 3 reflects the actual

time spent as of March 31, 2005.

30


Table 3: Actual Personnel Resource Distribution

Member Class MeetingPresentations & Demonstrations

Documentation & Reporting

Coding & Testing

ResearchTotal (hrs)

Tuan Cao 11 31 4 15 25 5 91Doug Doan 11 20 2 15 0 25 73Tiffany Schweer 22 30 0 25 0 30 107David Wire 22 21 0 20 15 5 83Sara Murphy 22 22 0 25 0 25 94John Saterfiel 22 22 0 20 0 20 84Total (hrs) 110 146 6 120 40 110 532

5.1.2 Other Resource Requirements

The other resource requirements are shown below.

Table 4: Estimated Other Resource Requirements

Item Team Hours Other Hours CostProject Poster and Printing 10 0 $45.00Software Resources 15 0 $0.00Totals 25 0 $45.00

Table 5: Actual Other Resource Requirements

Item Team Hours Other Hours CostProject Poster and Printing 10 0 $63.00Software Resources 15 0 $0.00Totals 25 0 $63.00

5.1.3 Financial Requirements

The estimated financial requirements, not including labor, are shown in Table 7

below.

31


Table 6: Estimated Financial Requirements

Item CostPoster $45.00

Subtotal $45.00Labor ($10.50/hr)

Tuan Cao $1,155.00

Doug Doan $1,155.00

Tiffany Schweer $1,522.50

David L. Wire $1,312.50

Sara Murphy $1,312.50

John Saterfiel $1,260.00

Subtotal $7,717.50TOTAL $7,762.50

The following table shows the actual financial requirements. The discrepancies

are mainly due to the difference in labor hours spent this semester, and also a

slight variance in cost.

Table 7: Actual Financial Requirements

Item CostPoster $63.00Binding $3.95

Subtotal $66.95Labor ($10.50/hr)Tuan Cao $955.50

Doug Doan $766.50

Tiffany Schweer $1,123.50

David L. Wire $871.50

Sara Murphy $987.00

John Saterfiel $882.00

Subtotal $5,586.00

TOTAL $5,652.95

32


5.2 Schedules

MTSS has kept on track with the original schedule by about 70 percent. The

following Gantt charts summarize the team’s current status in comparison with

the estimated schedule.

5.2.1 Project Schedule

Most tasks have been completed as planned. The following chart displays the

actual time spent on the activities in black, and the estimated time spent in the

underlying blue.

Figure 1: Project Schedule

5.2.2 Project Deliverables

All of the deliverables for the semester have been completed on time. The

following chart (Figure 3) summarizes the deliverables for this fall. The estimated

dates are in blue, and completed deliverables are shown with a black line

through the blue.

33


Figure 2: Deliverables

6. Closure MaterialsThere are five components in this final section, (1) lessons learned, (2) risk and

risk management, (3) project team information, (4) closing summary and (5)

Appendices. Each section is as follows.

6.1 Lessons Learned

While working on the MTSS project much knowledge was gained and the tasks

that were completed went well. Implementing the gradebook and quizzing GUI

offers a lot of experience in PHP, HTML, and MySQL. It was necessary to keep

backups of the completed tasks and data incase the MTSS server went down,

which it did once at the beginning of the Spring 2005 semester.

Also much research has been done regarding a definition to the problem solving

algorithm. Basic steps have been decided upon while detailed research to

formulate approaches to implement these steps continues. It is important to

thoroughly research a process and define multiple approaches to determine any

problems that might arise.

34


The importance of communication was an area of non-technical knowledge that

each team member gained by working on the MTSS project. Since each team

member is working independently and working on subgroups, it is necessary for

each member to be informed of exactly what others have been working on is

important so work is not duplicated and the work done can be easily joined with

the rest of the project.

In addition, accurately documenting the project was very important. Groups

working on this project in the future should not have to repeat the work that has

already done. With this in mind, the need for good documentation is a must;

otherwise future groups will not be able to take the project any further than it

already is since they will spend all of their time trying to understand what

previous semesters have accomplished.

6.2 Risk and Risk Management

The biggest risk that the group will face is the possible loss of information when

the team members complete their two semesters on the project. The other

members of the team will have to work closely with these members to ensure

that all of the knowledge that has been acquired is documented. Also backups of

this data will also to be made and all team members should be aware of where

the backups are kept. At the same time, the team will need to select new sub-

team leaders to take over.

Another risk that the group might face is the loss of contacts with our clients.

MTSS has previously lost two teacher contacts that have been replaced by new

personnel in the Curriculum and Instruction Department. The group now needs to

involve the new personnel/instructors in the project. Other schools could be

approached for help if necessary.

Similar to the loss of a client, is the loss of a team member. Fortunately MTSS

has not had face this peril. In the event that such would happen, it is necessary

35


that in weekly updates on each team members project status be known to the

group. A chain of command is also established within the group and within

subgroups to ensure that if a member were gone, another could pick up where

activities had been left off and continue with the needed work on the project.

Finally, the group must be aware of the risk of the failure to properly test all the

software. As this is a large program, systematic testing can take some time, it is

important to realize that some small details can be missed in the testing process,

and these neglected tests must be addressed at some point of time.

36


6.3 Project Team Information

The project team information is as follows:

Client: Ames Community SchoolsAdministrative Offices1921 Ames High DriveAmes, IA. 50010Phone: 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 [email protected] [email protected]

CprE/EE 492 Team Members:Tuan Cao Doug Doan119 N Hyland Ave. #1 4144 Eisenhower LN #5Ames, IA 50014 Ames, IA 50010515-450-9111 [email protected] [email protected] Computer Engineering Computer Engineering

CprE/EE 491Team Members:Sara Murphy John Saterfiel1236 Frederiksen Ct. 7312 Frederiksen Ct.Ames, IA 50010 Ames, IA 50010515-572-7785 [email protected] [email protected] Engineering Computer Engineering

Tiffany Schweer David Wire2323 Frederiksen Ct. 4719 Mortensen Rd Apt 307Ames, IA 50010 Ames, IA 50014512-736-8393 [email protected] [email protected] Engineering Computer Engineering

37


6.4 Closing Summary

Due to unsatisfying scores on standardized tests of third grade through sixth

students, an interactive software program called Mathematical Teaching System

Software was created. By implementing MTSS into the Ames Community

Schools, it will be easier for the students to visualize and solve mathematical

problems using correct problem solving techniques and method without the

assistantship of the teacher.

To achieve this, MTSS created a working software program that produces

mathematical problems for students in third grade through sixth. By using a

MySQL database to store math problems and student lockers, an interactive web

page allows students to view the problem at hand and check the correctness of

their answers. Giving teachers and administrator’s access to read/write

capabilities of the database they will be able to customize questions and

add/remove students from the program itself. They are also able to view the

scores and keep track of a student’s progress through the functions of the

gradebook.

To provide teachers with not only a great database of problems to quiz and test

their students, but with an aid to their teaching research for a problem solving

algorithm was conducted. The research involved determining what techniques

teachers use to teach their students how to solve problems, and what problem

solving techniques are widely used in areas other than mathematics. A general

model was developed and evaluation for implementation was conducted. When

complete this aspect of the project will provide teachers with a complete

mathematical teaching tool.

Having a strong approach and dedicated team members will make this software

a success. Carefully budgeting of time, money and constantly striving to

complete the proposed milestones are a few ways this project will be

38


accomplished. Keeping the clients informed on the status of the software is

another way to ensure the project’s success.

39


Appendix A

Screenshots of MTSS

Figure A.1: Main Page

Figure A.2: Home Page

40


Figure A.3: Register New User Page

Figure A.4: Problem Selection Page

41


Figure A.5a: Sample Problem 1

Figure A.5b: Problem Submission Page

42


Screenshots of Quizzing/Grading application

Figure A.6: Quiz Search Page

Figure A.7: Quiz GUI Page

43


Figure A.8: Quiz Grading Page

44


Appendix B

MTSS Wish List

Please note that the following are just recommendations. The actual feasibility

and implementation of each item is left to the discretion of future teams.

Problem Solving Algorithm

Create a simple but effective problem solving algorithm

Implement the algorithm into the software

The algorithm was able to help students improve their scores on the

national standardized test

Statistics

Display graphs of how a student is doing on problems, how a group

(class) is doing, etc

Record commonly made mistakes so that teachers can put them as

possible answer choices

Track date, time, user, problem(s) solved etc

User Administration

Implement a level of hierarchy of users such as administrator, principal,

student, and teachers.

Add/edit/delete groups such as classes

Add/edit/delete students to a group

Add/edit/delete teachers

Add/edit/delete principals

Problems

Have a way of saving problems so that a student can come back and work

on it later.

Have a set procedure that a student can follow along as they work out the

problem.

45


Dynamic problems – the same problem has different numeric values for

each student. The numbers should stay fixed if the same student logs on

later and tries to solve the same problem.

Allow creation of problem sets. This could serve as the set for a homework

and/or quiz. Ultimately students’ interaction with problems would be

through problem sets such as home-works or quizzes.

46


Appendix C

Problem Solving Algorithm Research

The Problem Solving Process

There are currently two problem solving models, outlined below. The first model

is used for mechanical, systematic, and abstract problems with correct answers

based on logical solutions. This model is a one iteration model, meaning that if

each step was done correctly, and the method for solving the problem was the

correct method, then the solver will only need to use each step once.

The second model is used for problems involving multiple steps where the solver

must reflect on past experiences, how those experiences apply to the problem,

and then act on a solution. The problems in the second model are simply too

complex to be solved in one iteration.

Problem Solving Models:

General Problem Solving Model (Bradford, 1984)

1. Identify the problem

Input: problem at hand

Output: an idea of what the problem is asking

2. Define the problem through thinking about it and sorting out the

relevant information

Input: problem at hand, student’s knowledge

Output: a detailed description of what the problem is asking,

information needed to solve the problem, skills needed to

solve the problem

3. Explore solutions through looking at alternatives, brainstorming

strategies, and checking different points of view

Input: problem at hand, student’s knowledge

Output: methods to solve the problem, one or more iterative

47


problem solving procedures

4. Act on the strategies

Input: problem at hand, student’s knowledge, output from

step 3

Output: solution(s) to the problem

5. Look back and evaluate the solution


step 4

Output: evaluation of the solution

Current Problem Solving Model (Gick, 1986)

1. Represent problem

Input: problem at hand, student’s knowledge, relevant

starting conditions

Output: the goal for the current iteration

2. Solution search


step 1

Output: a refinement of the goal, a plan of action to reach the

goal

3. Implement solution


step 2

Output: execution of the plan of action, evaluation of the

solutions to the goal

For the Mathematical Teach Software System, all the problems to be solved are

assumed to be the problems of the first type. These are the type of problems that

can be found on standardized exams, that is, logical problems that use an

iteration of a problem solving model.

It is important that we also assume the attitudes of the student or problem

48


solvers. The assumption is that they want to solve the problems, and they believe

that they can solve the problems. This assumption holds because these attitudes

affect how well a student is able to solve the problems.

In order to construct an algorithm based on the first model, there are several

things about the problem solver that has to be known.

What need to be known for each step1. Identify the problem

student’s ideas about the problem



student’s description of the problem in his or her own word

skills of the students (i.e. fractions, geometry, etc.) and the

relative expertise

what information about the problem is relevant



alternative methods for each problem

student’s strategies on solving the problem


student’s strategies on solving the problem

all possible correct strategies for solving the problem


student’s solution to the problem

correct solution(s) to the problem

For the first step, it is impossible to know the ideas of a student from an algorithm

stand point. Therefore, the first step will rely on assistance from the teacher.

In the second step, the algorithm, again, will need the teacher to verify the

49


student’s description of the problem. The skills of the student are something we

don’t know, but it is something that can be researched. Relevant information to

the problem can be programmed into the problem by the problem creator (i.e.

teacher). This step will require a change in the current framework.

To program the third step, all possible strategies for a particular problem, which

again can be programmed into by the problem creator has to be known. In order

to know the student’s strategies on solving a particular problem, some sort of

device which can check a student’s strategies against the possible strategies

would be needed. The nature of this device is not known right now, however, it

would be extremely complicated due to the complexity of comparing strategies. It

is one thing to compare two items, but to compare a sequence of items,

especially when two steps in the sequence can be interchanged, is not an easy

task.

The next step is similar to the previous step, requiring the knowledge all possible

correct strategies for solving a problem. This step is different than the last step

because the student must choose one of his or her strategies and act upon that

strategy. This step cannot be programmed into an algorithm simply because of

the nature of executing a strategy is rather complex. However, the results from

this action can be observe, and verify its correctness against the known solution.

In the final step, the algorithm will check whether the answer is correct. This is

probably the easiest step in the problem solving process because we only have

to compare two values.

Here is an example of how this algorithm might work for a simple problem:

“If Bill has $3.75 and that is 3/4 of the money that Mary has, then how much

money does Mary have?”

50


Solving the problem1. Identify the problem

find out how much money Mary has



let M = the money Mary has

what is M if $3.75 = 3/4 M?



divide both sides by 3/4

multiply both sides by 4/3



Did the student get M = $5.00?

In conclusion, the algorithm, if it can be computerized, must rely heavily on the

assistance of the teacher, whether in first creating problems or helping students

through the problem solving process. The reason it must rely on the mainly on

the teacher is because there is no way for an algorithm to know every possibly

strategy of any arbitrary problem, even the most simple problems. Referring back

to step 3 of the example, how would an algorithm know what the two strategies

are without input from the problem creator? It is also not clear whether the

problem creator himself or herself will know every possible strategy for a

particular problem, especially with more complicated problems. Since the

algorithm is so dependent on teacher’s assistance, it is important to discuss the

possible consequences of creating a problem solving algorithm with the teachers

themselves. How a teacher would respond to the new methods of problem

creation is needed to be known, and to the program having more reliance on him

or her.

51

Documents

K-12 Teaching Application Supportseniord.ece.iastate.edu/projects/archive/ongo08a/... · Web viewThe statistical analysis modules will provide invaluable insight to the teachers and