I’ve stated before that I think online educators should consider developing using a simplifed software engineering model. My rationale here is that online educational experiences may often be similar in many ways to software applications particularly if they involve multi-media elements and/or assynchronous learning where the educational experience may be accessed by the students independently of the learning facilitator.

The following image comes from the website of a software development company called Sciencesoft , and illustrates the software engineering process in a manner which is fairly easy to relate to the development of online educational resources.

The Sciencesoft model is intended for fairly large software projects. In the discussion that follows I am assuming that the developer is developing a fairly small scale educational resource that is one component of an online learning programme, however I believe that the same process can be applied to a larger-scale project with some modification.

Define Project Scope

I see this stage being an initial planning stage where the developer will consider factors such as

· Course learning outcomes and how the online educational resource (OER) will help students to meet them.

· How these outcomes may be assessed (e.g. can this process be automated, or does the nature of the assessment mean that it requires the judgement of a course facilitator)

· Communication technologies which may be used

· Nature of the user interface

· Learner profile

· Needs of the students for scaffolding or support (either technical or educational)

· Development budget


This model separates development into three stages – design, implementation and integration.

In this stage the developer will determine which components will be required in the OER, how they will work together. A search for pre-existing components that may be incorporated within the OER would take place at this point.

In the implementation stage the developer will create the first working version of the OER.

Integration in software development is where all of the components of a software development are brought together to operate as a complete unit. This will probably not be necessary in most online educational development because learning resources will typically operate independently without needing to pass data to other learning resources (as components of computer programmes do).

(or testing)
Testing is an essential part of the software development process, and it is something that seems to be lacking or perhaps not understood in online education. If an OER is to be used independently of the facilitator, it is essential that the resource is thoroughly tested before any students use it. Ideally a tester should consider all of the possible pathways that students can follow within the OER and ensure that all of them work (consider online tests, auto-feedback, hyperlinks, etc.). This can be a fairly time consuming process, but is important if preventing student dissatisfaction is considered important.

Deliver Product to Customer

Once the OER has been thoroughly tested, it can be released to the students to use.

Maintenance & Support
Most OERs will require a certain amount of maintenance. Hyperlinks need to be updated, software updates may wreak havoc with something that worked perfectly well beforehand. A developer should bear this in mind & consider how much responsibility they are prepared to take for this. For example if you create a resource that other teachers with less technical competency than you are using it’s quite likely that they will be unable to fix it when it breaks down. Will you be prepared to commit to the ongoing maintenance of the resource? When a programme has a fairly large online component is it worthwhile employing a staff-member whose role is purely to check & maintain learning resources?

It’s also worth considering what support the students may need to access the resource, and to use it effectively. What supports are in place, and are any additional supports required?

Non-linear development

It’s worth nothing that development should not be expected to occur in a linear fashion starting with the definition of project scope and progressing stage by stage to finish with maintenance and support. It is quite likely that development can jump back to a previous stage. For example in the Stabilisation (testing) stage it’s common to find a problem with the OER. Depending on the nature of the problem the developer may need to jump back to the implementation stage, the design stage, or even the definition of project scope.