The applications described above can be split into open source (Moodle, uPortal) and closed source (ANGEL, Learn, WebCT) projects. Further, while most are generic ap- plications which do not target specific institutions, a few (Bodington, BOSS) are in-house applications tailored more closely to the institution where they have been developed. MMS’ licensing model is currently effectively closed source (copyright retained by the University of St Andrews), although permission is being sought in order to release the code.
Open source projects have the advantage for the user that they can inspect the code before committing to deploying the application, enabling them to assess in depth its suitability, and any issues arising can (in theory) be addressed by the end user without referring back to the publisher. In my experience there is often a lack of resources available to make significant changes to open source software deployed within an institution, however at least the option is available.
By comparison closed source projects are typically better resourced, with full time devel- oper teams working on the code, however leave the customer dependent upon the publisher for updates and support. Historically closed source projects have often been better sup- ported, although it is now common for open source projects to be available with paid sup- port. Moodle Pty offer paid support for Moodle, and there are number of service providers for support for uPortal.
For staff at St Andrews, MMS blends open and closed source models, in that the source code is not readily available however the scripts used to implement academic policy (dis- cussed in detail in section 7.6) are exposed to staff who are encouraged to review them to ensure accuracy of implementation.
MMS has been developed an in-house application tailored to systems and processes in use at St Andrews, which limits the application, and it could not readily be used at other insti- tutions, although the institution abstraction layer (5.11) is intended specifically to enable such extension/replacement of functionality to support other institutions.
Chapter 3
Challenges
This chapter will expands on the design, adoption and support challenges addressed by the MMS project, focusing on the underlying causes. This work provides a basis for later chapters, which describe the solutions developed.
Wilson[137] and Yuan et al[140] examine the suitability of existing standards processes for use in a higher education context, and describe community-led informal processes which better suit the requirements of higher education software development. This provides con- text for higher education specific requirements and challenges.
Software design for higher education administration requires the architect to overcome a number of challenges specific to the sector, which are often overlooked, understated or/and misunderstood. Many of these have become apparent as MMS has been rolled out across the institution, both from the researchers’ own experiences using the system or from user feedback. These challenges include:
• Higher education teaching across different faculties is not a uniform process[107], and as such administrative tasks in relation to teaching are not uniform either. For example, Computer Science at St Andrews typically has weekly assessed work to be submitted by students, while English may have just one or two more substantial essays to be submitted for each taught module. In cases such as Chemistry submit- ted work may take the form of the results of an experiment, with no digital assets submitted (this is especially true where work is recorded in lab books).
• Teaching and administration may also vary by intended degree award, such as BSc, MSc, PhD, etc. Taught degrees tend to have similar requirements, however research degrees are substantially different with cross-year deadlines, no grading process of work (instead students are typically assessed with relation to whether and how their degree should proceed). Notably these variations interact with per-subject differ- ences, vastly increasing the number of possible process combinations. Portfolio- based degrees such as D.Eng add further complication.
• Processes also vary by attendance style; part-time, evening degree and distance learn- ing students also have their own subtle differences in process requirements. Students, especially those attending as part of a semester-abroad programme, may have exemp- tions and exceptions made, such as essay-based assessment in place of final exams.
• Exceptions to normal process are extremely common, for reasons including (but not limited to) personal circumstances of a student, additional support required due to disabilities, or even to correct earlier procedural errors. Examples of exceptions in- clude extensions to deadlines, exemption from pieces of work, changes to grades awarded and course material only made available to a subset of students on a course (such as notes in alternative formats).
• Higher education institutions can reasonably be expected to be innovative in their processes. This innovation leads to demand for support of rapid changes in require- ments.
• External organisations can impose requirement changes on institutions, forcing pro- cess changes and technical requirements which are difficult to predict ahead of time. Consider the examples of introduction of attendance reporting to the UKBA for over- seas students[88][127], or the suggestions of UCAS switching to admissions decision making after exam results are issued[114].
These challenges are also important to consider in terms of acceptance of new software by staff. Schneckenberg describes how lack of staff engagement can be a barrier to adoption of e-learning in higher education[116], and many of the same principles apply to adoption of software for managing administrative tasks. It is important that staff see value of new software[26] to themselves, as well as to the institution, if they are to invest effort in the adoption of that software.
3.1
Process Complexity
As a further consequence of these challenges, systems tend to be highly complex, and accordingly ensuring processes are implemented correctly is a challenge.
For software architects anticipating a more homogeneous, stable organisation, these chal- lenges can be a cause of significant complications in the software development process, especially if they are not effectively managed at an early stage in the design.
3.1.1
School and Subject
In his 1976 work Weick illustrates the complex interactions of educational organisational elements, describing the result as “loosely coupled systems”[132]. This loose coupling means that organisational elements (such as academic schools, or taught subjects) have a significant degree of autonomy. This leads to greater flexibility in terms of introducing process differences at the school or subject level than might otherwise be expected of a single large organisation. It should also be noted that universities are large and diverse employers, with staff headcounts around the 1,000 to 10,000 range, and heavily split not just by role but also by subject.
These differences manifest in a number of ways, ranging from obvious differences such as assessment process, to almost trivial differences such as policy on when to round during calculation of final grades. It is outside the remit of one academic school to define pro- cess upon another, it is obvious that understanding and supporting these differences was a requirement for MMS, given its development within the School of Computer Science.
3.1.2
Intended Award
While there are related themes in administration of taught and research degrees, it should be obvious that such degree types do have significant differences. Taught subjects in general include a number of points during the academic year where students are assessed on what they have learnt, whereas research students generally have a more supervision-orientated process. There are clearly similarities, however intent and outcomes differ.
This form of subtle difference is typical. Other differences include processes for progres- sion of students, such as confirming sub-honours students can progress on to honours, or M.Phil students can progress on to a PhD.
These differences interact with school and subject differences, substantially increasing the number of possible combinations. For example, undergraduate Medicine has different pro- cesses to both postgraduate Medicine and undergraduate Philosophy.
3.1.3
Mode of Attendance
The last potential complicating factor with institutional processes is mode of attendance. Distance learning, part-time, semester/year abroad and evening-degree students can all have their own requirements in relation to standard processes, especially as such degree courses can run substantially outside the normal academic year. Examples include:
• Distance learning students may require additional support, particularly in terms of feeling involved with their institution and other students, which technology is well placed to assist with[86].
• Semester abroad students may be required to complete alternative assessments in place of end of semester exams, where such exams occur after the students are ex- pected to have returned home.
• Part-time research students generally have different assessment requirements to re- flect that their progress is at a different rate.
• Part-time taught students may be taught across multiple calendar years, meaning their modules have extremely unusual requirements in terms of both availability to students, and reporting deadlines.