OSIMS

When designing the student data I made the unusual choice not to include the student’s gender in the student table.  While the information may be useful for identifying students it really only narrows the field by roughly 50% and I think there are more useful ways to track the information.

Aggregating / Disaggregating Student Assessment Data

When analyzing student assessment data we often look at the aggregate, or combined, data for a school.  What percentage of the students in the school proved they understood the concepts they’re expected to know at their grade level?  It might then be useful to look at how well different groups are learning the material.  Do the girls seem to be doing better at math than the boys?  We call  this disaggregated data.  Truthfully it’s information that’s still “aggregated” but at a finer level than the whole school.

In order to allow for the maximum flexibility, I want to create one method for aggregating and disaggregating students that can be used in many different scenarios.  I’m going to do this by creating “groups” into which students can be assigned.  An individual student can be a member of many groups at the same time, and each group can then be used to aggregate the data.

Virtually anything can be a group of students. Some possible example groups are:

• Male/Female
• School
• Grade
• Teacher
• Ethnicity
• Native Language
• Football Team
• Needs Additional Tutoring

Having the ability to create such diverse groups will allow educators to track the performance of many different student populations and the effects of instructional programs.  Teachers will be able to use any number of groups when drawing reports.  By specifying multiple groups, extremely targeted information can be attained.  Perhaps we want to know the effects of a new textbook on Russian speaking students in Aardvark Elementary school as compared to their English speaking peers.  Trust me, that type of information can be difficult to determine in many of the systems that educators are currently using.  We’ll be simplifying that to a few clicks of the mouse.

Types of Groups

For many reasons it makes sense to define types of groups.

The first is for clarity and organization.  The Male and Female groups are both Genders and should be a separate field from the Caucasian, Hispanic, and African American groups in the user interface.

The second reason is that some groups should be mutually exclusive and some should not.  Students shouldn’t be able to fall into two different gender groups, but they might fall into a couple different ethnicity groups.

The third reason is to make some required.  When adding a new student to the system, it might be wise to force school staff to enter the student’s gender and ethnicity, but they students don’t have to be required to have an after-school activity.

User Defined Groups

In addition to information that is tracked through the formal existing data systems, teachers sometimes need to track small informal groups of students.  Maybe the teacher has identified a few struggling students and is giving them additional tutoring.  It would be nice to be able to show those students to their peers.  Allowing all users of the system to create their own private groups gives the greatest amount of utility.  Each user can track exactly the type of information they wish to see.

Access Control

When it comes to student-by-student information, teachers generally only need to see the information for the students in their class.  In OSIMS the teacher’s class will exist as a group with students assigned to it and we’ll simply allow the teacher access to that group.  Similarly, Principals will have access to their school’s group, and specialists might have access to the Special Education group within a school.

By assigning students to groups, and allowing aggregation on any number of groups, OSIMS will give educators an unprecedented ability to monitor the progress of students.

Filed under:
Uncategorized by Brian Bain