Implementation of an Open Source School Web Learning Environment Project

Page 1 Project Title Introduction Objectives Minimum requirements Page 2 - Page 7 Background Research Methodologies Page 8 - Page 13 Analysis Requirements Page 14 - Page 18 Solution Development and Initial Testing Page 19 - Page 21 Solution Implementation and Student testing Page 22 - Page 26 Solution Evaluation Project Evaluation

Project Title
Implementation of an Open Source School Web Learning Environment

Introduction
With Virtual Learning Environments having now developed into mature systems capable of supporting a range of pedagogical models, it has become necessary to examine the effectiveness of these systems in meeting the needs of the school environment. This project aims to be a starting point for further research into this area by providing a nontheoretical view of the needs of a secondary school and the effectiveness of a specific Virtual Learning Environment (Moodle) in meeting those needs.

This project is primarily an investigation into whether the open source Virtual Learning Environment (VLE) known as Moodle is capable of meeting the requirements for webbased distributed learning found within a secondary school environment. This project aims to provide a factual account of the requirements for web-based learning within a specific secondary school and the abilities of Moodle in meeting them, to be used as an aid for schools investigating which VLE to implement and a starting point for further research.

Aims/Objectives
This project aims to examine the application of open source software in web-based learning within a secondary school environment, through customisation and implementation of a Moodle Virtual Learning Environment solution to meet a chosen school's virtual learning needs. The objectives of this project are:

Research the subjects of Learning, Teaching, Open Source Software and Virtual Learning Environments within Secondary education. Identify and adopt a suitable methodology capable of providing the necessary structure for the project life cycle. Gather the requirements for a Virtual Learning Environment from technicians, teachers and students at the chosen school and from these, derive a set of core fundamental requirements to be addressed primarily. Develop a suitable look for the Moodle installation that fits within the current systems used by the chosen school. Develop a Moodle solution capable of meeting the core requirements of the chosen school. Make the developed Moodle solution available for use by the chosen school. Contribute modifications and findings back to the Moodle community.

Minimum requirements
The minimum requirements for this project are:

A literary review of existing material on the subjects of teaching, learning and Virtual Learning Environments. A requirement document generated through interview with problem holders. An open source Moodle solution customised to meet core requirements and to match existing systems within the chosen school. Deployment of the solution for use by the chosen school. An evaluation of the final solution against the specified core requirements.

A few possible enhancements to the project are listed below:

The inclusion of non-core requirements into the system including real time chat and revision quizzes. The generation of material to assist with the usage of the LPS Moodle environment. An evaluation of the project process.

Background Research

To attempt this project it is necessary to understand the potential impacts on students and teachers from the points of view of how they learn and teach. To gain an understanding of these topics, research was carried out into learning styles and teaching techniques, as well as research into open source software, Virtual Learning Environments and the current efforts to introduce these technologies into secondary school education. Also due to the size, timescale and nature of the project it was necessary to research and decide upon a project methodology to define a structure for how the project should be undertaken. Project Methodologies To provide a structure for carrying out the project, software project methodologies were reviewed. These were the Waterfall Model, the Iterative Waterfall Model, The Spiral Model and Rapid Application Development (RAD). From this review an appropriate methodology was chosen for this project.

The Waterfall Model The original Waterfall Model, first proposed in 1956, is based around the principal of a series of activities which are carried out during the projects lifecycle in order from top to bottom. Each activity must be finished before the next activity can be started and once an activity is finished it cannot be revisited. These activities usually equate to Analysis, Design, Implementation, Testing and Evaluation. The primary flaw with this model is its lack of flexibility. The lack of possible iteration means that changes in user requirements outside of the Analysis phase are not taken into account. A more recent adaptation of the original Waterfall Model known as the Iterative Waterfall Model follows the same basic rules of its predecessor, with the addition of the possibility for revisiting activities previously thought to be finished if the need arises. This helps overcome problems that may become apparent during later activities but must be used sparingly.

The Spiral Model The spiral model is a software development process combining elements of both design and prototyping-in stages, in an effort to combine advantages of top-down and bottom-up concepts. For a typical shrink-wrap application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty graphics) as an operable application, add features in phases, and, at some point, add the final graphics. The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. Advantages

Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier

Rapid Application Development Customers of IS/IT are concerned with getting working business applications delivered quickly and at low cost and Customers often see structured methods as unnecessarily bureaucratic and slow. The Rapid Application Development (RAD) methodology was created as a way of addressing these issues and of minimising the impact of changes in user requirements on the project. The process of RAD involves breaking a system into several smaller subsystems by for example breaking the requirements into distinct sets. The first of these subsystems is then developed and reviewed by the customer. When customer satisfaction is achieved, the next subsystem is developed and reviewed and so on until the complete system is finished.

Following this methodology allows customers to be involved continually throughout the project and allows the product to be developed incrementally. Developing in this manner can allow the customer to use or even sell a partially complete solution. Chosen Methodology Due to the need to get a working system up and running as early as possible, the system will be developed using the RAD approach. This approach fits very well with the modular design of Moodle and will allow the system to develop quickly and parts of the system to be used while others are being developed. This methodology will also allow changes in requirements or the emergence of new requirements to be addressed as they arise.

Teaching and Learning

Introduction Now that I have structured the workflow of the project by means of selecting a suitable methodology, it is necessary to look at the potential pedagogical factors that are present both within the school and the proposed solution. To design and successfully implement any system aimed at improving teaching and learning such as a Virtual Learning Environment, it is first necessary to gain an understanding of how pupils learn and how teachers teach. The following sections give a brief overview of popular learning theories and teaching techniques. As many Virtual Learning Environments are designed to embrace social constructivism, particular emphasis has been paid to learning and teaching via social constructivist methods. Teaching via Direct Instruction The direct instruction method of teaching is the classic method of teaching were the teacher is the absolute authority on the subject and the learner is simply expected to remember what they are told. This view of learning assumes that knowledge can be imparted from teacher to learner through instruction and lecture. Generally, knowledge is dictated to the learner with no allowance for student interaction and indeed as Dirks states "The learner was commonly penalized for too much variation from the text." or for questioning the facts. Although still used in some subjects like mathematics where the learning of rules, formulas, sequences and fundamental facts are paramount, this style of teaching is ineffective for high level subjects where analysis and evaluation are expected.

Teaching via Indirect Instruction The indirect approach to teaching is where learners are presented with materials, objects and exercises that help them go beyond the simple facts they have be taught. This technique drives the learner to underpin the knowledge they have gained through independent practical research and experimentation, and also allows them to develop advanced analysis and thinking skills. Teaching via Social Constructivism With teaching via direct or indirect instruction the teacher is always considered a major driving force in the learning process. To teach in a socially constructive manner, a teacher must adopt a more backseat role as a guide. Doolittle indicates that eight factors are essential in constructivist pedagogy. These are;

Learning should take place in authentic and real-world environments. Learning should involve social negotiation and mediation. Content and skills should be made relevant to the learner. Content and skills should be understood within the framework of the learner's prior knowledge. Students should be assessed formatively, serving to inform future learning experiences. Students should be encouraged to become self-regulatory, self-mediated, and selfaware. Teachers serve primarily as guides and facilitators of learning, not instructors. Teachers should provide for and encourage multiple perspectives and representations of content.

Dirks highlights 5 key support activities that a teacher is expected to undertake to assist the constructivist learning process.

Ensure alternative perspectives are accessible readily to students. Establish a conducive environment and encourage the student to empathetically enter the alternative perspectives. Provide access to the conversation of the knowledge community. Enable the social environment in which cognitive interactions and dialogic processes can evaluate the alternatives. Provide incentives to encourage learners to complete the knowledge construction process.

The Cognitive Theory of Learning

The Cognitive theory of learning developed by the Swiss psychologist Jean Piaget, depicts knowledge as being generated through the learners active exploration of their world. Piaget states that as a child matures, the ways in which they think and interact with their environment changes. Firstly from birth a child makes sense of the world via feeling, seeing, tasting and hearing. Between the ages of 2 and 6 a child learns to group knowledge and begins to understand that others have a viewpoint. Later as the childs mental abilities grow they gain the ability to think logically. Finally by the age of 12, a child will manipulate ideas in their head. This allows them to organise events systematically, examine other possibilities and consider events that have not happened via deductive thinking and the imagination. Equipped with these skills and a need to understand, a child will develop knowledge beyond mere fact as they explore their environment over time.

The Information Processing Theory of Learning

This approach to learning is based around the idea that the brain absorbs information as it is experienced, analyses and processes it within the short term memory and stores it with other related information in the long term memory. As the child progresses through life new information is compared to stored information, the stored information is refined and reordered in a more diverse manner to accommodate new understanding of prior knowledge. An example would be a child who has seen a rabbit for the first time. This knowledge is compared to prior knowledge and place accordingly in the long term memory. In this case the new knowledge of the rabbit is compared to the prior knowledge of the childs grandmothers dog. Both are furry so the new knowledge is stored next to the knowledge of the dog. Initially the child will consider the rabbit as a dog and visa versa. As the child learns more about the rabbit and the dog, they see they are in fact different. The knowledge is reaccessed and segregated to accommodate this new diversity.

The Social Constructivist Theory of Learning

"Many scholars have now determined that knowledge, like Truth, is not objective, but socially constructed, and as such, it depends a great deal upon that which the learner brings to the experience and interactions with other knowers." The social constructivist view is that learners make sense of new information by comparing it with prior conceptions and experiences and those of others. This basically means that for someone to learn they must be allowed to question, analyse and truly understand the information presented before them in a social setting. Walters, K. states "The knowing subject is not a passive spectator who simply receives information that is anonymously processed in a formalistic black box. Instead, she brings to the act of knowing a complex set of presuppositions and commitments, and this set necessarily informs the type of information she concentrates on as well as the inflections she places on it. There is not, then, a radical separation between the knower and the object of knowing or the knower and the act of knowing." Study has shown that we can force knowledge into our short term memory for recall during a pressure situation such as an exam but this knowledge is easily forgotten. Dirks states "Cognitive retention studies seem to suggest, however, that a great deal of the content we deem important is not retained beyond the necessary demonstration for grading purposes." and "The requirement of active engagement of the learner in the process of constructing meaning, as opposed to the acquisition and retention of content, means that such ingrained teaching methods as the lecture may not play an important role in producing constructed knowledge. Through constructivism a learner is able to understand information rather than memorise it. This understanding is more beneficial than a simple fact as it can be applied to other problems. Through social constructivism a group of learners are able to draw in each others understanding and past experiences of a given problem and create a better understand based on these views. "What a child can do today in co-operation, tomorrow he will be able to do on his own." Dirks outlines 5 key stages that a learner goes through during social constructive learning, these are:

Exposure to alternative perspectives. Empathetic experience of entering into those perspectives for understanding. Understanding of the body of theory relating to the subject. Evaluation of the alternatives through reflection and critical thinking. Construction of a personal perspective, the matter that is learned.

Virtual Learning Environments

Introduction This section looks at what a Virtual Learning Environment (VLE) is, the common functionality that all VLEs provide and the proposed benefits of VLE usage. A Virtual Learning Environment is a piece of information communication technology that provides an integrated online learning environment for the facilitation of e-learning. They can be used to deliver courses in their entirety to students using distance learning or to complement traditional face to face learning. Although a VLE can be used as a document repository and to teach via direct instruction, they are designed primarily to engage learning and teaching through social constructivist methods and provide many core features for assisting with this, these include;

Forums supporting threaded discussion. Whiteboards / Messageboards. Real-time chat systems.

Proposed Benefits

A VLE offers a consistent interface, both to staff and learners. It's usually possible (and easy) to tailor this interface for different groups, so that, for example, you could choose to make available a 'real time' chat function to one group but not to another, depending on which classes they are enrolled on via the VLE. A VLE is integrated - all the functions and services are provided via the one system, rather than being discrete components as they probably will be on your intranet. This makes it both easier to use (for staff and students), and easier to install and maintain. In fact, the technical support required for a VLE is likely to be considerably less than for an intranet - an important factor for overstretched and under resourced technical support staff in colleges. Indeed, some colleges have chosen to have their VLEs hosted remotely, usually by the company supplying them - and so, in effect, outsourcing all the installation and technical maintenance problems. A VLE makes it easier to organise virtual classes, enabling class-based discussions, group work, peer support, and so on.

Because a VLE can be logically (in a technical sense) completely separate from an intranet, there is less danger of compromising your intranet through hacking activities.

as well the following benefits to students, teachers and parents;

Staff and students often find it easier to use ICT within an integrated environment. Communication channels are increased through the use of discussion groups, email and chat rooms. Flexibility if anytime, anywhere learning allows absent or excluded pupils to continue with their studies via the VLE. Access to online content supports homework study outside of school hours. Students develop higher level learning styles and new approaches to learning.

Open Source Software

Open Source software is software that is licensed under one of the many Open Source licenses provided by the Open Source Initiative (OSI). To be eligible for an Open Source licence, the software must conform to the Open Source Definition provided by the OSI. This definition states that;

The licensed software should be distributed freely. The source code of the licensed software should be made available either bundled with the software or in cases where this is inappropriate, via other publicised mean such as the Internet. The licensed software should be freely modifiable and any derived works must be allowed to be distributed under the same terms as the original software. The licensed software should be made available to everyone and for any purpose.

Possible benefits of using Open Source software The underlying principle of Open Source software is that when programmers can read, redistribute, and modify the source code for a piece of software, the software evolves.

People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing. This means that in principal Open Source software should be more adaptable and have fewer bugs. Also as many people are developing the code, bugs should be highlighted and fixed relatively quickly compared to commercial software. Financially, Open Source software carries no licensing fees. This allows institutions with a limited budget, such as schools to acquire functionality that would otherwise be out of reach. Other major advantages of using Open Source software are that it is normally developed to be cross platform compatible and is developed so that any external requirements such as databases can be obtained via other Open Source software.

Analysis
Introduction This chapter provides details of the key physical elements that play a part in the project, namely:

The school which the solution is to be developed for, LPS School and its existing systems. The users that the solution will be developed around. The software to be used to develop the solution, Moodle.

The School Environment LPS School is a mixed comprehensive community school catering for over 5000 students between the ages of 5 and 18. The school has several branches and is situated in Delhi. Technical staff LPS School has no dedicated IT staff. Instead the role of IT / Network Administrator is taken on by the Head of ICT, Mrs Dhawan with the assistance of a part-time technician, Miss Sunita.

Teaching staff LPS School provides the full range of subjects outlined by the national curriculum to all students. To facilitate the study of these subjects the school employs 150 fulltime staff, many of whom have other roles within the school such as Heads of Department. Students As mentioned previously, the students at LPS School are between the ages of 5 and 18 and from a large geographically distributed area. Students at the school are well mannered and very positive towards teaching and learning within the school. Teaching Styles present at LPS School Teaching at LPS School is carried out via a mixture of Indirect Instruction and Social Constructivist methods. Teachers use in-class exercises and homework to help students develop their own ideas and stimulate thinking. Teachers use probing questions to challenge students views and homework is used as a way of extending and reinforcing work begun in class. Teachers of many subjects at LPS School openly encourage debate and the questioning of knowledge, which are paramount for the development of social constructivist learning. School Website LPS School has an external website (www.lpsdelhi.edu ) which is used to provide parents of potential students with information such as the School Prospectus, parents of existing students with information such as the School Calendar, and existing students with details of the subjects and important course materials. It is important to note that although the website is structured in a way as to allow each subject to provide its own resources, currently ICT is the only subject that has done this.

Analysis - continued ......

The desire for a Virtual Learning Environment at LPS School Staff at LPS School are constantly looking for ways to engage their students and to promote learning outside of the classroom. Prior to the schools inclusion in this project,

the head of ICT begin to look into the possibility of making coursework resources available via the existing school website. This however was deemed too difficult to maintain and structure. It is felt that a Virtual Learning Environment may provide a means of structuring resources and would also provide necessary tools to allow communication to continue outside of the classroom environment. The Virtual Learning Environment - Moodle Moodle is a software package for producing internet-based courses and web sites. It's an ongoing development project designed to support a social constructionist framework of education. Moodle is provided freely as Open Source software. Basically this means Moodle is copyrighted, but that you have additional freedoms. You are allowed to copy, use and modify Moodle provided that you agree to: provide the source to others; not modify or remove the original license and copyrights, and apply this same license to any derivative work.

Moodle is basically a Virtual Learning Environment developed to facilitate web-based distributed learning. What sets Moodle apart from other VLE systems is its grounding in social constructivism, its flexible ability to embrace the educators pedagogy (Moodle doesnt force the use of social constructivism) and the fact that it was created and continues to be developed by teachers for teachers. Functionality Moodle is designed in a modular fashion around the idea of Blocks and Modules. Moodle provides a core level of functionality that can be added to via the use of these Blocks and Modules to suit individual course needs. Core functionality provided by the Moodle environment includes:

The ability to assign users into distinct categories each with differing privileges and levels of access to the system. The ability to structure courses. Several course formats are available such as by week, by topic or a discussion-focussed social format. Each course has its own homepage which can be used to display any changes to the course since the last login and news relating specifically to that course, thus helping to give a sense of community. An embedded WYSIWYG (What You See Is What You Get) HTML editor is provided to allow editing and creation of resources, forum postings, journal entries etc.

Activity reports for each student are available with graphs and details about each module (last access, number of times read) as well as a detailed "story" of each students involvement including postings, journal entries etc on one page. Copies of forum posts, teacher feedback etc can be emailed in HTML or plain text whenever required. Courses can be backed up into a zip file that can be restored on another Moodle server.

Analysis - continued ......

Moodle Blocks are functional areas that can be placed along the left and right borders of the initial site page and individual course home pages. These Blocks include:

Activities A Block used to provide links to activities within course. People A Block used to provide access to course members details. Calendar A Block that acts as a calendar, providing the facility to view course events, site events, group events and personal events. Administration A Block that provides administration functionality such as the ability to modify course settings. Recent Activity A Block that displays changes to the course or site since you last logged in. Online Users A Block that provides information about users that have used the environment within the past 5 minutes.

Moodle Modules are actual areas of functionality that can be instanciated to create activities within the Moodle site and individual courses. For example, the Forum Module provides the functionality to create and maintain forums while a teacher forum is an activity that uses the functionality provided by the Forum Module. The current stable version of Moodle is provided with the following Modules as standard;

Assignment Provides functionality for setting online assignments such as time stamping submissions against a specified deadline, student submissions tracking and uploading, return of grades. Chat Provides basic chatroom functionality for online discussions.

Choice Provides functionality for carrying out simple multiple choice polls and surveys. Forum Provides typical forum functionality, as well as the ability to rate forum posts and control who can post to specific forums. Glossary Allows a glossary of terms to be maintained and automatic linking of terms to glossary entries. Journal Provides the facility for a user to maintain an online journal which can only be viewed by themselves and the course teachers. Lesson The Lesson Module provides the ability to create a collection of pages that guide the user through a particular topic. Each page terminates in a series of questions which must be answered. Based on the answers provided by the user, they can be directed to further reading on the subject (if incorrect) or on to the next subject (if correct). Quiz Provides the ability to maintain a structured repository of questions (multiple choice, short answer, numerical answer or term insertion) from which online quizzes can be generated, as well as providing grading, question randomisation and answer randomisation facilities.

Other Blocks and Modules exist and are available via the Moodle website, they are however either deemed unnecessary for general use or simply not stable enough for inclusion in the standard distribution, these include an Appointments Module, an Attendance Module and a module designed to allow integration of quizzes created by the popular Hot Potatoes software into Moodle.

Requirements
The main goal of this project is to address whether Moodle is capable of providing the functionality and facilities to meet the requirements of the chosen school. This chapter documents how the requirements for LPS Schools Moodle were captured, the actual requirements generated via these methods and those deemed core to the project. User Groups from which Requirements were captured and Methods used Technical Staff The current technical staff within the school will be responsible for the system after the completion of this projects lifecycle. Therefore it was important that their requirements were addressed. The technical staff were also responsible for outlining different user classes and what functionality should be available to each class of user. As the school only has two technical staff, the requirements were gathered by a single interview with

follow up questions as required. This technique allowed prompt discussion and clarification to take place.

Teaching Staff Teachers from LPS School were asked to contribute their views on what they would like to be able to do and what they would require from a Virtual Learning Environment to be able and willing to use it. Due to the fact that the vast majority of teachers were unavailable for comment due to work commitments, the primary sources for the requirements were the Information Communication Technology teaching staff. Again semi structured interviews were used to gather the maximum amount of data over a short period and to avoid taking up too much of the teachers time. Students from LPS Student requirements were captured via a questionnaire given out during ICT lessons. The questionnaire was used as it allowed quantitative data to be collected quickly and filling out the questionnaires during a lesson meant that the return rate was very high.

LPS Schools requirements for a Virtual Learning Environment

Core System Functionality Requirements Technical staff and teachers were asked during interview what functionality they would like to see present within the system. The following list contains the core requirements captured. Technical

Login instructions should be given on the homepage. The system should use existing usernames and passwords. The system should be reliable. The system should be secure due to the sensitive nature of the stored information.

The system should be accessible via the existing school website. The existing school website should be accessible via the system. The system should be simple to patch when required. The system should allow students to create and maintain a profile. The system should record usage statistics.

Teaching

The system should allow resources to be presented in a structured manner. The system should allow learning to continue outside of regular classroom hours. The system should allow display or download of existing PDF documents. The system should allow display or download of existing Microsoft Office documents. The system should allow display or download of graphical images. The system should allow communication outside of regular classroom hours. The system should allow resources to be hidden from users. The system should allow working web links to be used. The system should allow individual courses to be presented differently. The system should allow descriptive text to be included with resources.

Students were asked to complete a questionnaire to ascertain their requirements, the following are the requirements derived from the 25 returned questionnaires and the thinking behind them.

The system should be largely text based with minimal use of images to keep download times to a minimum. (Only 23% of the students surveyed had broadband connectivity at home, with the remaining 77% all having standard dialup connections.) Instructional material should be provided for forum usage. (Only 38% of the students surveyed had any experience of message boards or forum usage.) The system should be easy to navigate and avoid the need to use the back button. The system should contain in-built help. (When asked how they preferred to learn a new computer program, 69% of the students stated that they prefer to explore using trial and error, while 24% stated exploration and the use of in system help as there preferred method.)

Other Highlighted Requirements

The following functionality was highlighted during the requirements capture but was deemed outside of the core functionality. These requirements would be addressed if time permitted after the core functionality had been implemented.

Chat sessions should be run between specified times. Chat sessions should be recorded for review. During chat sessions students should be identified by their names. Only valid students and teachers should be allowed to participate in chat sessions. Instructional material should be provided for chat usage. (Somewhat surprisingly, only 61% of the students surveyed had any prior experience with chat software.) Revision quizzes should be graded upon completion by the system. Final grades should be reported back to the participant. Course teachers should be able to review all quiz attempts. The system should include the ability to provide post quiz feedback.

User Classes and Required Functionality

The head of ICT at LPS School was asked to specify exactly what classes of users of the system were required and what functionality each user class should have. It was decided that three classes of user would be required within the system, each with different levels of functionality available to them. The following UML diagrams show the core functional requirements for each user class.

Solution Development and Initial Testing

This chapter documents the process by which the solution was developed using the Rapid Application Development methodology. As the project was waylaid due to unforeseen circumstances, it was necessary to develop the system in stages each of which added to the last. In line with the RAD methodology, each stage was implemented and made available for use prior to starting the next. The Development Plan To make sure that both the school would have a system that met their core requirements as early as possible and the project was always at a stage were development could cease having met the minimum requirements, the system was developed in four distinct stages. Firstly came the development of the actual Moodle environment and the look for the LPS Moodle. This was followed by the creation of the AA Board Set assignment course. At this point (post stage 2) the core requirements had been met and stages 3 and 4 were included to address the non-core requirements of the school. The following plan was drawn up to aid development, highlighting the content and structure of each stage.

Stage 1. Initial Environment Task 1. Create test plan for stage 1. Task 2. Create initial Moodle environment in line with Schools requirements. Task 3. Create theme based on colour scheme used within existing website. Task 4. Review existing default Moodle user classes, modify to match Schools requirements if necessary. Task 5. Test initial environment. Task 6. Demonstrate initial environment to head of ICT at School. Task 7. Modify, re-test, re-demonstrate if necessary. Task 8. Implement initial environment for use by the School. Stage 2. AA Board Set Assignment Course Task 1. Create test plan for stage 2. Task 2. Create AA Board Set Assignment course. Task 3. Upload resources. Task 4. Upload users. Task 5. Assign users.

Task 6. Create desired forums. Task 7. Test stage 2. Task 8. Demonstrate stage 2 to the head of ICT at LPS School. Task 9. Modify, re-test, re-demonstrate if necessary. Task 10. Create user guide. Task 11. Implement stage 2 into initial environment. Stage 3. Adding Chat functionality Task 1. Create stage 3 test plan. Task 2. Create chat session. Task 3. Test chat session. Task 4. Demonstrate stage 3 to head of ICT at School. Task 5. Modify, re-test, re-demonstrate if necessary. Task 6. Create user guide. Task 7. Implement stage 3 into initial environment. Stage 4. Adding revision quizzes Task 1. Create stage 4 test plan. Task 2. Create revision quizzes. Task 3. Test revision quizzes. Task 4. Demonstrate stage 4 to head of ICT at School. Task 5. Modify, re-test, re-demonstrate if necessary. Task 6. Implement stage 4 into initial environment.

The Testing Platform

During each stage, all development was carried out on a separate installation of Moodle from the final system, running on a computer. Both the testing environment and the final system were created using Moodle with the only noteworthy difference being that the testing environment ran locally while the final solution was accessed remotely via the Worldwide Web. All elements were created, tested and demonstrated using the testing environment and then either uploaded or recreated on the final system. Stage 1 Introduction

The first stage in development was to create the actual instance of the Moodle environment. This involved deciding whether to host the final LPS Moodle environment on a local web server or remotely via a web host, creating the look for the LPS Moodle environment based on the current school website, creating the actual instance of Moodle and modifying the functionality of the default user classes within Moodle to match the requirements of the school.

The Hosting of LPS Moodle With regard to hosting two methods were considered for the LPS Moodle project, these being a local web server located at the school and hosting remotely via a web hosting provider. Although either of these methods would have been suitable for the project, the final decision was to host remotely via a web hosting provider. This method was chosen due to the facts that LPS school does not already run a web server and the technical staff with their current responsibilities would be unable to maintain a secure web server should one be installed at the school. Matching Existing Systems The general look and feel of a Moodle environment is dictated by its theme. The theme is made up off a collection of files that together govern the colours, gradients, text decorations and other effects within the environment. To match the LPS Moodle environment with the existing LPS school website, it was necessary to create a theme that used the same colour palette, fonts and text decoration effects. Via investigation of the schools existing website and significant modification of an existing Moodle theme, a theme was created that was both functional and similar to the existing LPS website for use within the environment.

Creating the Necessary User Classes

Having now created a theme for the environment, it was next necessary to review the default types of user available within the system and modify them to meet the requirements of the school as specified in previous chapter.

By default Moodle offers four types of user class, Admin, Creator, Teacher and Student. The default Admin user class within Moodle, has overall control of all aspects of the system and can do anything and go anywhere within the system, which fits very well with the requirements for the Administrator user class. The default Creator and Teacher user classes are practically identical with the only difference being that a Creator has the ability to create new courses within the environment. As within the LPS Moodle environment, only Administrators should be able to create new courses, the default Teacher class was used to represent Teachers in the environment with the option to allow editing switched on. This option would allow teachers to edit courses that they were assigned to. The final user class offered as default by Moodle is Student, this class of user encapsulated all the desired functionality required for a LPS Moodle Student user. Although the functionality required for the three LPS Moodle user classes was available via the default Admin, Teacher and Student user classes, it was necessary to modify the Teacher and Student classes to remove the ability for members of these groups to alter their passwords. To do this it was necessary to locate all the possible ways in which passwords could currently be changed and modify the Moodle source code to prevent the option from being presented to the user if they are not an Administrator. It was found through thorough investigation that there were three places within the current system where a user could change their password. These were;

On the homepage, the user was given the option to click a button if they have forgotten their password. Clicking this button sends and e-mail to the specified user with a link to the change password function. If the user chose to view their own profile, they were presented with a button that allowed them to change their password. If the user chose to maintain their profile, they were given the option to change their password.

Through reading the technical forums at http://moodle.org, it was found that many other people had the same desire to prevent the changing of passwords. There was however mention elsewhere on the forums of a method within Moodle called isAdmin. This method would return a specific value if the current user was an Admin. By wrapping the parts of the Moodle source code responsible for displaying the button on the homepage, the button on the view profile page and the new password field on the edit profile page, within a simple IF statement with the condition that the current user was an Admin (found via the use of isAdmin), it was possible to only display the buttons and fields required to change passwords to Administrators, thus removing the ability for Teachers and Students to change their passwords. The method for doing this was then reported back to the Moodle community via the technical forums.

Problems found during Demonstration To demonstrate the functionality implemented during stage 1, a simple fictitious course was created to demonstrate that the required functionality for the user classes was present. Although the demonstration went very well and the required functionality was found to be present, it was also noted that the level of detail within the individual profiles needed to be changed. Firstly the ability to change certain fields in the users profile should be limited to Administrator such as Name and Email Address. Secondly certain fields would only confuse the user and should be removed completely such as Digest Type. To achieve this new functionality it was necessary to drastically alter the Moodle source code file responsible for displaying the user profile editing form. The profile display and edit file (edit.html) was modified, again using the isAdmin function. Within the file, the source code responsible for displaying each of the elements deemed unnecessary was again wrapping inside an IF statement with the isAdmin clause, however as this file was a HTML file it was necessary to embed the new PHP code within the HTML form object. Also the form processing file (edit.php) requires that certain fields are passed to it from the form. As several of these fields had now been removed, it was necessary to hard code hidden fields into the form that would pass on the current data held within the user profile and avoid errors relating to missing fields. The following images show the difference between the profile editing screen displayed to Administrators and the screen displayed to Teachers and Students. Student / Teacher profile edit screen

Administrator profile edit screen.

Stage 2

Introduction Now that the environment had been created and agreed upon, the next stage in the development of the LPS Moodle system was to develop a course based around the CBSE Board Set Assignment for use by the current Year students. Course Structure The AA Board Set Assignment consists of four major tasks based around a fictitious sandwich vendor that must be attempted during the CBSE course by all students. These tasks are:

Create a promotional leaflet for the sandwich vendor based around requirements. Create a system for calculating the production cost of sandwiches. Create a website to advertise the sandwich vendor based around provided requirement. Create a system for generating sandwich labels.

For each of these tasks a set of resources (images, data files etc.) are provided by the AA for use within the final deliverables. Moodle allows courses to be presented in three ways. Firstly they can be presented using a weekly structure, whereby the resources and activities are structured into the relevant week in the course where they are used. Alternatively courses can be structure using a very minimal structure whereby all resources are located in a single area. Finally courses can be structured by topics where areas containing the used resources are created for each individual topic. As the AA Board Set Assignment is structured around four key elements, the topic based structure was deemed most appropriate with an area created for each individual topic and an area for resources that are more global than topic specific. Under the supervision of the Head of ICT, the relevant resources for each topic were added into the course structure and forums were added to allow students and teachers to communicate outside of usual classroom hours and to allow students to report bugs and make suggestions about the environment.

Moodle Blocks Along with the course resources and forums, several Moodle blocks were included in the environment to accommodate the requirements for specific functionality. The Calendar block was added to provide the ability to maintain a course and individual calendars. The Recent Activity block was added to allow students and teachers to be alerted to new content and forum postings.

Stage 3
Introduction During the requirements capture phase, the desire to hold real time chat sessions was expressed by several members of the ICT staff, to allow real time question and answer sessions to take place outside of regular classroom hours. Although this functionality was deemed outside of the core requirements for the environment, this was added as an extension after the core functionality had been implemented within stages 1 and 2. The Implementation of Chat Session After the core functionality of the system had been addressed, a chat session was introduced into the system to allow students and teachers to communicate outside of regular classroom hours. The idea behind this addition was that regular advice sessions would be made available to students through the environment where teachers would address students questions and concerns in real time and students could be encouraged to assist each other. To demonstrate the functionality available within the Moodle real time chat module, a chat session was created on the test platform and accessed via several web browsers all logged into the test system as different users. This chat session was then used to demonstrate how the real time chat session would work. Problems found during Demonstration During the demonstration, two issues became apparent. Firstly within the Moodle chat environment users are provided with the ability to make other users machines beep via a link next to each users details and a command line option. This functionality is provided to gain the attention of desired users. It was felt however by the Head of ICT that this facility would be abused by students if made available to them and should therefore be removed. It was also noticed during demonstration that only first names were used to identify speakers. This would mean that if several users all shared the same first name

and were using the system at the same time, it would be difficult to identify which user was communicating. As Moodle offers no option to switch the beep function off, to address the issue of the beeping, it was again necessary to inspect the Moodle source code although this time it was the code responsible for the chat functionality. After spending many hours trying to remove the beep functionality completely, it was decided that this was too difficult to achieve. Therefore an alternative solution was derived whereby the link used to activate the beep function would be removed completely from the system as well as any reference to the beep functionality within the Moodle help documentation. This was deemed sufficient, as when the chat functionality is added to the live system, users would never have experienced the beep function and the chances of them guessing the command to use at the command line would be very slim. This issue would have to be reassessed should the students become aware of the beep command. To modify the chat system so that it displayed the full name of the speaker rather than just their first name, it was necessary to first locate exactly where the display of messages was being carried out. This proved to be very difficult to locate as the source code for Moodle is very poorly commented. Although once located the modification was very simple to administer.

Stage 4
Introduction Another functional area highlighted during the requirements capture but deemed outside of the core functionality, was the inclusion of revision quizzes based on official past examination papers. This functionality was the last to be added as revision was deemed more likely to take place during the later stages of the academic year. The Implementation of the Revision Quizzes As the initial student user base were CBSE ICT students, revision quizzes based around the latest CBSE foundation and higher level papers were created using the Moodle quiz module. After researching appropriate questions and discussion with the head of ICT, it was decided that a series of multiple choice quizzes would be most appropriate with feedback upon completion. It was also decided at this time that correct answers should not be given at the end of the quiz, instead advice about errors should be given. This

would allow students to attempt the quizzes again at a later date having reinforced their knowledge.

Solution Implementation and Student testing

As mentioned in the previous chapter, the final system was developed as a series of stages each of which were implemented into the final system after creation, testing and demonstration on a testing platform. This chapter documents how the final LPS Moodle system was implemented, tested through use by the ICT teachers and students at School and the problems that occurred during this process. LPS Moodle Implementation During a discussion with the Head of ICT, it was decided that due to the complexities and work required to install and maintain a web server, the most appropriate method of hosting the LPS School moodle installation would be via an external web host. Several web hosts were considered using the following criteria:

Cost The hosting should be inexpensive at this stage to avoid unnecessary costs to the school should the final outcome of the project be unusable. Features Moodle requires that MySQL and PHP be available on the web server. Bandwidth As the system will contain a large amount of content and the possibility of real time chat sessions, the system may require a large amount of bandwidth which is often limited by hosts.

The final outcome of a short period of research into potential web hosts was the decision to use a company called net4domains.com. This decision was made due to the low cost (2500 per annum), high specification (MySQL, PHP), and high bandwidth provided by the company.

Having now acquired space on a web server, the next stage in the implementation was to create an identical Moodle installation to the test installation, on it. This involved creating a default installation of Moodle and migrating the created theme across from the test server. Next the files modified during development stages 1 and 2 were copied across to overwrite the default functionality and the AA Board Set Assignment created during the development stage was recreated on the new installation. At this point the test and final environments were identical. The final operation prior to LPS Moodle going live was to create the necessary user accounts and assign the necessary privileges. LPS Moodle Test Users It was decided that the final implementation should be tested via usage by the current CBSE ICT classes. To allow this, details of the technical staff, teachers and students involved were provided via a comma separated file generated from the schools active directory server. This file was modified to allow the records to be uploaded into Moodle and used to create the initial user accounts. This process created accounts for the two technical staff, three teachers and thirty two student users that were all involved in the current CBSE class and the AA Board Set assignment. LPS Moodle Testing On Jan the 21st, the testing students were introduced to the LPS Moodle environment during an ICT class. This introduction included a walkthrough of how to log into the site, how to move around the site, how to modify the user profile and a discussion of what the system is for. Students were made aware of the forums within the environment and asked to share their problems, solutions and views with other students via them as well as posting any technical problems or issues to the bugs forum. From this point on, the LPS Moodle installation was used by the students to assist with the AA Board Set assignment.

Problems found after Stage 2 Implementation

With the system no being used by students and staff at LPS School, the following issue became apparent that was not observed during the development of the system or the testing on the test server. Very early on, students reported that they were often unable to get passed the login screen when trying to enter the environment. After several failed attempts to recreate this issue, the official Moodle forums (moodle.org) were consulted,

were it was documented that the problem was caused by a caching issue with Internet Explorer. Two solutions were provided for this issue. Firstly the security settings within Internet Explorer could be modified to allow certain cookies and prevent caching of Moodle pages. This solution was inappropriate as the school required the security to be set at a high level within Internet Explorer and at home all students would have to make major changes to their browser settings.

The second solution provided was to drastically modify the headers sent from Apache to the requesting browser. Although complex instructions were provided, this solution was inappropriate as it involved modifying the web server settings which were not available due to the system running on an external web host. Although an appropriate solution to this problem was never found, it was discovered that when this issue occurred, the user was in fact being logged into the environment and could access the resources. To counter this, users were made aware of the problem and instructions were provided as part of the login screen.

Stage 3 and 4 Implementation

In March, the Chat functionality developed during stage 3 was added to the environment as a Wednesday evening advice session. The idea behind this session was that teachers would be logged into the chat session and would answer students questions as they were asked. These sessions continued to run through March but were changed to monthly session in April due to other teaching commitments. During early April, the quizzes developed during stage 4 were added to the environment to aid with revision. As an exercise students were asked to attempt these quizzes as part of a homework exercise. On completion, the results would be reviewed and used to gauge areas that might need reviewing. Problems found during Stages 3 and 4

During stage 3, several students complained about being dropped from the chat session at random times. This again was a problem that had not occurred during the testing carried out during the development on the testing platform. Students stated (through the bugs forum) that at random times the panel containing the details of current participants would display an error stating that the database was overloaded or missing. This would cause the chat session to crash and drop them from it resulting in the student having to close the session window and re-enter. Initially it was thought that this was simply a problem with users being timed out due to being idle. Moodle Chat sessions use this function to remove users who have terminated their connection to the session. Basically if a user is deemed to have taken no action for a significant amount of time (5 minutes by default) then they are removed from the session. Again through research using moodle.org it was found that this idle timeout could be extended by modifying certain variables within the chat session code. This modification was carried out but proved unsuccessful in curing the problem.

After significantly more research into the problem, it was found that it was caused by the amount of concurrent database connections required to sustain the chat session. When many users were engaged in a chat session, the database was being overloaded at the web server and was causing this problem. Again this problem could not be solved as the hosting company were unable to remedy the issue and the only alternative offered by the Moodle creators was a daemon version of the Chat module. This daemon version would provide greater stability but required installing as a background application on the web server, which was inappropriate given the current hosting solution. Unexpected Benefits During March a large number of students were snowed in at home and unable to attend school. During this time several chat sessions were used by the Head of ICT to help students catch up on missed work and allow them to continue with their assignments while away from school. Although this facility would be wasted on less motivated students, due to the maturity and respect of the students at LPS school, the sessions proved to be a great asset resulting in several students being able to keep up with the rest of the class. This also highlighted the fact that as long as the student was suitably motivated, the environment could be used to assist students who may be absent through no fault of their own such as illness.

Solution Evaluation
As the main purpose of this project is to ascertain whether Moodle is capable of meeting the core requirements of LPS School, this chapter looks at the final solution compared to the core requirements highlighted in previous chapters. Each requirement is addressed in turn and evaluated as to whether it has been met, could be met under different circumstances or has failed to be met by the final installation. Evaluation of Solution against Core Requirements The system should only be accessible to valid students and staff. By removing the guest access from the system, only students and teachers with a valid account and password can gain access to the content within the environment. As existing (and presumed secure) usernames and passwords are used, access is unlikely to be gained via guessing username/password combinations.

Login instructions should be given on the homepage. Prior to the discovery of the login problem, simple instructions were provided on login screen. After the discovery of this problem, these instructions were improved to include details of the problem and the solution. The system should use existing usernames and passwords. Users were entered into the system using a comma separated file generated by the schools active directory server. This file contained the existing usernames and password. The system should not allow students or teachers to change their passwords. Via extensive modification, the ability to change passwords has been limited to administrators. The system should be reliable. Although the current system is usable and is indeed being used, there is a possibility that if and when the system is rolled out to more subjects and users across the school the database connectivity issue found during use of the chat functionality will surface during usage of the main system. The solution to this issue would be to either change the hosting

of the system to a host that specifies Moodle support as one of their services at a significantly greater cost or to run the system from an internal web server within LPS School with a significantly greater workload for the technical staff. The system should be secure due to the sensitive nature of the stored information. By hosting via an external company, the system is somewhat dependant on their security. To counter this unknown, no information deemed sensitive has been included into the system. This includes personal photos, address and telephone numbers. The system should be accessible via the existing school website. The existing school website should be accessible via the system. A link to the system has been added to the existing school website and a link to the website has been included in the system.

The system should be simple to patch when required The open source Moodle project is constantly under development with minor updates being released on a very regular basis. The updates are made available through the official Moodle web site and if the Moodle installation is registered, through email as they become available. To apply these updates it is either a case of running the provided installer or manually overwriting certain files within the Moodle installation. It is important to note one key issue however. As several of the files within the current system have been modified to provide the functionality required by LPS School, updating these files would result in the loss of these changes. This means that either updates which modify these files must be avoided or the changes contained within the current system will need to be reapplied whenever the modified files are replaced which may be beyond the abilities of the schools technical staff. The system should allow students to create and maintain a profile. By default, any installation of Moodle allows users to maintain a complex profile containing personal details and individual settings for the environment. The default profile was deemed too complex for the teachers and students at School so was reduced to meet the requirements specified by the school during the project. The final profile available to both students and teachers allows these users to maintain an identity within the system and hence feel a part of the LPS Moodle experience, but reduces the complexity to a minimum to avoid unnecessary confusion.

The system should record usage statistics. By default, Moodle records all actions from login to logout that a user performs within the system. These records can be used to display activity from a specific day, a specific activity, a specific course, a specific user or a combination of these. Also all Chat sessions are recorded within the system and can be reviewed at leisure by users with administration rights. Finally as the recorded data is stored within a single MySQL database, it would be possible to further mine the stored data using complex SQL statements. The system should allow resources to be presented in a structured manner. The final system and Moodle by default, allow courses to be presented in several structured fashions including a weekly structure whereby the course is divided into weeks and a module structure where the course is presented as a collection of modules. The system should allow learning to continue outside of regular classroom hours. To ascertain whether or not the final solution meets this requirement, it was necessary to both identify whether the system provides functionality that can be used to continue teaching and learning found within LPS School, outside of the standard classroom hours and to review the logs generated through usage by the school to identify actual learning that has taken place. As identified previously, LPS School uses both Indirect Instruction and Social Constructivism to teach during regular school hours. During research into teaching styles was carried out which highlighted what was required to teach in these methods. It was written that to teach via Indirect Instruction a teacher must present the students with materials and exercises that allow them to go beyond the simple facts they have been taught. Moodle allows several file formats to be used as resources as well as links to external websites to be included within the course, allowing teachers to include materials and resources that allow teachers to take there learning beyond simple facts. As the final system has been created to be easily identifiable as an asset of LPS School and the system allows courses to be structure in a manor appropriate to the course, i.e. 4 modules within the AA Board Set assignment represented by 4 separate areas of resources, it can be said to mimic an authentic real world environment. By allow students to openly participate in discussions via forum posts and to maintain an identity within the system, the students are encouraged to take responsibility for their actions within the environment including their learning. As forum posts are persistent, the knowledge held within them is always available to course students.

To prove that learning had in fact already taken place within the environment during the user testing, the activity logs form the LPS Moodle environment were reviewed with the following result. During the 2 months in which the system has been in use, 17 questions have been asked relating to the AA Board Set Assignment with 37 replies requesting the same information or providing possible answers to the original question.

The system should allow display or download of existing PDF documents. The system should allow display or download of existing Microsoft Office documents. The system should allow display or download of graphical images. The system should allow working web links to be used. Moodle allows practically any file type to be uploaded as a resource for use within the system. The only real limiting factor is the size specified for maximum upload within the environment. Within LPS Moodle, this is set to 2 megabytes. Also the Moodle environment allows links to be used to navigate to external resources either as a new browser window or within the current Moodle pane. The system should allow communication outside of regular classroom hours. As the final system is available for use by students and teachers at any time, communication via the forums can take place outside of regular school hours. Also with the inclusion of the Chat functionality, real time chat sessions can be used to provide real time communication whenever required. The system should allow resources to be hidden from users. Moodle allows resources to be made invisible to the users without course editing priveliges.

The system should allow individual courses to be presented differently. Via the inclusion of introduction text and images, courses can be given a certain degree of flexibility that allows them to be presented in a different manner.

The system should allow descriptive text to be included with resources. During the creation of a resource and its inclusion into the system, the environment allows descriptive text to be added. The system should be largely text based with minimal use of images to keep download times to a minimum. Images within the site and required for the AA Board Set assignment were kept to a minimum when displayed or if complex made only available as a download. Students found that page loading times for the final system were perfectly acceptable even when viewed through a standard dial-up connection. Instructional material should be provided for forum usage. As only 38% of the student surveyed during the requirements capture phase had any experience with forum usage, a basic guide to the forums was created and made available to the students through the environment. The system should be easy to navigate and avoid the need to use the back button. Moodle uses a system called breadcrumbs to provide a continually updating navigation chain that can be used to return to previous sections of the environment and is always present when within the environment. The system should contain in-built help. Moodle contains a thorough help directory that can be customised to provide specific help as required. The majority of Moodle functions and functional areas have help text associated with them via a simple graphic.

Project Evaluation

Within this chapter, the project has been evaluated against the minimal requirements specified and an evaluation of the project stages has been carried out. Also conclusions have been drawn and suggestions for further work documented. Evaluation against Minimum Requirements A literary review of existing material on the subjects of teaching, learning and Virtual Learning Environments.

Earlier, teaching styles, learning styles and Virtual Learning Environments were discussed. It was found that three styles of teaching exist within modern schools, Direct Instruction, Indirect Instruction and Social Constructivism. This knowledge was then used to research the teaching styles used within the host school and to ascertain whether the final solution was capable of allowing these teaching styles to continue within it. A requirement document generated through interview with problem holders. Previous chapters document the requirements capture process used to develop a set of core requirements for the proposed system. Several interviews were used to gather requirements from the technical staff and teachers at LPS School and student requirements were derived from the results of a questionnaire filled out during an ICT lesson. These requirements were then listed within chapter 4 along with the functionality required for each user type.

An open source Moodle solution customised to meet core requirements and to match existing systems within the chosen school. During the course of the project, a Moodle installation known as LPS Moodle was developed for the School. This final system was designed to match the existing school website and to provide the core requirements highlighted during the requirements capture phase of the project. As an extension to the project, addition functionality was added to the solution to cover non core requirements gathered from the requirements capture phase such as Chat functionality and revision quizzes. Deployment of the solution for use by the chosen school. As the project was developed using the rapid application development methodology, the final system was made available for use by School at a very early stage during development. LPS School continued to use the final solution while the project continued to develop and have now upon completion of the project taken complete control of the environment. An evaluation of the final solution against the specified core requirements. Chapter 7 of this document is an evaluation of the final solution against the core requirements gathered during the requirements capture phase. Here each requirement is addressed with respect to the final system.

Evaluation of Project Stages

To ascertain whether each stage used within the management of this project was appropriate, the following section identifies each stage of the project and highlights whether the way in which the stage was carried out was a benefit to the project. Chosen Methodology The methodology chosen to manage this project was Rapid Application Development. This methodology was followed throughout the project and proved invaluable as the course created within the project (AA Board Set assignment) was running while the system was being developed. By following the RAD methodology, LPS School were able to gain benefit from the system at a very early stage and the development was able to progress at a steady rate and in a modular fashion. Background Reading The background reading carried out during the project was an invaluable aid. Having had no experience of teaching techniques or Virtual Learning Environments it was important to research these subjects to avoid embarrassment when discussing the environment and pedagogies involved within it and the host school. This knowledge was used continually throughout the project to ensure that the pedagogies found within the school could continue to be used within the environment.

Requirements Capture The requirements capture phase of the project involved highlighting the users groups involved within the system and capture the requirements of each of them. To capture the requirements of the technical staff and teachers, interviews were used. These interviews allowed elaboration and adhoc questioning to take place although proved very difficult to organise due to the busy schedules of the people involved. To capture the requirements of the student users, a questionnaire was created. This questionnaire was handed out during an actual ICT lesson resulting in a very high return rate and the questionnaire being answered in a serious fashion. The data gathered from the completed questionnaires was then used to derive the core requirements for the student users. Although a lot of requirements were generated from the interview with teaching staff, ideally a broader range of teaching disciplines would have been used to gather requirements for a school system rather than a system based around the ICT staff.

Solution Development The final solution was developed using the Rapid Application Development methodology to allow the core requirements to be implemented and tested while development continued. This was important due to the problems encountered during the project and to make sure that the minimum requirements for the project could be met if further problems ensued. This process worked very well as Moodle is module by nature and fitted the concept of Rapid Application Development very well. Solution Implementation Again in line with the Rapid Application Development methodology, the final solution was implemented and made available for use by School in a modular fashion. As each stage of development was completed, the final installation was updated with the new functionality. This method along with the continual user testing allowed the system to be used while problems were being overcome that became apparent during the user testing. This technique also allowed LPS School to gain the maximum amount of benefit from the AA Board Set assignment course as they were able to start using the system at an early stage of the AA assignment. If the project had been managed using the Iterative Waterfall model as first decided, the final solution would most likely not have been made available for use until a much later stage of the AA assignment. Conclusions This project has proven that Moodle can be used within a School environment and can be modified to meet the core requirements of the host school, namely LPS School which were the primary questions that the project proposes to address. The changes made to modify the functionality will be scalable when the system grows. It is however a concern that problems that are currently very infrequent will become an issue when the environment is developed to include further courses and subject areas. On major issue has become apparent during the course of this project. The changes made to the functionality of Moodle during the project have all involved skills vastly beyond the knowledge and ability of the average school technician or teacher. Through discussion with the LPS School ICT staff it was found that ICT teachers with a degree in a technically subject such as Computing or Computer Science are very rare and most have a degree within the area of Education. From a programmers point of view the Moodle source code is very poorly documented and often required several thousand lines of code to be examined before a solution can be conceived. So in reality although Moodle can be modified to meet the core requirements of a School, these modifications would require either substantial learning or the use of an external body. Suggestions for Further Work

The current implementation of LPS Moodle is limited to the ICT subject area. Further work could be carried out into the usability of the system from the point of view of other subject areas such as Maths or Foreign Languages. Moodle generates a vast amount of data relating to the activity within the environment. Within a system that had been running for a substantial amount of time, this data could be analysed to ascertain and quantify the actual benefit of a Moodle environment to the host school. This would very likely require a timeframe beyond that offered by a final year project and would probably be more suited to a research project where the current situation could be analysed, a more comprehensive Moodle environment developed and after a period of time the effects and benefits of the environment could be ascertained. Finally Moodle contains functionality that has not been deemed unnecessary for this project. This functionality could be researched and used to further develop the LPS Moodle environment.