7.6. System Resilience
Reliability has to be one of the core attributes of an MLE. The nature of MLEs - enterprise-level systems joining together key academic and administrative processes - means that any hardware or software failure is likely to have a considerable impact.
An MLE needs to be resilient against
hardware or software faults
changes in requirements
changes in back-end data sources
changes in personnel
Resilience needs to be designed into the system at each stage of its development:
hardware specification and configuration
software design
testing
documentation
7.6.1. Hardware specification and configuration
It is not possible to produce a detailed set of recommended hardware specifications for an MLE. Existing systems vary greatly - not only in terms of the numbers of users, but also in the type of content delivered (i.e. how much of it is static or and how much obtained dynamically from back-end systems, whether it includes interactive or multi-media elements, etc.)
MLE developers have had to make educated guesses about hardware requirements, but have generally applied the following principles to try to ensure system resilience:
Include redundancy in the system - i.e. multiple interchangeable components to perform a single function in order to cope with failures and errors;
Over-specify - so the system is not working to full capacity all the time, and can cope with spikes in demand;
Ensure that the system is scalable - so extra capacity or processing power can be added easily if the load on the system increases, or has been under-estimated.
Developers have to choose one of two basic architectures:
The 'Big Box'
Load balanced/clustered
Bristol University's Portal Project has assembled a useful collection of extracts from mailing lists and other sources where the two approaches are discussed - often with details of the hardware used. These may be found in the Key resources for this section.
7.6.2. Software Design
The scale and complexity of an MLE will mean that software is written, debugged, maintained and further developed collaboratively. Therefore it is essential that good design principles are applied i.e. it should be modular and use standardised components where possible.
MLE software needs to be simple and robust. There can be pressure to use 'work-arounds' to speed up the implementation process, but these are counter-productive because they greatly increase the effort required to support and maintain the system. For example, De Montfort University has had to postpone the introduction of several of the functions developed for its MLE - even though they were piloted successfully - because currently
They rely on processes that were difficult to scale - e.g. manually uploading data to the MLE from a back-end system; or
The function worked well for one faculty or department, but could not be applied across the whole institution.
Several projects have chosen to use toolkits or development environments which offer the required flexibility but also simplify some of the basic tasks, encouraging modularity and standardisation, e.g.
- Tool: uPortal
A set of Java classes and XML/XSL documents for producing a campus portal (More details:
http://mis105.mis.udel.edu/ja-sig/uportal/ )- Used by:
- DMU MLE; MARTINI
- Tool: Zope
Application server, written in Python, for building content management systems, intranets, and portals. (More details:
http://www.zope.org/)- Used by:
- SMILE
- Tool: ColdFusion
A tag-based scripting tool for developing data-driven Web sites. (More details:
http://www.macromedia.com/software/coldfusion/)- Used by:
- GIMIS
The GIMIS Project uses a standard approach to developing in ColdFusion, which is set out in their Tag Based Web Development Programming Guide (See Key Resources.)
De Montford University changed to using uPortal after first developing a completely in-house MLE. The perceived benefits of using uPortal were:
It provides standard format/process for building and and adding channels - enables division of labour
It enables the separation of presentation and business logic
It provides some standard Portal functions 'out of the box', e.g. setting personal preferences, bookmarks, announcements
Increased credibility - examples of successful implementations; VLE vendors interested in developing links.
Another advantage of Coldfusion, uPortal and similar tools is that they each have a body of knowledge which projects can draw on, in the form of
Experienced developers
Technical manuals, guides, and support forums
Training
7.6.3. Testing
At De Montfort University, testing of the MLE has identified a range of issues, including potential technical problems. The Report on Evaluation of the MLE User Interface includes a section on Summative Evaluation - carried out once the main development phase has been completed. The following methods are used:
cognitive walk through
heuristic assessment
observational study.
(See Key Resources for more information.)
The GIMIS project has provided a Testing Guidelines document. This defines the following types of testing:
Functional (black-box) Testing - i.e. testing that the program does what it is supposed to do, and does not do what it is not supposed to do.
Structural (white-box) Testing - concerned with the degree to which test cases exercise or 'cover' the logic of the program.
Integration testing - checking for errors related to the interfaces at unit, sub-system and system level, or related to data transfers in the system.
Acceptance tests - involving the client, and testing the functionality of the system as stated in the requirements specification. (See Key Resources for more information.)
7.6.4. Documentation
MLE development needs to be underpinned by comprehensive documentation. This has been explicitly addressed in the GIMIS Project, which has produced a set of standards for Document Control (See Key Resources.) The rationale is explained in the Introduction to this document:
There is a need for documentation control on all projects or service agreement provision. The need varies depending on the size of the project or service provision, however it is essential that all documentation is:
Easy to use
Of high quality
Controllable
Uniquely identifiable
Of a common style
Transferable between users
It recommends documents should include the following information on every page:
Document title
Document reference
Document version and, where applicable, document revision
Issue date (not print date)
Page number
and the following information on the front page, or control page:
Status (draft for comment or definitive)
Total number of pages
Contents list
Amendment history (or issue record)
Author of the amendment
Approval, authorisation and client signatures, if required.
A synopsis may also be added to the document front page if required
Logos and copyright information can appear as required
