- LTEO

Picture of Students
rss picture LTEO News
External News [What is RSS?]

AddThis Social Bookmark Button

Moodle Development Plan 2010

 

Introduction

The aim of this document is twofold. First, it is to state the Moodle development priorities for the 2010 academic year, thereby giving the university community a clearer idea of the development priorities over the coming months. Second, it is to continue a process of giving the university community an opportunity to be consulted about developments. The e-Learning Operational Plan 2009-20112, published in April 2009, stated that “currently staff do not feel involved in the process of e-learning software development and provision”. Indeed, Action (A13) of this plan was to Develop the Moodle Development Plan for 2009/10.

 

Methodology

In October and November 2009, the e-Learning team identified a range of Moodle development projects that might need to be completed during the 2010 academic year. These projects were informed by the requirement of the e-Learning team to support a reliable, robust and scable Moodle service, as well as some informal conversations that had already taken place with staff about the notion of shaping a development plan. The projects identified appear in Appendix 1.

Once this initial plan was developed, it was discussed at a wider e-Learning Team meeting, which includes e-learning officers in Departments of Education and Economics, the Faculty of Engineering as well as the Division for Lifelong Learning.

Following further refinement, the plan was presented at the Moodle Advisory Group3 meeting in December 2009. The group prioritised related tasks using the MoSCoW technique. Additionally, weightings were applied to aid further prioritisation. The tasks are reproduced in Table 1.

Developments (Total) Weighting from MoSCoW (M =4,
S = 3, C =2, W = 1)		 Impact on: all (3), some (2), few (1) Priority: high (3), medium (2), low (1) Time taken: short (3), medium (2), long (1) TOTAL (multiply column totals
together)
1.2 Moving Moodle 'log tables' 4+2+2+4 = 12 3 3 2 216
1.3. Moodle housekeeping 4+4+3 = 11 3 3 2 196
1.1 Single Sign On 2+2+2+4 = 10 3 2 3 180
2.1 Integration with Turnitin [on moodle-test server] 2+3+2+3 = 10 2 2 3 180
1.4 Developing SOOT 3+4+4+2 = 13 2 3 2 156
2.3 Evaluating Moodle 2.0 on test server [Phase 1] 4+4+4+4 = 16 3 2 1 96
2.4 e-assessment related staff development 3+3+4+2 = 12 2 2 1 96
           
1.5 Developing the Moodle-SAMIS functionality 4+4+4+2 = 14 2 2 1 56
2.2 Questionnaire software 1+2+2+3 = 8 3 1 2 48
2.5 SAMIS Applicant database 1+4+3+4 = 12 1 1 1 12

Table 1: Moodle Development Plan 2010 MoSCoW prioritises [ordered by Total]

A line was drawn through the table to indicate the seven tasks that will receive highest prioritisation over the project plan period. These are the tasks that the e-Learning team plan to deliver during the stated time period. There has been a key emphasis in the prioritised tasks on service performance improvement related projects.

During the project schedule that follows, both resource constraints and the following essential projects have been considered:

[The 3.x references above correspond to tasks which appear in the Gantt Chart in Appendix 2].

 

Project Schedule

Following the MoSCoW prioritisation activity and the application of weightings, and further discussion of the plan by the Moodle Operational Team, the following project schedule has been developed. Further items have also been included as appropriate.

Developments Category Schedule
1.2 Moving Moodle 'log tables' ESP April – June 2010
1.3. Moodle housekeeping ESP January – March 2010
1.1 Single Sign On FE June – July 2010
2.1 Integration with Turnitin FE January – March 2010
2.3 Evaluating Moodle 2.0 on test server [Phase 1] ESP/FE May - July 2010
2.4 e-assessment related staff development SD January – June 2010
1.4 Developing SOOT FE January – February 2010

Category Key

 

The Project Milestones include:

 

Reporting and Monitoring

The responsibility for implementing the Moodle Development Plan 2010 resides with the Moodle Operations Manager. Progress with be disseminated through the following mechanisms and meetings:

 

 

Appendix 1: Moodle Development Projects 2010

1. Service Performance Projects

1.1 Single Sign On
Single Sign On (SSO) functionality has been implemented for a wide range of services already, such as the access to electronic journals, Learning Materials Filestore (LMF) and the Wordpress blogging application. The intention is to bring Moodle into line with these applications.
Rationale: Streamlining authentication process, leading to efficiency gains when moving between multiple institutional systems. Users will no longer need to log in once again when accessing electronic journals and LMF files through Moodle courses.

1.2 Moving Moodle 'log tables'
Each time a user completes a task in Moodle, such as clicking on a link to access a course, a record of this action is noted in the database log tables. These log tables are growing exponentially, which in turn is having an implication on the performance of the application. This project aims to regularly move data from the log tables to another database. It is our suggestion that the live database only holds 1 days' worth of data, before archiving it off. This data will still be available, but through a separate interface.
Rationale: The logs table is ever-growing and heavily indexed. At some point, if nothing is done, Moodle’s performance will deteriorate.

1.3 Moodle housekeeping
Whilst Moodle has been used at the University of Bath since mid-2006, the table containing user data has never been pruned. As such, 34000+ users currently exist in the Moodle database, even though there are only 12000 odd users in the LDAP (the BUCS database that contains username and password-type data). This work will happen once a year. This work should have a positive performance impact on Moodle, as we will be reducing the number of 'active' users in the database.
Rationale: Removing thousands of users from the Moodle users table, is likely, in turn, to have a positive effect of Moodle service performance.

1.4 Developing SOOT
SAMIS only stores the details of the Module Tutor for a particular unit. SOOT is a web application that enables staff other than unit conveners to be associated with a unit of study in SAMIS. These are referred to as Other Staff. Storing staff data in a central database in this way has the advantage of enabling it to be automatically pulled into e-Learning tools (such as Moodle and the LMF), whilst also ensuring that only one staff listing needs to be maintained, and only one interface used. New functionality for this tool is currently being developed, tested and rolled out.
Rationale: Efficiency gains, which will give those users needing it, quicker access to Moodle courses. Will allow easier coordination of a range of tasks needing to be completed across courses. This additional work includes functionality allowing for a Director of Studies, for example, to request access to every SAMIS-related Moodle course within their department, instead of requesting access to Moodle courses on a course-by-course basis.

1.5 Developing the Moodle-SAMIS functionality
As well as ongoing maintenance work on this functionality, a further development has been planned related to SAMIS occurrences. These are increasingly being used by departments - this project aims to get a better understanding about how they are being used, if approaches between departments are consistent and how they might be used/implemented in Moodle.
Rationale: Use of occurrences within SAMIS unit records is increasing. Failure to develop this functionality will lead to increased numbers of manual and bespoke tasks for both the e-Learning team and colleagues in academic departments.

2. Other Projects

2.1 Integration with Turnitin [on the moodle-test server]
 Turnitin is an Internet-based plagiarism-detection service, which checks for possible plagiarism by comparing submitted papers to several databases. As part of the a wider e-assessment review, some colleagues have already asked for Moodle-Turnitin integration.
Rationale: Requested by numerous colleagues in academic departments. Will lead to efficiency gains in terms of streamlining the process of running an electronically submitted item of work through TurnItIn. Currently, it is a manual and rather cumbersome process.

2.2 Questionnaire software
A number of Departments and Schools already use the solution Bristol Online Surveys (BOS) as a mechanism for conducting a wide range of questionnaires and surveys. A third-party Questionnaire Module is available for Moodle - further details can be found at: http://docs.moodle.org/en/Questionnaire. This module allows users to complete online feedback
style forms using a variety of user input methods. It allows you to create your own questions, unlike the Survey module which has presets to choose from.
Rationale: Provides for a Moodle integrated alternative to BOS. Easier to create and deploy questionnaires than the standalone tool, which requires the creation of manual user accounts.

2.3 Evaluating Moodle 2.0
Moodle 2.0 is due to be released to the wider Moodle community in summer 2010. It is likely, therefore, that the University of Bath will be upgrading the latest version of Moodle (2.1, 2.2) in summer 2011. Led by the Moodle Operations Manager, the Learning Technologists and Educational Software & Systems Developers will be undertaking some investigative work over the next 12 months or so, to explore how this upgrade will impact on stakeholders.
Rationale: Essential to upgrade to the latest version of Moodle to take advantage of new development within the software, and to maintain our position as one of largest Moodle installations within a UK HEI.

2.4 e-assessment related Staff Development
The aim is the develop the Moodle Staff Development programme to include a increased focus on completing e-assessment within Moodle. In particular, objective and subjective testing, as well as electronic submission of work. The latter is likely to include some technical work.
Rationale: An increasing number of academic departments are expressing an interest in this area of work. Part of the wider institutional e-assessment review currently being undertaken by Andy Ramsden, Head of e-Learning.

2.5 SAMIS Applicant Database
The recent launch of the aforementioned database will issue a BUCS-type username to prospective students. Whilst these user(name)s will not have access to Moodle during the 2010 academic year, it is anticipated that this might change moving forward. An initial needs analysis will need to be completed, and a policy statement and report published. This is likely to include some technical work. Rationale: This service is currently being rolled out by BUCS. There are opportunities to integrate this group of students relatively easily into Moodle.

Appendix 2: Project Schedule

A Gantt Chart can be downloaded in PDF format.

 

Footnotes
1 An online version of the Moodle Development Plan 2010 can be found at: http://go.bath.ac.uk/moodledevplan2010
2 The e-Learning Operational Plan (2009-11) can be downloaded from: http://go.bath.ac.uk/elearningopplan
3 The Moodle Advisory Group was Action (A2) of the e-Learning Operational Plan 2009/11. The group, which is convened twice annually, acts as a focal point for discussions on Moodle within the University, considers issues concerning the academic community with regard to Moodle practice within the Faculties and Schools and the ongoing development of the environment. Information can be found at: http://blogs.bath.ac.uk/moodle