Information Technology Reference
In-Depth Information
and navigating through the module, the content
should be essentially the same. The module should
be as flexible as possible (by applying the idea
of open specification) in order to be adequate to
different profiles without having to modify its
structure significantly.
Methodologies and tools used for developing
SoftTest were in agreement with the SP-DEM
instance. As development methodologies, we
adopted ADDIE model and IMA-CID approach.
Word, PowerPoint, FrontPage, Visio, LaTeX,
Moodle, WebCT, CoWeb, and e-Class were chosen
as authoring and educational tools. As a domain-
specific tool, we selected Proteum (Delamaro et
al., 2001).
The development team was composed of three
members: (1) a teacher, acting as the domain ex-
pert as well as the instructor of the module; (2) a
graduate student, performing the roles of project
manager, version manager, coordinator and de-
veloper; and (3) an undergraduate student, acting
as developer and technician. All members worked
collaboratively for developing the module. Their
roles were also in agreement with the SP-DEM
instantiation (Figure 3).
SoftTest was composed of 16 sub-modules;
Figure 5 shows its overall structure in terms of a
conceptual map. For each sub-module, concepts,
facts, principles, procedures, examples and exer-
cises were modeled and implemented as a set of
slides, integrated to HTML pages, text documents,
learning environments and testing tools. Figure 6
presents an overview of SoftTest, illustrating its
main components and their integration.
Following SP-DEM process, SoftTest was
evaluated according to three perspectives: (1)
standards verification, checking the module
against the interface standards established; (2)
editorial verification, looking for grammar errors;
and (3) functional verification, looking for logical
errors through the navigation. We have also ap-
plied SoftTest in realistic learning scenarios aim-
Figure 5. Overall structure of SoftTest
Search WWH ::
Custom Search