Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
A Model for Component-Based Courseware Development (CBCD)
Nelson Baloian (+), David Fuller (*) and Sergio Ochoa(+)
(+) {nbaloian, sochoa}@dcc.uchile.clComputer Science Department
Universidad de Chile
Blanco Encalada 2120, Santiago, Chile.
Phone: (562) 678-4362, Fax: (562) 689-5531 / (*)
Computer Science Department,
Pontificia Universidad Católica de Chile,
V. Mackenna 4860, Macul, Santiago, 306/22, Chile.
Phone: (562) 686-4108, Fax: (562) 686-4444
Abstract
The use of courseware as a tool for supporting the teaching/learning process is a story of both successes and failures. Among the reasons for its failures are the large number of resources required for developing quality courseware and the lack of a methodology that could facilitate this process while ensuring a certain level of product quality. These are the same problems the software engineering field has experienced during the software crisis. On these accounts, this work reuses many of the solutions found by this discipline. As a general solution to the stated problem, a systematic and proven model for courseware development is proposed in order to support its development and reengineering process. On this direction, the model is intended to decrease the level of craftsmanship of this process and to reduce the development time and costs, as well as to improve the capability for predicting the courseware’s quality level. This work shows that it is possible to develop courseware engineering by following the steps of software engineering.
1
Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
1. Introduction
Computers as well as computer-based learning material are already a sine-qua-non part of any undergraduate, graduate, technological, and even non-technological study curricula [see Communications of the ACM, January 1998 for a number of examples]. This kind of material, combined with the tools which make it available to the students and that enable collaborative and/or cooperative learning activities among themselves, is known as “courseware”. This set is primarily used to support distance learning. Courseware, however, may also be used effectively to complement and enrich the traditional type of learning. Courseware development is a complex task, which requires an interdisciplinary work, a large amount of experience and experimentation. The result of a courseware development effort often depends on the people doing the work, and the set of tools and methodologies chosen for the task [5; 7].
Currently, the only good known model and methodology for developing courseware is CDM -Courseware Development Methodology- [17]. However, this methodology is vaguely specified, making it very difficult to apply out of the original context it was conceived for. It is also based on the cascade development model, thus presenting a number of well-known weaknesses [1].
On the other hand, there are courseware tools [8] available which offer a computer-based environment to develop a courseware. These tools, however, do not have an associated methodology to guide the development process. This methodology is particularly necessary to support the courses curricula development. We understand curriculum development as the process of selecting and sequencing of educational activities to reach the pre-established learning goals [9].
In summary, since the courseware development process depends on the people, tools, and methodologies involved, and considering the fact that there is still not a clear methodology to carry out this process, the results will depend mainly on the abilities of the involved people. This situation is prone to cause many drawbacks, as discussed in [15], which are typical for any ‘hand-crafted’ process.
From another viewpoint, M. Jackson states that the software development methodologies can be extended, but they should be tailored to each particular situationif they are to be used in areas different to those they have been designed for [6]. It is also known that some of these models have helped to notably reduce the craftsmanship levelof the software development process. Therefore, the present work proposes a model of courseware development, based on one of the more successful software development models, such as the CBD -Component-Based Development- [11]. Besides, the proposed model includes five of the six best practices found by software engineering to address this problem [7]. In order to simplify the experimentation phase, the sixth best practice (configuration management) has not been included here.
The key aspect to specialize the CDB model is the management of requirements, specifically, the management of courseware learning goals as if they were user requirements [4]. This model includes specific characteristics of courseware development, and it has helped the authors to carry out this task in a systematic way, by following a set of well-defined steps. This presentation is the result of the authors’ work carried out during the last three years on courseware development and evolution.
Section 2 presents a courseware lifecycle and discusses its similarities and differences with a software lifecycle. In Section 3, the proposed model is described. The obtained results are shown and discussed in Section 4. Conclusions of the work are presented in Section 5.
2. Courseware and Software Lifecycle
Likewise to software development, in courseware development the phases: analysis, design, implementation and validation are obligatory.
During the analysis phase both the work scenario and the requirements for the product to be built should be defined. The requirements are the set of educational goals to be reached by the students during the course. In this phase, both the process and product risks should also be identified, and the effort level for courseware development should be estimated as well.
During the design phase the requirements are translated into a representation of the final product that can be evaluated in a static way (similar to a blueprint). In the case of a courseware, this consists on designing the means to be used for reaching the course goals. These means are a combination of a didactic activity and a course content, designed for attaining a specific educational goal.
In the implementation phase, the final product (courseware) is built, based on the design obtained in the previous phase. This courseware should contain -at least- the following elements: the didactic material, the tools to carry out the foreseen activities, and a detailed planning of the teaching/learning process to be developed. All these components should be organized in such a way that the course’s dynamics lead to the attainment of the preset goals.
Finally, in the validation phase, both levels for courseware goal attainment and for courseware acceptation are evaluated. Based on this feedback data, the weaknesses and strengths of the product are analyzed. This information will then be used as input for a reengineering phase, also called "the following evolution of the courseware" (see Figure 1).
The most important differences that can be distinguished between both the software and the courseware development processes are the following ones:
- From the point of view of the requirements, both processes have product and user requirements [4]. However, unlike the software systems, the courseware design depends fundamentally on the user requirements. Thus, the only way to validate the courseware requirements is through experimentation.
- Since we have considered the educational goals as a user requirement, the characteristic of requirements management is an important issue to be considered during the courseware development process. This kind of requirements should be organized hierarchically in order to assure that the upper goal be reached if the lower goals are previously attained as well. Typically, this does not happen with the requirements of software systems.
- Generally, the evolution speed of a courseware is greater than that of software systems. Consequently, the development process needs a strong support for the reengineering activities.
- In courseware, automatic mechanisms should be foreseen to verify the achievement of the various goals, because these cannot be verified statically. The only way of verifying the completion of these goals (user requirements) is by using the product. This information will then be used to redesign the product. With software systems, this is unlikely to happen, because this feedback is left to the user's opinion.
- In the software lifecycle, both software system specialists and applications domain experts develop each phase. With courseware, instead, experts of the applications field are required to carry out each phase.
Models such as RUP [7], CBD [11; 16] and WebE [16] have shown good results in software development, but they are only partially applicable to the courseware development. The fact that the design depends mainly on user requirements makes it necessary that these models manage standard solutions for recurrent user requirements. In other words, it requires that the models use software components that implement the typical design patterns of the application area. Although CBD does not derive the design of user requirements, it is a better compound than the other ones, because it uses a framework of components that could implement the typical design patterns of the application area. This model does not regard the hierarchical organization of requirements (objectives). On account of the above reasons, the proposed model is presented in the next section, as a specialization of the CBD model, adapted for courseware development.
3. The Proposed Model
The proposed model is called CBCD and it is a specialization of the CBD model [11]. This latter model has been simplified to improve its usability and to make it manageable by people having little expertise and time to design, build and maintain a courseware. The proposed model uses a combination of incremental and iterative development for building a courseware, and it features three main components: an evolutionary methodology, a visual modeling language, and a framework of software components. The methodology is used as a guideline for the development process. The visual modeling language is used during the analysis and design phase to define a model of the courseware structure or the course curriculum.
Figure 1. Proposed Development Model
The framework of software components is used during the implementation phase for creating the courseware. This framework supports the different kinds of learning activities that are to be carried out during the course and they also contain the computer-based learning material to be used. Ideally, an interdisciplinary group made up of the teachers involved in the curricular subjects, psychologists, education experts, graphical designers, and software engineers should delve into this process. In the real practice, however, it is the course teacher(s) and assistants that perform this task, though they may not be experts on the pedagogical design of courses. The model uses patterns to build a courseware in order to help these people in their task, as well as to reduce both the development time and overall costs.
A graphical representation of the model is shown in Figure 1. Each cycle corresponds to a certain stage of courseware development, and it consists of four phases: analysis, design, implementation, and validation. The typical courseware development using the model starts with the analysis phase. During such a phase, the work scenario is identified and the courseware goals are defined (section 3.1). During the design phase, the means to be used for reaching courseware goals should be designed and structured (section 3.2). Then, in the implementation phase, a courseware based on the design is built up (section 3.3).
Finally, this courseware is tested by using it in a real scenario with teachers and students in order to find possible errors or weaknesses (section 3.4). This information is very important to improvethe courseware during the reengineering stage. The proposed development model establishes -for each phase- a list of major activities, deliverable items, review activities, and milestones (Figure 2). The major activities component indicates which main tasks should be carried out for each phase.
The model suggests a top-down order to develop these tasks, but this can be modified or adapted according to the needs or habits of the developers. Each phase should produce a deliverable item that will be validated and approved through different types of reviews.
The reviews help to identify at an early stage the errors and risks of both the process and the product, thus reducing the time and costs of correction. The proposed model establishes as well a set of milestones that defines the minorgoals to be reached during the development or reengineering process. These milestones are useful for assessing the project’s progress. Thus, it is possible to identify early in the workthe delays that usually arise in this kind of projects, and to take the consequent corrective actions.
3.1 Analysis Phase
The analysis phase is the front door of the model. This phase is divided into two sub-phases called the Scenario Definition Sub-phase and the Goals Definition Sub-phase. During the first sub-phase, the work scenario is defined, whereas in the second sub-phase the courseware goals are defined and organized into a hierarchical tree. The product from the analysis phase is a document called AD (Analysis Document) encompassing the documents obtained in both prior sub-phases, namely the SDD - Scenario Definition Document, and the GDD - Goals Definition Document.
Scenario Definition Sub-phase.In order to define the work scenario, it is necessary to determine the target audience, to identify the available resources for carrying out the teaching/learning process, and to analyze the background informationof the course. Once these points have been set, it is possible to determine which instructional strategy will be used during the course as well as the evaluation methods to apply. All this information is registered into a document called SDD (Scenario Definition Document). This is a standard-format document, ant it is the gate to the next analysis stage, as well as background of courseware evolution.
1
Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
Figure 2. CBCD Activities
1
Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
While building the SDD, it is not necessary to do any inspection activity, on account of the simplicity of this document. Nevertheless, it should be reviewed by means of a technical revision (SD/R Scenario Definition / Review) in order to have it approved. During this revision, the proposed work scenario is compared with the historical scenarios of the course, and with the former experience gained in similar previous courses. This is done to identify problems or risks in the proposed scenario. From this revision process there arise comments, suggestions, correction requests and –possibly- the approval itself. In case of not approving the document during the technical revision, it should be modified until it can be accepted. By concluding this, the following phase starts.
Goals Definition Sub-phase. During this sub-phase, the learning goals of the course should be defined. This is done hierarchically, based on the scenario definition and on the course’s general goal to be firstly defined (Figure 3). Then, this general goal should be broken down into several -more operational- learning sub-goals. These sub-goals can also be further refined until the pre-established learning goal can be clearly attained by a single learning activity.
The learning activities are the leaves of the goals tree. The methodology does not impose a certain number of levels in the hierarchy of goal definition, thus meaning that the tree may have any depth and that it may not be balanced as well. However, based on our experience and some learning principles, we suggest implementing no further than four levels, corresponding to the general goal, chapter goals, section goals, and session (or sub-section) goals (Figure 5). This arrangement will also result in a balanced tree.
After completing the above issue, the goals tree is inspected in order to identify risks or inconsistencies. Finally, a plan for developing the courseware is created. The product of this sub-phase is a document called GDD -Goals Definition Document-. In order to finish the analysis phase, the GDD and AD documents should be approved during a technical review.
1
Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
Figure 3. Example of a Course’s Goals Tree
1
Proceedings of the KSI Conference SEKE’01 (Software Engineering & Knowledge Engineering). Bs. As. Argentina, Jun. 13-15, 2001. Knowledge System Institute. KSI Press. USA. pp. 363-370.
Goals Modeling Technique. In order to represent the hierarchy and relationships among goals we have defined the following nomenclature.
Symbol / Meaning/ This relationship indicates that the activities associated to goal 1.1 should be finished before those corresponding to goal 1.2 can get started.
/ The non-relationships among goals indicate that there are not any starting or finishing constraints for theactivities associated to goals 1.1 and 1.2.
Figure 4. Supported Link Types.