SchoolTool Specification

This document describes the functionality we would like to add to SchoolTool. This document is of course subject to change. Currently, SchoolTool is vapourware, and the most important task we face is figuring out what functionality our first snapshot will contain. If you are a school administrator now is the time to help us figure that out.

Functionality Target for 1st Release

Metamodel of Courses and Resources. SchoolTool will need to capture data about the different courses that are taught at the school, as well as information about the teachers, classrooms and other relevant resources at the school. As far as possible it should be straightforward to correlate the subjects taught at the school with national curriculum for that country or type of school. The relationships between subjects should be flexible. For example, in some countries, all subjects are taught at the same level to a group of students (the 'standard' or 'grade'), and students progress through these 'grades' one year at a time. Repeating a year means repeating all the subjects in that year. In other countries, subjects can be taken at different levels by students in the same year of study. So, for example, a student might take math at a hgiher level of instruction than physics. In these cases, registration in a course will have specific requirements that need to be enforced. We will support at least the UK, USA and South African models:

• ZA: constant 'grade' with different subjects all taken at the same 'year' of study, failure means the entire year is repeated. One classroom would typically have students of the same age. NB: in smaller schools it may happen that a single teacher is teaching multiple age groups at the same time.
• US: subjects can be taken at different speeds to different levels in different years. So 'Maths - Calculus' might have people from different age groups / years at school.
• UK: Similar to South Africa: subjects are offered in a grade and students take all their subjects at the same grade.

It should be quick to configure to a typical case... perhaps we will make it possible to download and install templates for different countries, or provide wizards that walk through the setup process, especially where there is a standard national curriculum. We will provide a central web based repository of these templates or wizards, so that schools can leverage work done by others.

Student and Staff Mobility. SchoolTool will make it easy for student data to be moved from one school to another when the student moves schools. It will support government standards for student data (import and export) where these exist. It will also have a rich native data exchange format that will capture as much data as possible.

• Question: how does one handle data movements within the system? e.g. pupil moves from one school to another where their pedagogical organisation is fundamentally different? How much data would move? Perhaps handle as 'human-readable data transfer' that does not pretend to be fullly 'active' data transfer. In other words, we don't expect to be able to know all the test results a student had in a subject that was taught at his old school but not at the new one... just the final result, perhaps.

Group Memberships Model. Schools are often defined in terms of groups of students. For example:

• Courses and classes
• Clubs and societies
• Houses
• Sports Teams

Students, staff members, parents, administrators and other people may be members of many different groups. SchoolTool should model the structure of the school in an efficient manner. It should be possible to find a group quickly through the web or SchoolTool client interface, and then take some meaningful action on that group. For example, send all members of the group a message, or assign some work to them, or find a time when they are all available for an activity. Different kinds of groups might support different types of workflows or events (for example, if a student fails a test, that might generate an alert or event for that student which might be routed to his housemaster).

In particular, the group membership system will be connected to the calendar system. Each group can maintain its own calendar, and group events are automatically shown in the personal calendar of any member of the group. So, for example, each of the members of a sports team will automatically see their training practice times, as well as match times and locations, in their calendars.

Again, we want it to be easy to setup the SchoolTool instance, so there would typically be a wizard that helps with the initial creation of most of the group structure of the school.

• Story: Model the organisation of the school into 'houses' or other groupings, and establish workflows of reporting, messaging, calendaring or other aspects of school life. For example, at Bishops, there would be a House calendar layered on top of the school calendar layered on top of club / team calendars layered on top of the personal calendar of the individual. Allow for automatic configuration of the individual's setup so that relevant information is drawn into their SchoolTool presence.

Calendaring Functionality. A core part of SchoolTool will be its support for calendaring functions. The calendar is slightly distinct from SchoolTool's support for timetabling, although the two are of course linked. Each person in the SchoolTool system, and each group, can have its own calendar. Timetabled events that affect that person or group would also show up in the calendar, but the main purpose of the calendar is to allow individuals and groups to map out and manage their time. Initially, the calendar will be rendered in HTML and displayed over the web.

Timetabling. The critical part of the academic organisation of the school is the school timetable. This determines how effectively teachers and classrooms are utilised. A well-designed timetable will give students the maximum choice of subjects, while keeping teachers and classrooms optimally employed but still making sure there is time for other activities and that subject classes are well balanced through the week. SchoolTool will support the creation and maintenance of an effective school timetable.

SchoolTool must support different kinds of timetables: core academic timetables, sports team training timetables, and exam timetables. It should be possible to use SchoolTool to try to improve an existing timetable. The first release of SchoolTool will only support the importing and manual editing of existing timetables that have been manually created by school administrators.

SchoolTool timetables will be integrated with the SchoolTool calendaring system, so that timetabled events automatically show up in the calendars of the people involved. For example, as soon as the exam timetable is finalised, the relevant information will show up in the personal calendar of any student writing exams.

It should be possible to view the timetable / calendar for a resource as well as a person. In other words, we should quickly be able to see when a classroom or a shared laptop computer or a shared projector is in use, or find a time when it will be available.

The timetable system will be aware of typical resource management approaches. For example, in some schools the students stay in a particular classroom throughout the day, and teachers move from class to class. In other schools, a classroom 'belongs' to a teacher, and groups of students move around from class to class between school periods. Also, different schools have different definitions of the work cycle - some use a 10 day cycle, others use a 5 day cycle. SchoolTool will need to make it easy to setup different timetables and then to optimise the use of resources given those contraints.

SchoolTool will need to support the following in its first release:

• Attractive timetable printouts in a variety of sizes.
• Export of timetables to HTML or Word for presentation purposes.
• A generic API for timetabling services and storage, that can be used by extension programmers to support additional kinds of timetables.

Test Results Tracking. Student performance evaluation is an important part of school life, and is also a significant contributor to the admin burden that teachers carry. SchoolTool will provide a central repository for test results, ensuring that teachers only ever have to capture this data once. Schooltool will need to allow different kinds of test 'result': e.g. A/B/C..F, 0-100%, x/y, ordinal ranking, pass/fail. SchoolTool will also have to make it possible to produce an aggregate course result from these diverse test results. The important thing will be to ensure that the data does not have to be captured and re-captured.

SchoolTool will treat test results as sensitive information and it will be possible to publish them only in a controlled fashion. Students will have access to their own test results, as will their parents and teachers. In many schools today test results are openly published, and SchoolTool will support this transparency if desired.

SchoolTool will not only reduce the amount of work required by teachers tracking test scores, it will also support workflows related to testing and test results. For example, if a test result highlights a particular problem it will be easy for a teacher to flag that result for the attention of staff responsible for the student in question.

It will be possible to amend results once they have been captured in the SchoolTool database, but this will be done in a carefully controlled and auditable manner to ensure that amendments cannot be abused by staff or students. It will be possible to generate effective fraud management reports based on audit logs of amendments to test results in the system. It will also be possible to search for evidence of plagiarism in test result patterns.

Tracking Absenteeism. SchoolTool will make it simple to keep an accurate record of absenteeism and tardiness at a school. Where teachers have access to computers in the classroom this information can be captured directly, otherwise it will be captured by administrative staff on a daily basis. If action needs to be taken SchoolTool will automate as much as possible: for example, housemasters might see a 'hotlist' of students in their house who have been flagged as absent or late from a class that appear in a window on their desktop or web portal page. Also, parents might receive an automatic alert, such as an instant message or SMS text message to their cellphone notifying them if one of their children is marked absent for a class.

Student and Staff Registration. One of the most admin-intensive periods in the academic year is the start: student and staff registration. SchoolTool aims to streamline and simplify this process. SchoolTool is fully integrated: it will only be necessary to capture information about a given student once. Where possible and desireable, students will handle their own selection of courses, and SchoolTool will simply enforce pre-established course requirements. Alternatively, SchoolTool will make it easy to promote grades of students who have successfully completed their studies and simplify their enrollment in the following year's study.

SchoolTool will make it straightforward to change the registration details of students after the year has begun, and will also automatically add students to relevant groups.

User Interface. SchoolTool will support a variety of user interfaces. The basic mode of operation will use a direct web interface. This allows SchoolTool to be setup and administered remotely. However, a web interface is not a good platform for large-scale data capture, and a web interface can't interact with local devices such as bar code scanners, so there is a need for a 'fat' client for SchoolTool as well. This 'fat' client will have a richer interface than the web based interface, and will support more functionality.

Network API. The SchoolTool client will communicate with the SchoolTool server using a network API (such as CORBA or XML-RPC or SOAP) that can be used independently of the SchoolTool client, by third-party software developers. In addition, we expect that custom applications for PDA's and laptops will also use the network API to support specific functions such as abseenteeism tracking or test result data capture.

Web Portal Interface. In addition to the web administration interface and SchoolTool client, we will support adapters for commonly used Portal Toolkits such as Zope and PHP-Nuke. These will make it simple to include SchoolTool data, such as timetables, calendars, work assignments and test results, in school portal web sites.

Systems Management. Typically, SchoolTool will be deployed with a dedicated physical server. It may also be possible to deploy multiple 'virtual' servers on a single physical server, so that data centers could maximise the number of schools they can service without having to deploy a real physical server for each school. Similarly, the SchoolTool client will be able to switch from school to school, allowing a teacher or administrator to work with data from multiple schools from a single laptop or desktop computer. In the first release of SchoolTool, data will be stored in a single file, and backing up the SchoolTool instance will require backing up that file. It may require server downtime while the backup is in progress.

Regulatory Compliance. Schools across the globe are subject to national and local regulation. They have to produce reports and track specific information, and protect sensitive data. In many cases schools have regulatory compliance requirements that are quite different from schools close by. For example, independent schools often follow different rules from state schools. And of course these rules can vary widely from country to country. SchoolTool will need to ensure compliance with local regulation. In the initial release we hope to support the regulatory environments of South Africa, the UK and at least some states in the USA.

Subsequent Releases:

Our vision of SchoolTool maps out a long term picture of how we hope the software will evolve. It will need much more functionality than we envisage being able to deliver in the first release. Here are some additional features that we would like to inlcude in SchoolTool over time:

Calendaring. SchoolTool should be able to publish school, group and personal calendars using internet standard protocols such as ICS and ICAP. This will allow parents at home or in the office to subscribe to their children's calendars and see a unified view of their own calendars and those of their family members. It will also allow calendars to be published and shared between schools. For example, a society in one school could invite students from other local schools to participate in society events, and publish the relevant calendar to those 'foreign' members automatically. SchoolTool will need to make it easy for people to subscribe to these calendars and show a merged view of the year, month or day planner.

Timetabling. The first release of SchoolTool will likely only support the manual editing and creation of timetables. In subsequent releases we will try to add 'intelligent' support for timetable optimisation and creation. For example, we might offer the use of genetic algorithms to improve an existing timetable, or create a brand new timetable from scratch. The user interface requirement of this functionality are challenging to implement, but it will make a tremendous difference, particularly in developing countries, if we can improve the process of timetable creation.

A significant indicator of school efficiency is the timetabling process. We hope that SchoolTool will enable regional, provincial and national education administrators to identify schools with poor timetables and poor management early on in the school year, so that they can deploy supporting resources to those schools and communities.

Test Results Tracking.

• Test result alerts and messages: Send alerts to parents / housemasters / headmaster etc if test results meet specific criteria or show significant change.
• Allow for import / export of results, specifically into OpenOffice / Excel, and allow for 'checking out, editing/manipulating, then checking in' results sets using Excel.
• Allow for curve-based weighting of results
• Provide an audit trail of results changed over time

Common Administrative Procedures.

• Discipline-related admin

Report Card Functionality.

• Streamline writing of reports (annual / biannual etc)
• Support import / export to and from major pckages... Word, PDF
• Include workflow functionality, for example: teachers -> housemasters -> headmaster
• Include automatic report writing tools (colour-by-numbers). Need to see what the state of the art is and do better.
• Include disciplinary elements in reports... absenteeism, sanction (demerits / punishment).
• Parents should be able to see a snapshot of their child's relative academic performance as well as disciplinary information.

Workflow System. SchoolTool will need to create a workflow management system. This may or may not be built on top of existing Content Management Services frameworks such as Zope-CMF. For example, if a disciplinary process is initiated then that report would need to be review, commented on and edited by a sequence of people based on the school structure, before action was taken based on the report. It should be possible for the school to cusomtise these workflows as well as easily setting up standard processes.

Another example might be annual or bi-annual report writing. At the end of term, teachers would automatically see TODO lists of reports that need to be written for the students they teach. These reports would then be consolidated for review by housemasters, and once they had completed their work, could be reviewed by the headmaster for his comments before being sent to parents and the students themselves.

It should be possible for the school to define these workflow patterns, basing them on the particular structure of the school itself.

This same workflow system might underpin electronic assignments for students. When an assignment is given to students they might use the workflow system to submit their response or paper or project, which would then be queued for review by staff or tutors, again depending on the particular structure and operational style of the school.

Messaging System. SchoolTool might expand to include an internal messaging system. Ideally, this would encompass a variety of messaging technologies, such as: email, snail mail (reports and letters that might be printed and mailed), instant messaging, SMS text messaging and paging. Individuals would be able to set their preferences for how they might be contacted under different circumstances.

An example use of this infrastructure might be anotifications of absenteeism. If a teacher marked a student as absent from a class, a notification message might be sent to his housemaster. The housemaster might know why that student was away and thus 'clear' the alert, but if not, or if no response was received from the housemaster, then SchoolTool could automatically send a text SMS message or page to the parents of the student.

Similarly, a strong unified messaging system would facilitate workflows and communication within the school community. For example, if a student was performing consitently poorly, or if a student's performance in class change suddenly in either direction, a notification of that might be sent to responsible individuals who could then decide what action was appropriate.

The messaging system could be a platform on top of which alarms, calendar and timetable events, homework assignments, reports, emergency messages and so on are all handled.

Management Reporting. SchoolTool should make it easier for school administrators, staff and district / regional administrators to have a sense of the status of the school. Performance outliers and attendance outliers should be easily and quickly identifiable. It should be possible to identify students that need extra support, and it should also be possible to identify whole communities that have systemic need for additional social welfare support.

Testing & Student Performance Measurement. SchoolTool is not a 'computer based training' platform. We do not aim to host training content, although it is possible that this might fit within the SchoolTool framework at a later stage. We do not envisage students 'learning' in the SchoolTool application. It is an administrative framework. However, there is some interaction between the learning process and SchoolTool, because SchoolTool will most definitely support the acpturing of test results. We will want to minimise the amount of time teachers spend on data capture, so it would be sensible to allow computer-based testing software to interface directly with SchoolTool, and deliver test result data straight to the system.

It's likely that this will be done through the SchoolTool Network API. We should ensure that SchoolTool complies with existing standards for computer-based testing products, such as LCMS standards. SchoolTool should also possibly be made compliant with other learning-related standards such as SCORM.

If SchoolTool does grow to allow for the direct capture of test results and possibly test answers, then it would be useful if SchoolTool could automatically check for signs of plagiarism.

Accreditation Management. Qualification fraud is a growing problem in the recruitment industry. A very high proportion of degrees and other qualifications claimed on Curriculum Vitae documents turn out to be fraudulent. The verification of these details is time-consuming and expensive. It would be very useful if SchoolTool were able to support the automatic verification of degrees and qualifications earned by graduates of the school. This could take the form of published digitally signed 'qualification certificates' in XML format, or a web service to validate the details of graduates from the institution.

Financials. If SchoolTool is to be a complete solution for schools and colleges then it will need to address financial management as well as operational functionality. There are already many open source financial packages of varying quality and functionality: GnuCash and SQL-Ledger, for example. It is not clear how best we could extend SchoolTool to address financial management, or incorporate / interface with these existing applications, but this will need to be addressed eventually.

Areas of financial management that would need to be addressed include:

• Fees and payments, other income, school expenditure, and budgeting
• Payroll management
• Asset tracking - keep track of desks, chairs, computers, projectors, blackboards etc.
• Procurement and supply chain management

Offline Use By Staff. As the SchoolTool client becomes more sophisticated it is more and more likely that teachers will want to use it when they are not actually connected to the school network. For example, they may be marking papers at home and wish to capture the student marks directly into the SchoolTool system. To supoprt this, we envisage that the SchoolTool client will support online / offline use, with data syncronisation occuring when the client is reconnected to the server. We imagine that this would include test result capture, tracking of attendance, report writing and other core administrative duties for teachers.

Extra Modules. There are several areas that SchoolTool might expand into, or where we might integrate existing open source solutions into the SchoolTool framework:

• Library management
• Cafeteria management
• Groundskeeping

Extensibility or Component Architecture. Without doubt, other organisations will want to extend SchoolTool. The system will need a flexible but robust mechanism for extension. This might take the form of subclassing, or extension through a component interface.

Replication. The first release of SchoolTool will allow simple backing up of the database by backing up a single file on the SchoolTool server. Future releases might support online replication of the data from one server to another, so that changes to the database on the main server automatically also migrate to the backup server. This would allow for failover support, where a second computer could take over from the prime SchoolTool server if a hardware failure or other problem took it offline. We may also be able to support load balancing, where multiple servers appear to be a single server, and share the load between them. This would be particularly helpful if SchoolTool reaches the point where it is deployed in very lrge institutions.

Support PDA's. The first version of SchoolTool will have a web interface and a desktop client interface, as well as a Netwok API. We expect that later versions of SchoolTool will include custom applications for a variety of Personal Digital Assistants (PDA's) that will provide useful interfaces to specific functionality such as attendance tracking and test result data capture. These applications are likely to be 'mobile' in the sense that the data is best captured 'in the field', where a PDA is more likely to be in use than a laptop of desktop computer.

It would be necessary to work with broad range of PDA's and PDA operating systems, including:

• Palm OS
• Windows CE
• Symbian
• Linux

Security Enhancements. The first version of SchoolTool will have a very simple access control and security framework in place. Over time, this framework could be expanded to include support for:

• Digital signatures and certificates for pupils, staff, parents
• Smartcard / biometric awareness