Sunday, 21 November 2010

Moving to Moodle 2

In my presentation at the UK MoodleMoot earlier this year I raised a number of questions about what the OU is going to do next with our Virtual Learning Environment – and I’ve been meaning to say something about how we’re answering those questions.
To cut to the chase, we are going to stick with Moodle, and we are planning to use Moodle 2 very significantly closer to its ‘out of the box’ form.
During the summer we commissioned a review of Moodle and a number of possible alternatives in both the commercial and open-source markets, and eventually came to the view that, for the OU, continuing with Moodle was the right way forward.  However, we do recognise that we made too many localisations in our adoption of Moodle 1.x – we will be making substantially fewer with Moodle 2.x.
We also guessed, back in the early summer, that Moodle 2 probably wasn’t going to make it out the door until sometime in the Autumn (at the earliest), and we’ve been assuming that there wouldn’t be a proper/stable Moodle 2.0 release until about the turn of the year.
Our plan, at this point, is to have a fairly complete new OUVLE in place in March 2011.  This will be based on Moodle 2 and will have most (but probably not all) of the major OU contribs we developed for Moodle 1.x migrated to run in Moodle 2.   We’re not intending that this release gets used with our learner community; it will be primarily used for testing, particularly to allow us to be confident that Moodle 2 will be able to carry the load we expect. At the moment our Moodle 1.9 installation is seeing something like 1,000,000 transactions (from 50,000 users) a day and these numbers are both still increasing.
The first student-ready release of our new OUVLE will come online in June 2011, with a follow-up release in September 2011.  We’re planning to run the new OUVLE alongside the existing Moodle-1.9-based OUVLE for at least 12 months, and we’ll be gradually moving students over to the new OUVLE during that period.
The new OUVLE will also have significantly more facilities than the current VLE.  In addition to enhancing a number of the standard tools that we use (the OU versions of the forum, blog and wiki, and the new quiz engine that will be part of Moodle 2.1) we’re also carrying out a programme of developments to improve (i) Moodle’s support for mobile devices, (ii) integration with Google Apps for Education, (iii) facilities for both personalisation and the handling of user generated content.

Tuesday, 4 May 2010

Moodle 2.0 - and rivals.

The arrival of Moodle 2.0 is clearly a very important landmark for the entire Moodle Community, however for the OU it is also going present a number of challenges.  In my talk at the UK MoodleMoot I highlighted the fact that the OU has made something like 2000 localisations to the standard Moodle, and that this did represent something of a challenge to us in moving.
As part of understanding that move we want to commission a study of the alternatives to Moodle 2.0. We want someone to compare the functionality that Moodle 2.0 is going to offer with the functionality currently (or in the near future) offered by Blackboard, Desire2Learn and Sakai.
There is more information about the study on the OU tenders website

We are asking for bids to undertake this work to be submitted (via the tenders website) by 14th May 2010, and we want the study to be completed by 30th June 2010.

Sunday, 18 April 2010

VLE Development at The Open University

At the MoodleMoot recently I was asked a number of questions both directly and via twitter about the model that the OU is using in our VLE development - a blog posting seems like the best way to describe what we do.
The model isn't based on any formal methodology as such but has essentially evolved to meet the needs of the OU.  There are certainly 'agile' elements in the process - at least in that we are constantly adjusting our developments to meet changing requirements from the OU community while still ensuring that we are able to thoroughly test developments before we release them to our student community.
We now have a quarterly release cycle, and we try to minimise the number of changes between those releases.  Each cycle covers a period of approximately ten months starting with a requirements gathering phase going through to a three month period when a particular release is ‘in service’.


1. Requirements Gathering.  For a couple of years we have had a process (and activities) that encouraged the submission of requirements ahead of each of the four releases in the year.  This lead to a lot of requirements being submitted, but the development team had difficulties in keeping the submitters informed about their requests.  To improve on this we’re just on the point of rolling out a requirements gathering database into which any member of the University can enter a requirement, and then come back to the database later to see the progress in implementing their requirement, or indeed why it’s not been possible to address that requirement yet.
At a pre-announced date approximately six months before a release is due to go live, we pull together the most pressing requirements from the database and from other sources around the University and put together a development plan for the release.
The decisions here will be based on (i) operational requirements, for example changes needed to improve or preserve the VLE performance,  (ii) addressing changing University strategic plans and (iii) the value of particular developments for large numbers of students.
We regard each development cycle as a distinct activity, so we reassess all the new and outstanding requirements at the start of each development cycle -  this means that new requirements may (particularly if they are performance related or address a particular strategic target) displace requirements that have been in the "queue" for a long time.
2. Once the development priorities have been determined for the release, the development tasks will be allocated to the development teams (each team having one leading technical developer working with a number of technical developers). At this time we will prepare a development environment for the new release, merging the latest stable release from with our code base. This then forms the underlying code base for the next three months development work.  Each developer has their own development environment and is able, once they are happy with their development code (and it’s been reviewed by one of the lead developer), to commit changes into the CVS respository.  One of the challenges with a large number of parallel developments is that changes made by one developer can impact on code committed by another developer - ensuring that all the developers are aware of the range of developments certainly helps, but we are currently experimenting with a continuous integration system that will highlight problems very early in the process.
3. At the end of the development period (usually 12 or 13 weeks), the developments for the release should be functionally complete - and the statement of what’s likely to be in release that was prepared at the start of the development period gets revised.  At this point new developments get passed through to the testing team, where the new developments get tested to ensure that the functionality is as required (at this point we can start preparing the user documentation for these new features).  Issues raised by the testing team get logged directly in the Bugzilla system used by the development teams.
4. About four weeks after the functional testing starts we will be at a point when the new release of the VLE can be put onto our acceptance test system (this is the first rehearsal for the upgrade).  The new features will have been through one round of testing and bug-fixing and then integrated with the other new features into a release candidate. This is turned over to the testing team again for two weeks of intensive testing, followed by a window for bug-fixing, then a further week of verification testing.  At this point there will be a further upgrade rehearsal, before at the real upgrade. By this point in the cycle we will also have release documentation in place, and the online Computing Guide (that’s available to all users) will have been updated to reflect changes in features.
5. The upgrades to the production servers happen the on first working Tuesday of March, June, September and December, ideally, during our advertised "at-risk" periods.  On some occasions, typically if there are major database changes that require the database to be reloaded, we will need a longer downtime than the "at-risk" period allows, but we try to keep the interruption to a minimum (and we do advertise the interruption well in advance).   We will almost always have a catch-up release seven days after the main release to allow patches that didn’t quite make the deadline get onto the live system.
6. Once the release has gone onto the production servers we try and minimise the number of changes to the system. If there are security patches needed these will happen as soon as possible, in other cases changes that are requested will be vetted to confirm if they really are needed urgently.  A change to remedy a serious problem with an assessed activity is likely to be allowed, but a cosmetic change would be queued to be included with the next scheduled release.
7. The release will then stay in service for about three months, until the next release is ready to roll.
8. We also do regular reviews of both usability and accessibility.  For new features we will factor in testing periods during development, this is in addition to incremental testing on the each release, just after it goes live, either by expert testers or by student testing panels.  The outputs from this testing is fed back into the development process, with urgent changes being regarded as critical patches, and other less urgent changes being queued for the next scheduled release.

Moodle at the OU

I gave a keynote presentation at the UK MoodleMoot on 13th April 2010.
In the presentation I reflected on the OU's selection of Moodle in 2005, and reported on the developments that the OU has both commissioned and carried out directly.
I also talked about the scale of the OU's current Moodle installation, and speculated about how we would be working with Moodle 2.0 once it is released.
The slides from that presentation are now available on SlideShare.

A number of my colleagues also gave presentations which are now available on SlideShare
Anthony Forth - Mobile Moodle and DataPlus
Phil Butcher - Assessment for Learning

And if you want to see the gory detail - the videos of (some of) the sessions are now available online too.