|
Quick Links
Engineering
|
Engineering E-Learning |
|
The Challenge of E-Learning DevelopmentIn recent years course developers and instructional designers have been adapting to developing and delivering e-learning. Many of them accepted this challenge with reluctance and uncertainty of how they would adjust. Fortunately many companies were willing to facilitate the adjustment by providing tools and systems to make it as easy as editing a document on a word processor. Still the whole process of developing self-paced courseware on-line took on a whole different approach to instructional design. The process has been complicated with innovative approaches to learner interactions within the on-line courseware. The interactions may have been produced easily with tools such as Macromedia Flash, or may have been produced by programming in Java, JavaScript, ASP, XML, etc. Whatever the case may be, the fact remains that developing e-learning is becoming more and more like developing software. For this purpose the whole e-learning development process needs to become more of a marriage between traditional instructional design and software development methodology. Does this mean it needs to be complicated? Hopefully not, the idea behind any process is to simplify tasks to make the entire process more efficient, but it also needs to be thorough to eliminate potential oversights. Instructional Design BasicsSo how do we apply a software engineering approach to instructional design?
First we need to review a high level overview of each to have proper frame
of reference. Let's begin with a basic instructional design model, such
as Dick and Carey. The performance objectives are then used to develop criterion tests which are designed to test that the student can achieve the expected performance objectives. The instructional strategy is then developed to determine the appropriate methods and media in which to deliver the content. The content is then developed based on the instructional strategy or storyboard. The course design is then tested in a pilot class and an evaluation of the course design is reviewed. The course is then revised based upon the results of the pilot delivery. The course is then delivered to the masses and evaluated on its effectiveness towards the expected impact. Software Engineering BasicsIn software engineering the approach is similar in some aspects. The process starts with a definition of a system based on a set of requirements
or goals that the system is expected to address. This usually results
in a system specification document that describes what the system should
do. There are many factors that go into this initial stage, particularly
on how the software will function on multiple platforms or multiple operating
systems. This is then followed by the development of a software plan that
defines the resources, timeline, and budget for developing the system.
It also defines the scope of the software design and in many cases may
also explicitly define what is considered to be out of scope. The process continues with documenting specific software requirements. Different from the high level requirements which simply describe how the system should basically function, the software requirements describe specific flow of information, interface and function details, and software validation requirements. The requirements are then reviewed until a final set of requirements is approved. The process then enters the development phase which begins with the design process. The set of requirements are now developed into a high-level design which evolves into a more detailed design. The design is reviewed and modified until it is approved for the next step. Finally the software itself is developed, typically with multiple programmers coding simultaneously which introduces the need for a source code control environment for parallel development. Depending on the size and complexity of the system, many components may be designed separately and tested separately (unit test), then tested as the components are put together as a complete system (integration test). Any errors detected during either the unit testing or integration testing are then identified and fixed. Typically before integration testing is started all code development is frozen to avoid introducing conflicting code. Once the system has successfully passed all the tests, a snapshot of the software is saved and is released. The system is then monitored and if any problems are reported they are evaluated and fixed, then released in a patch to correct existing systems and also integrated for the next release of the system. Engineering E-LearningSo now how do we apply the software engineering approach to instructional design? As in both cases we must start with a set of requirements. In the case of developing e-learning, the process follows the basic instructional design process similar to the Dick and Carey model up to Step 6 or through the Design Phase of the Learning Development Process in which the actual determination that we are delivering the content via e-learning is established. The process from this point forward assumes development of asynchronous e-learning in which the learner is guided through an instructional design by electronic means. A storyboard is developed to organize the presentation of the content
in a logical flow. The storyboard would represent the pages or screens
which would display to the learner and any interactive exercises or assessments
that might be be included. The storyboard would then go through a technical review process in which each reviewer or Subject Matter Expert (SME) would review the accuracy of the content. Once the storyboard has been approved by all reviewers the content is ready to be developed. Consistent with instructional design, the preceding and post module assessment test for each course module as well as an overall post course assessment are developed first to meet course objectives. Some courseware authoring systems support customized or accelerated learning paths by developing a pretest that is mapped to key topics within each module. If the learner can successfully answer a specific question or set of questions tied to a particular topic, that topic can be eliminated from the course automatically so that the learner is only presented with unfamiliar material. The posttest for each module would then validate that the learner understands the content and record a completion status for that module. Although a learner may have completed all modules of a course, an overall posttest may still be administered, particularly for certification purposes, before recording a course completion. The module content is then developed following the storyboard path. In most cases the content will be developed from a template which already includes navigational controls and links to required and/or optional resources. The delivery of the content may include images, multimedia content, interactive exercises and demonstrations, dynamic presentation of the content, and text. All of these components are designed to support a successful completion of the post module assessment. During development there may be more than one course developer working on the course or module. Depending on your development and/or LCMS environment each developer may need access to the same file or a file that is a dependent of another file. To prevent accidental conflicts or overwriting of developed content by another developer I highly recommend employing a source code control process or system. A source code control system has the ability to prevent access to a file that is currently under development by another developer, or supports the creation of a local working environment by copying needed files from a central repository, then synchronizing changes made by other developers into the working environment to determine if those changes have any impact. Once the module has been completed it is ready to be tested. The unit test focuses on testing functionality and usability within the module itself. Local navigation can be tested, but navigation to other modules would not be tested because the other modules may not be ready. The e-learning developer can follow a checklist of items to check at every page or screen, such as whether all images appear properly, all buttons and links work, animations and multimedia play smoothly, etc. If possible, the developer can also test that their content is deliverable on multiple platforms in multiple combinations, particularly the minimum requirements. The minimum requirements can be determined by building a minimal system on which to test. This system would be representative of the minimal system requirements you expect from your learners' system. There are methods in which you can develop rich content for high-end users and still provide quality content for minimal system users by detecting system resources at run-time. When unit testing is completed for all course modules, then the modules can be assembled to create a complete e-learning course. In most authoring systems this is already being done during development. When the complete course is built all code development is frozen and no developer is allowed to make even the smallest change. The course is now ready for integration testing. A new set of checklists are provided to testers to evaluate functionality (all components function as expected), usability (the components are easy to use by learners), and platform compatibility (all components work on all targeted platforms and configurations). The testers document specific problems and describe in as much detail the error encountered and how, if possible, it is reproduced. Once the integration test is completed a list of documented errors are provided for developers who in turn update their modules and conduct unit testing to validate the fix. The integration testing cycle is repeated until all components function properly. The course is now ready to test with an audience. A pilot audience is provided access to the course in the development environment and are also provided with a checklist of their own as well as a form to document any content or functional issues. If this course is being evaluated at level 3, 4, and ROI then the pilot audience should be made up of a portion of an experimental group, or be eliminated from the evaluation population completely if initial errors in the course are to be discounted. When the pilot delivery is complete and all documented issues are provided to developers, then course developers revise the course or respond to the pilot audience to address the issues raised. The course is then ready to be released. The release process involves uploading the course from the development environment to the production environment and providing access to the course through the LMS. A course catalog description of the course should have already been completed during the Design Phases of the Learning Development Process. There is a lot more to this process, including physical development architecture and related processes, but this should give you a very high level approach to e-learning engineering. |
|
|
Copyright
©2003 E-Learning Engineering |