Early Warning System for Identifying students at risk of failingRoger BrownCenter for Educational TechnologyUniversity of Cape Townroger.brown@uct.ac.za
OverviewPART 1Why we started looking at EWSThe functional requirements of the systemInstitutional fitMatching Vula (Sakai) affordances to the functional requirementsDevelopments that would allow Sakai to act as an EWS (well some of them anyway!)How UCT is moving forwardPART 2 - DiscussionActivity and course gradeYour ideas12th Sakai Conference – Los Angeles, California – June 14-162
Part1: IntroductionIn 2009 Senate Re-admission Review Committee recommended that greater attention needed to be given to Faculty EWS.  The SRRC report recommended that:the SRRC monitors data from the Faculty EWS with the aim of assessing and reporting on the impact mid-year exclusions have on throughput rates, and 	Investigate the EWS issue to assess the most effective approach to adopt a single system thereby providing consistency across faculties.
EWS – Functional requirementsThe ability to record a standard number of “in course”results/performance/gradeThe ability to create a current class list of all valid registered students in a course, populate this list with “in course results”, and load these to the students’ PeopleSoft record.Specification of an “at risk” threshold value for these resultsRecording of comments against a studentGeneration of communication to identified students Retentions of a permanent record of these communicationsSpecified reporting of student performanceFor a student within a course across all coursesFor a specified cohort of studentsAccess and authorisations to entry grades, viewing of grades and running of reports, course conveners and/or mentors and/or other “intervention” managers
EWS – Institutional criteriaTechnical ImplementationTechnical IntegrationUsability and User Support RequirementsTechnical SupportSecurity and AuthorisationsStudent AccessOverall Reporting CapacityCost (of licensing, implementation and support)Vendor and Product Sustainability
EWS Functional requirements and Vula (Sakai 2.7) - IntegrationPeopleSoftHEDA - Higher Education Data Analyzer Demographic and  K12 data (currently used by IPD)IDvault
Vula: Affordances vs RequirementsGroups: Easily created and populatedConfigurable Roles: Accessand authorityGradebook
Vula: Affordances vs RequirementsCommunication: EmailInternal messageSMS Secure
 Familiar
 Widely accepted by admin/academic staff  (2474 staff used Vula in 2010)Vula: Affordances vs Requirements -Gradebook1. Import marks from excel3. Integrates with Vula testing tools2. Weighting and Categories
Assessing students at risk?Back to My WorkspaceOut of Gradebook
Vula: Limitations (currently)“At Risk” assessment would need to be done outside VulaNot all lecturers/course convenors use VulaVula is not the authoritative source of marksVula does not “push” data to PSStaffing
Vula: R&D for EWS applicationAutomated Gradebook export to ETL platform or preferably an internal logicInternal or external algorithm development for risk analysisAuto grouping based on risk analysisReporting communications, display, etc Predictive logic based on previous student performance
How UCT is moving forwardThe task team recommended in phase 1EWS to utilise the functionality of PeopleSoft (some developments required)Improve the integration of Sakai and PS gradebook export to PS (it’s easier to get grades into GB than into PS )Samigo& Asn => GB => PS12th Sakai Conference – Los Angeles, California – June 14-1613
Part 2: Vula: Final grade vs all events (PSY1001W)

Sakai la-ewsv2

  • 1.
    Early Warning Systemfor Identifying students at risk of failingRoger BrownCenter for Educational TechnologyUniversity of Cape Townroger.brown@uct.ac.za
  • 2.
    OverviewPART 1Why westarted looking at EWSThe functional requirements of the systemInstitutional fitMatching Vula (Sakai) affordances to the functional requirementsDevelopments that would allow Sakai to act as an EWS (well some of them anyway!)How UCT is moving forwardPART 2 - DiscussionActivity and course gradeYour ideas12th Sakai Conference – Los Angeles, California – June 14-162
  • 3.
    Part1: IntroductionIn 2009Senate Re-admission Review Committee recommended that greater attention needed to be given to Faculty EWS. The SRRC report recommended that:the SRRC monitors data from the Faculty EWS with the aim of assessing and reporting on the impact mid-year exclusions have on throughput rates, and Investigate the EWS issue to assess the most effective approach to adopt a single system thereby providing consistency across faculties.
  • 4.
    EWS – FunctionalrequirementsThe ability to record a standard number of “in course”results/performance/gradeThe ability to create a current class list of all valid registered students in a course, populate this list with “in course results”, and load these to the students’ PeopleSoft record.Specification of an “at risk” threshold value for these resultsRecording of comments against a studentGeneration of communication to identified students Retentions of a permanent record of these communicationsSpecified reporting of student performanceFor a student within a course across all coursesFor a specified cohort of studentsAccess and authorisations to entry grades, viewing of grades and running of reports, course conveners and/or mentors and/or other “intervention” managers
  • 5.
    EWS – InstitutionalcriteriaTechnical ImplementationTechnical IntegrationUsability and User Support RequirementsTechnical SupportSecurity and AuthorisationsStudent AccessOverall Reporting CapacityCost (of licensing, implementation and support)Vendor and Product Sustainability
  • 6.
    EWS Functional requirementsand Vula (Sakai 2.7) - IntegrationPeopleSoftHEDA - Higher Education Data Analyzer Demographic and K12 data (currently used by IPD)IDvault
  • 7.
    Vula: Affordances vsRequirementsGroups: Easily created and populatedConfigurable Roles: Accessand authorityGradebook
  • 8.
    Vula: Affordances vsRequirementsCommunication: EmailInternal messageSMS Secure
  • 9.
  • 10.
    Widely acceptedby admin/academic staff (2474 staff used Vula in 2010)Vula: Affordances vs Requirements -Gradebook1. Import marks from excel3. Integrates with Vula testing tools2. Weighting and Categories
  • 11.
    Assessing students atrisk?Back to My WorkspaceOut of Gradebook
  • 12.
    Vula: Limitations (currently)“AtRisk” assessment would need to be done outside VulaNot all lecturers/course convenors use VulaVula is not the authoritative source of marksVula does not “push” data to PSStaffing
  • 13.
    Vula: R&D forEWS applicationAutomated Gradebook export to ETL platform or preferably an internal logicInternal or external algorithm development for risk analysisAuto grouping based on risk analysisReporting communications, display, etc Predictive logic based on previous student performance
  • 14.
    How UCT ismoving forwardThe task team recommended in phase 1EWS to utilise the functionality of PeopleSoft (some developments required)Improve the integration of Sakai and PS gradebook export to PS (it’s easier to get grades into GB than into PS )Samigo& Asn => GB => PS12th Sakai Conference – Los Angeles, California – June 14-1613
  • 15.
    Part 2: Vula:Final grade vs all events (PSY1001W)