Time to Read: 3 MinutesComments
In previous entries, I discussed the primary functionality of the assessment system; the ability to collect information through components described as assessment instruments of which there are three varieties: Capture Hours, Attendance, and the most common, Standard. Besides the basic report that simply displays the standard instrument’s submission. One of the more popular reports in the old system was the instrument aggregate reports.
The instrument aggregate reports were an instrument-specific report that simply displayed the # of responses associated with a rubric choice for each indicator for a specific instrument. This report was generated based on either the academic year or academic term and a choice to view reports for responses on students for a specific program or all programs or a combination of both. Additionally, the percentage of responses to a specific indicator’s rubric choice was also available to better represent which rubric choices held the majority of responses.
Using this information, users can determine how large groups of students in specific programs for specific terms are scoring on specific indicators for a specific instrument. However, in the old system, since the structure of the instrument was different from instrument to instrument and each instrument had its own database table for its responses; each instrument also had its own aggregate report in its own source file that hard-coded the structure of the instrument to display with the report.
Also, these reports simply worked with Rubric type indicators with discrete rubric choices and did not include any Select or Number type components (as discussed in earlier entries when detailing the generalized structure of the Standard Instrument).
Once again, my plan was to make the following changes:
Make the report more robust. Given the way that I structured the response data in the new system. I wanted to expand upon the limited term, academic year, and program criteria for generating reports.
This new report would give the user more options to deduce trends and make credible judgments on the aggregate collection of data from various standard instruments. Adding a drill-down ability would add another layer allowing the user the ability to investigate the individual responses for a specific indicator based on the response value of that indicator. Additionally, the user could also view the overall performance on an instrument in relationship to those submissions where a specific response value was received for an indicator.
And best yet, there would be no need for a technical developer to add to the source of the system just to accommodate a newly created standard instrument.
This post is about the project, DREAM
An online electronic assessment system for the purpose of collecting assessment data regarding student teachers and counselors throughout their collegiate career. The system also electronically facilitates a large number of other institutional processes in an effective manner.
Software Developer Career Tips: Closing Thoughts
12 February, 2020
Fitness Series: Illnesses and Injuries, Make a Contingency Plan
03 February, 2020
Software Developer Career Tips: The System Design Phase
27 January, 2020
Software Developer Career Tips: The Technical Phase
21 January, 2020
Software Developer Career Tips: Do Your Preliminary Research
13 January, 2020
The Power of Habit
19 December, 2019
Rich Dad Poor Dad
14 October, 2019
19 August, 2019