When it comes to educational assessments, student responses come in many more flavors than they did 10 years ago. As recently as 2005, the majority of educational assessments were performed on paper. Most test assessment activity involved students using #2 pencils to fill in bubbles and hand-write their responses. Educational assessment companies like Questar routed a combination of scanned optical mark recognition (OMR) data and actual student test papers to individuals for scoring. In fact, I remember the days when student documents were sent through a scanner a dozen times to separate their written responses and then packaged together for humans to read and score.
Today the market has shifted quite a bit. Paper-and-pencil-based assessments still exist, but that realm is rapidly being phased out in favor of computer-based testing (CBT).
Now that we are relying more heavily on technology to administer assessments, before the scoring of student responses can even begin, educational assessment providers and our clients need to make three key technology-related decisions about all of that technology-generated student data:
- Where is the data stored?
- Who can access the data?
- How will data flow in and out of interfaces?
Most businesses store their data in relational databases. Our industry is no different. Properly designed relational databases offer many advantages when implemented correctly. We gain huge back-office efficiencies for ourselves and our clients by normalizing data when and where we can, for all operational needs. So, now we know where the data is stored.
But who can access the data is a question that strikes to the heart of your security model. If you haven’t taken precautions yet to lock down your security model, begin that work immediately. Start with a frank discussion that includes your DBA and Architects. Topics like encryption, authorization, and privileges should be addressed in detail to try and discover your database platform weaknesses and remedy them as soon as possible. However, the best way to ensure that the database is as impenetrable as possible is to develop a security strategy before you build the database. Bottom line? All good database implementations start with a sound security model. Period. Entire books are written on the subject. To learn more, I’d recommend this document for Microsoft SQL Server.
Once you get that database locked down, you can address how data flows in and out of your databases and interfaces. Now student response data comes to educational assessment providers in many digital formats known by such acronyms as HTML, MP3, MP4, PNG, JPG, and TIF, to name just a few. Your state, district, or school may not hold or control the source of this data. For scoring purposes, application programming interfaces (APIs) must be created in a way that allows for the consistent and reliable flow of data in these formats.
Schools Interoperability Framework™ (SIF) offers some models to adopt when architecting your service layers and data models. I’ve found the StudentResponseSet and the StudentScoreSet to be beneficial in our data exchange needs. This model has many required elements and attributes, and presents the option to implement undefined elements where required. For example, how would you represent the amount of time measured in seconds that it takes a person to view and score a student response? Or incorporate some metadata, like an assigned human resource identifier, about the person performing the scoring? You can adopt the SIF_ExtendedElements part of the model to handle this data.
Exchanging student response data across layers and platforms and between business partners is a complex process that requires standards to ensure quality at every step. Every student’s response is important, and their educational career deserves the best we can give them as we score and report their assessments.