6.3. Design Process
Having gathered a set of criteria we need to wrap this all into a process. The process must, on an on-going basis gather and track the criteria and turn them into designs, plans and schedules that evolve with the project and the stakeholders.
The design criteria and its gathering may also be part of the same process. There are many different methodologies for managing a systems design process, and you may have a favourite in mind. If your favourite, has worked in the past, and is well understood by your development team, then it forms a good starting point. If you do not have one, we will suggest some later in design methodologies.
The things that make MLEs much harder to develop and deliver well is the open nature of the process. The MLE bonds a variety of different systems together across an organisation and that is an open system with constant variation. So we need to pick a methodology and a project management approach that reflects that.
6.3.1. Architecture
A really good paper to read is from the IBM Systems journal, (see the key resources for this section) this gives a very good overview of the information architecture concept and it is relatively easy to see how this can be applied to your MLE project.
The architecture of your MLE is again about ensuring everyone needs to know the right things at the right time and dealing with changing requirements.
6.3.2. Interfaces
A big question for many MLE designers is where does the MLE stop? Your MLE could include a vast range of services and data sources. The JISC INSIDE project based at St. Andrews and Durham identified over 50 possible candidate systems for inclusion in their MLE. The question for you will often be what is 'in' and what is 'out'.
A good technique to use to resolve this is to identify what interfaces each system has. If there are a number of similar systems then, after the first one, you may find that the others integrate very easily. A key outcome from the JISC funded MLE programme is - 'do a small number of things well', rather than trying to be comprehensive and having to reduce the quality.
6.3.3. Causal relationships
In computer science there is much research in to the causal relationship between systems, for example when one system in your MLE does something, like enrol a student, then another set of systems all have to follow the process through. An example from enrolling a student might be:
Enrol student (student records)
Create debt in the finance system (finance)
Allocate course units and timetables (timetabling)
Enter the student of the health centre database (Patient records)
Print library card (library system)
Notify supervisor (enrolments)
etc.
This chain of systems is something the MLE will have to interact with, and these relationships need to be understood if you are going to make the system meaningful. Some parts of the process can happen in parallel and some parts are sequential, understanding how your own business processes work is important if the data you deliver is going to be meaningful. The problem of causality is a big issue where human intervention is required, for example where a lecturer has to sign off a course structure before the modules for a student can be added to the various systems. This process may take days and your MLE needs to understand and cope with it.
6.3.4. RAD methodologies
RAD (Rapid Application Development) methodologies are a class of approaches which differ from traditional engineering approaches by having a relatively fast interactive approach to development. If you do not already have an interactive design approach you may want to consider DSDM - Dynamic Systems Design Methodology. This is becoming a common approach in the UK and it has both good books and training courses available. The NCC (National Computer Centre is championing the use of DSDM and have a number of relevant resources.
No methodology is perfect however and the technical factors and the skill set of the developers will have an impact on the choice of methodology. Different methodologies favour different tools, programming languages and emphasise different parts of the design process.
If you are going to use Java then there is a wealth of material available on the methodologies that can be used. UML (Unified Modelling Language) and OODM (Object Oriented Design Method) are probably the most well known. You should consider them or at least facets of them if you are using Java.
A note of caution is that the transition from procedural languages like Visual Basic and C to object oriented languages like Java or C++ is not trivial for most programmers, and this will need to be borne in mind when selecting a methodology. If the methodology is design for object oriented use you may have to retrain and retool the development team. This can be a positive agenda for change or an unnecessary diversion, but either way it will be expensive and time consuming.
Follow this link for key resources for this section (these open in a new window)
