4.3. Constructing Models
4.3.1. Introduction
The formal creation of a conceptual model describing the functionality of the intended MLE needs to happen relatively early on in the design process. However, even before this takes place, you are likely to have undertaken several activities which will have informed the modelling team.
It is to be hoped that your institution, having decided to introduce e- learning, will have built this into the strategic plan based on a sound business case for its implementation. The business case would include reference to the creation of an MLE for the delivery of e-learning and therefore an outline conceptual model would already be in existence which describes the basic functionality of the system and the intended users.
This outline model will probably come from knowledge of existing MLEs in other institutions and information from such sources as JISC. It is also likely that the institution will have some experience of the use of key MLE components such as a VLE, although the knowledge and experience may be confined to a few specialist staff. The model at this stage is likely to be aspirational, encompassing all the different planned modes of student engagement with learning and the levels of support they will be offered. It will, either implicitly or explicitly, be structured to deliver the intended pedagogic approach favoured by the institution.
There are different levels of conceptual modelling in systems design. The MLE design team will create a model which describes the overall system, its components, functionality and features. Additionally, conceptual models of sub-systems will need to be formed to capture the viewpoints of each of the key stakeholders and the job of the design team will be to ensure that these individual models are catered for in the overall design.
4.3.2. Conceptual Modelling
The task for the design team, in creating a formal conceptual model of the MLE, is to develop a comprehensive systems descriptor which defines what it is intended to do and how it does it.
At the most basic level your MLE may consist of a virtual learning environment (VLE) such as Blackboard or WebCT linked to your student records system. A more complex model may envisage integration with other systems such as library, timetabling, assessment and staff records.
Robertson describes a template for a requirements specification which provides a complete description of a product's capabilities. You can adapt this to create a useful framework for specifying a model MLE, classifying the requirements in terms of:
Functional requirements (what the MLE is intended to do and how it does it)
Non-functional requirements (look and feel, performance requirements, political and legal requirements etc)
Characteristics and constraints (the business case for implementing the MLE, the owners, users and customers, the naming conventions, budgetary limits etc)
Development issues (the project plan and responsibilities, re-use of existing models and MLE components, evaluation of vendor products etc)
The design team will identify the stakeholders and will include in the model a description of the activities and communications that each will undertake with the MLE. This will later be tested with those stakeholders.
Checkland calls these descriptions Root Definitions of a human activity system which capture a particular viewpoint. There are a number of individual conceptual models each of which must be included in the overall model.
Espejo similarly stresses the importance of including all viewpoints, not just the direct users of the system:
'Insightful solutions developed by a group of participants, perhaps through a highly regarded problem-solving process, can often be frustrated by the structural realities of the organisation in which they operate if they are not taken into account.' (Espejo, R. (1989) A Cybernetic Method to Study Organisations. In The Viable System Model. Ed: Espejo and Harnden. Wiley. P361.)
The models relating to individual viewpoints are often referred to as prototypes and the developing and testing of prototypes is extensively covered by Maguire (Maguire, M. C., (1998) User-Centred Requirements Handbook. Deliverable 5.3, Requirements Engineering and Specification in Telematics. Part B, Phase 2, Prototype and User Test.)
Your design team can use a number of techniques to describe their conceptual model and diagrams are likely to feature strongly in the documentation. A good example of how this has been applied in the design of an MLE can be found on the De Montfort University Managed Learning Environment Project web site. The MLE Architecture Overview document available on this site summarises their approach.
The use of diagrams in the design of MLEs is also discussed by Holyfield. A number of useful examples are provided in this report, which can be accessed through the key resources for this topic, and their value discussed as well as some potential disadvantages.
At a more advanced level of analysis, design teams will find value in Beer's Viable Systems Modelling methods which are aimed at optimising communications and control capacity in human activity systems. The CoManTLE Project report 'Research Framework: Modelling the Organisational System' recognises the complexities of introducing an MLE across a large institution and explores the use of formal systems analysis including viable systems modelling.
Follow this link for key resources for this section (these open in a new window)
