CASCADE PROJECT: CASE STUDY 2 Customizing open source software: benefits and pitfalls

Aimed at e-Learning developers, this case study draws on the JISC-funded Cascade project’s experience of customizing the Moodle assignment module, to highlight the benefits and pitfalls of working with open source software.

1.

BACKGROUND & CONTEXT

The Department for Continuing Education1 is the University of Oxford’s largest department and each year enrols approximately 15,000 part-time students. It employs a core staff of 149 academic and support staff, as well as over 1,000 part-time tutors, to deliver its broad portfolio of over 700 courses, which range from one-day courses to sixyear part-time DPhil programmes. Almost all the Department’s programmes are delivered in flexible formats to enable students to study alongside their work or other commitments and an increasing number of courses offer an element of distance learning. The online infrastructure and services to support distance learning are provided by the Department’s e-Learning unit, Technology-Assisted Lifelong Learning2 (TALL). In November 2008, under its Transforming curriculum delivery through technology programme,3 JISC awarded the Department funding to undertake the Cascade4 project to investigate how technology could be used to improve efficiency and enhance the quality of its curriculum delivery services. Following a process of consultation with stakeholders, development of an improved facility for online assignment submission was identified as a key focus area of the project. A review of online assignment-handling systems was undertaken and, as the Department was already using the Moodle open source Virtual Learning Environment (VLE) software to support a number of its courses, it was decided that the most appropriate solution would be to customize the standard Moodle assignment module in order to meet the Department’s specific online assignment-handling requirements. 2.

INTENDED OUTCOMES

The intention of this focus area of the Cascade project was to develop modifications to the Moodle code, running locally, to provide the additional assignment-handling functionality required by the Department, and to make the majority of the updated code available for others to use by integrating it with the upstream project.a

a

1

“Upstream” is the conventional name, used in open source development, for where software code originates from. Typically, software code flows from its primary developer(s), down to other developers, distributors, and users.

3.

THE CHALLENGE

This aspect of the Cascade project had two key challenges: (a) to specify requirements for the enhanced assignment-handling functionality in Moodle; and (b) to develop the code itself. (a) Specification of online assignment-handling requirements The initial specification5 seemed straightforward: starting with the known functionality of the Department’s legacy online assignment-handling system; identifying the required additional functionality; matching these with the functionality already present in Moodle, and identifying the shortfall and hence those features that needed to be developed. Although the 'normal' workflow of the required system was relatively easy to specify, difficulties were encountered with identifying, and specifying, all the non-standard situations that could potentially arise. This was exacerbated by the wide variety of assessment formats used by the Department’s courses. (b) Development of Moodle code The challenge regarding the actual coding involved designing and producing code that was acceptable to upstream for other users of Moodle to utilize (in terms of meeting their needs and coding standards), as well as integrating well with the established use of Moodle within the Department. 4.

ESTABLISHED PRACTICE

At the start of the project, the following practice was in place: (a) Online assignment-handling The Department’s processes for online assignment-handing were fairly well established with a legacy online assignment-handling system (CASS), originally developed by its Department in the late 1990s to support its first online courses, being used by nine award-bearing programmes. The stand-alone CASS system offered facilities to support the following specific assignment-handling requirements of the Department:     

Submission of files, by students, in a variety of formats; Access to the system by a wide variety of tutors, many of whom are external to the Department, to mark assignments; Separation of assignment files by tutor group, within a single course, according to who would be marking them; Functionality for students to request extensions and for the relevant course director to grant/reject such requests; Email notification of relevant actions to inform users and prompt them if further action was required on their part.

Set-up and technical support for the CASS system was provided by IT staff from the TALL unit and the assignment-handling process was overseen by the Department’s Registry (to ensure compliance with University regulations). Whilst the CASS system offered essential functionality, the legacy system was cumbersome for students and tutors to use and required high levels of IT support to operate it, which meant it was not scalable for wider adoption across the Department’s full range of courses. (b) Moodle software development Moodle development was undertaken by the Department’s TALL unit. Local modifications to code were managed initially via a set of “patch” files describing changes to upstream Moodle, and instructions on how to apply them. “Tickets” in a Trac6 issue

2

management system (IMS) were used to document course and VLE development tasks, their progress, decisions, and completion. 5.

THE CURRICULUM DELIVERY ADVANTAGE

The Cascade project enabled the development of a new assignment-submission system that simplified the assignment-handling process and integrated it into Moodle, the VLE already used by the Department to provide support online for many of its courses. In terms of curriculum delivery, this offered a number of advantages including: 

An improvement in the student experience by providing an online assignment submission system that is easier to use and seamlessly integrated within the VLE, rather than accessed as a separate stand-alone system;



Increased efficiency by reducing the amount of time needed for assignmenthandling by Registry staff, course administrators and tutors, and IT support staff with opportunities for further savings across the Department by creating a robust online assignment-handling system that is suitable for use by more courses.

6.

KEY POINTS FOR EFFECTIVE PRACTICE

Outlined below are the key lessons learned during this element of the Cascade project: (i)

(ii)

When planning a software development project, it is important to identify and separate the technological development tasks from the process tasks being modelled – often there are underlying process problems that cannot be solved by technology. To assist with specification: 

Identify as many of the different administrative processes involved as possible, and the special cases (which will be numerous). Adapt these into specifications and illustrations of the software to be created;



Update the specifications and illustrations with the requirements of additional processes and special cases revealed as the project progresses.

Manage stakeholder expectations with clear communication: 

Describe in detail what the completed system will do, and what it will not do. In the Cascade project, initial negative reactions to online assignment submission resulted from tutors conflating the processes of assignment submission by students and on-screen marking by tutors; their reservations about the latter marred their enthusiasm for the former. Careful consultation removed the confusion but, with forethought, this could have been avoided.



Provide clear updates when requirements/specifications/schedules change.



Communicate when different stakeholders have conflicting requirements. This usually needs resolution of the process, rather than a technological solution.



Where limits on time and/or resources mean that not all desired features can be developed within the given timeframe, implement a system of categorizing features as critical, essential, nice to have, not in this version, etc.

(iii) Be disciplined in use of an issue management system: 

3

Use tickets for all issues and tasks from the start, providing support so all project members can use the system effectively;



Proper use of tickets provides a coherent way of tracking what work is required, and provides a history of reasoning and decisions for the project (which can be vital when later attempting to understand why the software behaves as it does);



A developer should not accept tasks without a ticket. The developer may create the tickets based on information provided by others, but this risks loss of information, duplication of effort and, more importantly, lack of team engagement with the IMS;



Make tickets actionable by limiting them to one task or issue, with a clear description of the problem and expected behaviour at completion.

(iv) Use a version control system to manage code, but don’t over-manage it:

(v)



To better manage the integration of our changes with those flowing from upstream, a version control system (“Git”)7 was adopted;



Moodle originally used “CVS”, but is gradually moving to Git;



Version control keeps a history of changes over the lifetime of the code;



Version control allows creation of linked copies (“branches”) of the upstream code which enables development of new features without disturbing the incorporation of new code from upstream;



“Merging” is a companion to branching which provides methods of combining changes from one branch into another;



Key to effective use of branching is knowing when to make branches. Too many branches or branches with overlapping features will be confusing and difficult to merge;



Use the version control system regularly, to get comfortable with using it, and so that progress is documented for later reference.

Testing the modifications: 

The developer needs to be rigorous in testing the system prior to its use by stakeholders in a pilot study;



Setting up multiple test users and checking the system's functionality from the aspect of each type of user ensures the correct integration of roles;



Retesting of correctly functioning features needs to be incorporated into later tests to identify any knock-on effects of further changes to the code when developing other functions;



Where possible, a unit testing framework should be created/used. This enables automatic testing of the code, on-demand and at regular intervals – e.g. every night. Although this will take additional time to set up and maintain, it should more than repay itself with time saved through early identification of problems;



Early on in the project, identify suitable opportunities for testing. In this project, having to tie in with known assignment deadlines for the courses taking part in pilot studies provided a time schedule for the development. Also having a limited number of opportunities for running pilot studies with real assignments became an issue when problems identified in one pilot study needed to be resolved then retested.

(vi) Working with an open source project: 

4

Learn about, and join in with, the existing community8 and development culture;

7.



Take the upstream development status into account, e.g. upstream is focusing on Moodle 2.0, which means that there is no chance of new features and code created for the Cascade project being incorporated into Moodle 1.9;



Continuing development away from the “bleeding edge” is the right thing to do if that is what your schedule requires;



Offer up your ideas and designs, and incorporate some of the comments you get in return;



Do not worry too much about including features that others want, as this may overcomplicate your initial development. Initially keep it as simple as possible and get your key requirements working;



Share your code; if it interests others, they will try it and give useful feedback.

CONCLUSIONS AND RECOMMENDATIONS

The experience of the Cascade project suggests that customizing open source software to meet the institution’s bespoke curriculum delivery requirements can result in the development of a robust system offering improved services to stakeholders. Key recommendations for other developers considering similar projects are: 

Define the processes involved before working on the development of software; a broken or unclear process cannot have an effective technological solution;



Keep all stakeholders informed of what the final result will be, providing updates when the requirements/functionality change;



Have everyone concerned with functionality and bugs use an issue management system from the start of the project;



Use version control to manage code, but keep it simple;



Learn and work with the norms of the open source community for maximum wider benefit.

8.

ADDITIONAL INFORMATION

1.

Department for Continuing Education website: http://www.conted.ox.ac.uk/

2.

Technology-Assisted Lifelong Learning (TALL) unit: http://www.tall.ox.ac.uk

3.

JISC Transforming curriculum delivery through technology programme: http://www.jisc.ac.uk/whatwedo/programmes/elearning/curriculumdelivery.aspx

4.

Cascade project: http://cascade.conted.ox.ac.uk/

5.

The following online assignment-handling specification documents, developed during project, are available on the Cascade project website:

5



Wish list of assignment-handling features: http://cascade.conted.ox.ac.uk/sites/cascade.conted.ox.ac.uk/files/Assignment WishListLatest.doc



Comparison of CASS and Moodle: http://cascade.conted.ox.ac.uk/sites/cascade.conted.ox.ac.uk/files/Comparison %20of%20CASS%20and%20Moodle.doc



Assignment handling flowchart: http://cascade.conted.ox.ac.uk/sites/cascade.conted.ox.ac.uk/files/flowchartLat est.xls

6.

Trac is an issue management system (IMS) for software development projects (see: http://trac.edgewall.org/)

7.

Git is a distributed version control system (see: http://git-scm.com/about)

8.

Resources, including forums, documentation and open source code, from the Moodle developer community are available at: http://moodle.org/development/

9.

More detailed information about the work outlined in this case study is available in the Final Report of the Cascade project, which is available from: http://cascade.conted.ox.ac.uk/project-outputs

10.

Moodle source code developed by the Cascade project is available to download from: http://cascade.conted.ox.ac.uk/project-outputs

Project Contact:

6

David Balch, Senior Web Developer Technology-Assisted Lifelong Learning (TALL) Department for Continuing Education University of Oxford Email: [email protected]

6 CASCADE Customizing open source software benefits and pitfalls ...

6 CASCADE Customizing open source software benefits and pitfalls.pdf. 6 CASCADE Customizing open source software benefits and pitfalls.pdf. Open. Extract.

49KB Sizes 0 Downloads 260 Views

Recommend Documents

Open Source Software for Routing
ISIS (IPv6) (and ISIS IPv4 is not yet useable). • Multiple branches of Quagga: -. Quagga.net (official “Master” branch), Euro-IX, Quagga-RE and more. 17.

Free/Libre and Open Source Software Outline
Nov 19, 2010 - Free/Libre Open Source Software (FLOSS) World ... companies could adopt so as to participate in the world of ... 10 / 15. Impact of Low Intensity FLOSS Activity. Areas with a Low Intensity of Free/Libre Open Source Software ...

Open Courseware and Open Source Software
Wbile putting individual course material online is already a ... smaller and more fragmented than the shared con- text for open source ... currently dominant business models, the true long- ... shows strong global support for the idea of open.

Open Source Software for Routing - apnic
Funded by Companies who like an Open Source. Alternative. ‣ Non-Profit Organization. • Part of ISC (Internet System. Consortium). Quick Overview of what we ...

Producing Open Source Software
Producing Open Source Software: How to Run a Successful. Free Software Project by Karl Fogel ..... Identification and Header Management . .... Archiving IRC .

Producing Open Source Software
1SourceForge.net, one popular hosting site, had 79,225 projects registered as of .... Ten years ago, even five, it would have been premature to talk about a global ..... Such investments could, in the best scenarios, repay themselves many times over.

Producing Open Source Software
Running a free software project is not exactly like running a business .... number of free software projects on the Internet, of course; it's just the number that ... that even though only a small percentage succeed, the result ..... 1970's had been

Open Source Software for Routing - Semantic Scholar
Documentation & clean code http://www.xorp.org/ ... DragonFlyBSD, Windows. ‣ Juniper like CLI. ‣ Written ... (no GPL limitations). Clean C++ Source with good.

understanding open source and free software licensing pdf ...
Page 1 of 1. understanding open source and free software licensing pdf. understanding open source and free software licensing pdf. Open. Extract. Open with.

Open source software is changing the world and ... Developers
Open source software is changing the world and creating the future for the 11th ... Give students more exposure to realworld software development scenarios.

Generalized procedure for screening free software and open-source ...
Generalized procedure for screening free software and open-source software applications_Joyce_2015.pdf. Generalized procedure for screening free software ...

open-source-software-and-free-software.pdf
Open Source Software & Free Software .... about lack of vendor support or feel compelled to. upgrade. Whereas ... open-source-software-and-free-software.pdf.

An Open-Source Hardware and Software Platform for ... - GitHub
Aug 6, 2013 - Release 1.03. Zihan Chen. 1. , Anton Deguet. 1. , Russell Taylor. 1. , Simon DiMaio .... the high-speed serial network (IEEE-1394a) and the I/O hardware. In this design .... of services: isochronous and asynchronous transfers.

Benefits and Pitfalls Simple Guidelines for the Use of Social ...
Benefits and Pitfalls Simple Guidelines for the Use of Social Networking Tools in K-12 Education.pdf. Benefits and Pitfalls Simple Guidelines for the Use of Social ...

Open Source & Libre Software in medical practice.pdf
Open Source & Libre Software in medical practice.pdf. Open Source & Libre Software in medical practice.pdf. Open. Extract. Open with. Sign In. Main menu.

Daniel Martins – Software Engineer Open Source Enthusiast ... - GitHub
Parses bencoded strings directly to Clojure data structures and vice-versa ... Worked on 2012's Big Brother Brasil broadcasting page, which would then become ...

Guide to Using Open-Source Software to Develop Web Applications
so with severe budget constraints. They need a Web infrastructure that can enable higher developer productivity .... How to Get Started with Sun's Open-Source Web Application Platform ................ 8. Learn More . ..... servers for the database se