1 Learning Activities Educational Methodology Clinical Laboratory Science Program.
Aritculo 01 - An Extended Methodology for Educational Software Design
-
Upload
aquiles-brinco -
Category
Documents
-
view
213 -
download
0
Transcript of Aritculo 01 - An Extended Methodology for Educational Software Design
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
1/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-13
AN EXTENDED METHODOLOGY FOR EDUCATIONAL SOFTWAREDESIGN: SOME CRITICAL POINTS
Fernando J. Lage1, Yuriy Zubenko 2 and Zulma Cataldi3
1 Fernando J. Lage, Facultad de Ingeniera, Universidad de Buenos Aires. Paseo Coln 850, 4 Piso. Ala Sur, 1063 - ARGENTINA [email protected]
Yuriy Zubenko, Universidad John Kennedy ARGENTINA [email protected] Zulma Cataldi, Facultad de Ingeniera, Universidad de Buenos Aires. Paseo Coln 850, 4 Piso. Ala Sur, 1063 - ARGENTINA [email protected]
Abstract
This paper is part of a series of research linesrelated to the design, development and evaluation of
educational software. These research lines intend not only to
account for the problems faced by professors when
attempting to incorporate computational applications to
their educational practices, but also to provide them with a
computational solution for their developments.
In this particular case, the methodological aspect of the
topic is considered to be relevant, since this is a crucial
point to build a new product. This is why the activities ma-
trix of the processes is presented, integrating pedagogical
aspects to the conventional activities matrix, this integration
being the central core of our proposal
Index TermsEducational Computer Science, Educational
Software, Software Design, Software Methodologies.
INTRODUCTION
A life cycle is proposed for the design of the educational
software, and its selection justified. The stages of the cycle
are considered and the activities matrix is defined. Based on
this matrix, the tools and techniques to be used at each of the
processes considered are described.
The starting point for the proposal is a life cycle of
evolutive prototypes with successive refinements. For themethodological stage of the design, the classic
representation instruments provided by the cognitivist-
constructivist approach are incorporated.
The methodological proposal considers the construction
of educational programs from an integral viewpoint, taking
into account the pedagogical aspects of the life cycle.
Special interest is paid to the configuration of the profiles
of the different professionals of the development team, to the
design of the program, and to the confection of the process
documentation.
LIFECYCLE SELECTION
The selected life cycle model is that of evolutive prototypes
with successive refinements, due to several reasons:
When the software is to be developed by request, it is
desirable to have an outline of the program as soon as
possible in order to satisfy the curiosity of the client oruser. Prototypes with increased functionalities will be
gradually handed in, in order for the clients/users to try
them during a period of time previously agreed on, and
thus be able to incorporate their suggestions and changes
during the early stages of the life cycle.
On the other hand, it is important to know as soon as
possible if the interpretation of the product by the
developers is in agreement with the clients/users needs
and considerations.
In many cases, users cannot give a detailed idea of what
they want. Therefore, developers do not know exactly
what they are supposed to create, which makes each
prototype a revision and refinement of requirements as away of approaching the end product.
The following stages are defined in the incremental pro-
totype life cycle [12]:
1. Feasibility (FAC)
2. System requirements definition (RES)
3. Specification of prototype requirements (REP)
4. Prototype design (DPR)
5. Detailed design of the prototype (DDP)
6. Prototype development (codification) (DEP)
7. Prototype implementation and testing (IPP) Iterative
refinement of prototype specifications (enlarging its
aim and/or scope). If the desired aim and scope were
achieved, it is possible to go back to stage 2. (RIT)
8. Design of the final system (DSF)
9. Implementation of the final system (ISF)
10. Operation and maintenance (OPM)
11. Withdrawal (if pertinent) (RET)
Following there is a description of each of the stages of
the selected life cycle that will be part of the activity matrix
(1):
Feasibility (FAC): This stage defines the software product
and determines its feasibility in the life cycle from theviewpoint of the relationship cost-benefit, as well as the
advantages and disadvantages as regards other products.
System requirements (RES): The functionalities, interfaces
and type of design required for the development of the
system (or program) are defined at this stage.Specification of prototype requirements (REP): This stage
consists in the specification of the functions, interfaces and
output required for the prototype. Increments in
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
2/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-14
percentages of the system overall functionality are
considered here.
Prototype design (DPR): The plan of the prototype plan is
put into action; since once the restrictions are agreed upon
with the users, they will expect to see at least some of the
functions working. An analysis is required here in order todetermine how the work is going to be done, what modules
are going to be done, what logic is going to be applied, and
which functions are going to be used.
Detailed design of the prototype (DDP): This stage is a
verified specification of the control structure, data
structure, interface relations, size, basic algorithms and
assumptions of each component of the program. In this
stage, not only are the algorithms that will carry out the
functions to be performed by each module defined, but
they are also documented. Software design is a process
centered in four different attributes of the program: data
structure, software architecture, procedural detail and
interface characterization. During this process, the
requirements are to be translated to a software
representation that can be established so as to obtain therequired quality before coding begins.
Prototype development (codification) (DEP): The codifica-
tion or detailed design is carried out in a language the ma-
chine understands.
Prototype implementation and testing (IPP): It consists in
achieving a proper functioning of the software product in
the computer system, operationally working, including
objectives such as data and program conversion (if there
were any), installation and training. The test must ensure
that all of the sentences have been tested, and that all tests
granting that the defined input actually produces the
expected results have been carried out at the external
functions.Iterative refinement of prototype specifications (RIT): this
stage increases the functionality of the system by going
back to the REP stage in order to increase prototype func-
tionality or by moving on if the desired objective and
scope were achieved.
Design of the final system (DSF): This stage consists in an
adjustment of the final restrictions or conditions and an
integration of the last modules.
Implementation of the final system (ISF): It is the computer
system operationally working, including objectives such as
data and program conversion (if there were any), installa-
tion and staff training.
Operation and maintenance (OPM): The computer systemstarts working; this objective is repeated for each update.
Withdrawal (RET): It is a suitable transition between the
functions carried out for the product and their successors.
Next, the basic processes for this life cycle are defined,
as well as the activities for each of them.
Processes include those concerning software develop-
ment and those, which are specifically related to education
issues, although in the proposal there is no specific educa-
tional theory defined.However, the activities added to the activities matrix in-
dicate a cognitivist-constructivist approach.Here the use of a
theory with an active subject who builds its learnings from
his own experience, the way Bruner did [3], must be consid-
ered; or that it can sustain the meaning and quality of what it
had learnt since it incorporated the new knowledge to a solid
structure of concepts already acquired [1], pointing out the
difference between significative learning and mechanical
learning. It can also be considered a sociological view [17]
in which the building of meanings as a process of internali-
zation implies mediation by the association of ideas that
meanings are taken from the exterior, and the piagetian ac-
cording to which the subject builds meanings in an autono-
mous way [13].
Table 1 present 23 processes considered to make theactivities extended matrix for educational software.
In Times Italic those processes are highlighted that have
relative activities to preventive pedagogic aspects. In the
extended activities matrix [5] they are added new processes
with activities concerning the definition and consideration of
educational, didactic and pedagogical aspects to develop the
educational software and in some of the existing processes
for the development of standard software, activities
concerning educational aspects are added, and in some of the
existent processes for the development of standard software
concerning activities are added to consider educational
aspects.
Once each of the activities are defined, the tools andtechniques to be used for each of them are still to be
considered, taking into account the model of the life cycle
selected (evolutive prototyping) and the educational theory
behind the development.
The following table shows the methods, techniques
and/or tools to use for each of the different processes.
In Table 1 are indicated the methods, the techniques and
tools used more frequently in each of the processes of the
activities matrix. They can be divided in technical processes:
with the use of cost/benefit analysis. Pert, CPM, Gant, mo d-
eling, DFD, DD, E/R diagrams, programming languages,
modularity, prototyped, software testing, between other; and
processes with pedagogical components: educational theo-ries, metacognitive strategies, conceptual maps, use of the
Ravens test [14], Wilcoxons test for small samples and
others.
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
3/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-15
Processe s Output document Methods/Techniques/Tools to use
Process ofIdentification of theeducational needs
Adopted an Educational Theory Interview, survey
Process of life cycle model selection Adopted life cycle
Process of initiation, planning and estima-tion of the project
Project negot iation plan Gantt or Pert diagram (CPM)(2)Estimation empirica l models
Process of project follow-up and control(program),
Risk analysis and contingencies plan.Historic register of the project
Modeling. Prototyping.Revisions. Audits. CPM analy-sis.
Process of software quality negotiationQuality guarantee plan.Quality enhancement recommendations.
Planning techniques.Software quality metrics
Process of concepts exploration Needs report. Possible feasible. Solutions Cost-Benefit analysis.DFD(3). Prototyping
Process of program assignment (system).
Specification of hardware and software functional require-ments.Specification of the interfaces of the system or program.Functional description. Architecture.
DFDModules
Process of educational requirements analysisSpecification of the objectives and concepts structure.Selection of contents and relevancy.
Cognitivist approaches.Constructivist approaches.
Cognitive strategies.
Process of software requirements analysisSpecification of software requirements, user interfaces andother software. Hardware interface and with the physical
system.
Structured analysis.DFD. DD(4). E/R (5) diagrams.
Prototyping techniques.
of the contents
Identification of mental processes to stimulate.
Definition of the activities to be carried out by students.Concepts hierarchization.
Use of cognitive strategies.
Ausubel and Novak theory.[1]Use of conceptual maps. [11]Process of
design
of the softwareDescription of software design and architecture.Description of information flow, bases, interfaces and yalgorithms.
Structured programming.Object-oriented programming.Prototyping techniques.
Process of implementation and modules inte-gration
Data for tests. Documentation of the system or programand the user. Integration plan.
ProgrammingLanguages
Process of installation Installation plan.Installation report.
ProgrammingLanguages
Process of operation and supportSupport requests histor y Statistical analysis.
Process of maintenance Maintenance recommendations Reapply the life cycle
Process of withdrawal Withdrawal plan
Process of verification and validationVerification and validation planTest plan. test specification and summary. Tested software.
Black box tests and white boxtests
Process of software prototypes evalua tionDesign of the evaluation instrument. Test summary. Sam-
ple selection.
Structured questionnaire , open
and semi-open.
Process of software internal and external
evaluation
Design of the evaluation instrument. Test summary. Sam-
pleselection.
Structured questionnaire, open
and semi-open.
Process of evaluation in contextDesign of the experience.
Experimental and control groups definition.
Pre-post analysis techniques.
Raven test. [14]Wilcoxon no parametric test.
Process of configurationConfiguration negotiation plan Data
basePERT and Ganttdiagrams
Process of technical documentation Technical documentation plan.
Process of didactic documentation Didactical documentation confection plan.
Process of staff training Training planTable 1: Definition of the methods, techniques and/or tools to use at each process.
Professionals from the area to which the softwaredevelopment will be applied
Professors and specialists in pedagogy to determine the contents to be included and ex-perts from the development area
Professionals in software development Analysts and programmers. For project analysis and codification .
Project coordinator As in every project supported by base engineering, this will be the task of the softwareengineer.
Support technical staff (graphic design and sound) Depending on the dimensions of the development, there will be operators, graphic design-ers, sound and video specialists, etc.
Table 2: Professionals required for the development
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
4/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-16
THEWORK TEAM
The creation of educational programs is a task concerning
many different areas. The formation and conformation of
development teams is fundamental for this type of educa-
tional projects.
To do so, it is necessary to consult specialists in softwaredevelopments, efficient planners and professors familiar
with the interest area for which the program will be devel-
oped, since a pedagogical model will have to be generated
for each case according to its particular needs.
Even though the conformation of the development teams
for commercial software requires the presence of a good
project leader and good relations between the members of
the project, in this particular case the situation is critical due
to the interdisciplinary nature of the team, centered on the
task of integrating and coordinating professionals from dif-
ferent disciplines. Basically, the profiles required are shown
in table 2.
Some authors like Marqus [10] consider the softwaredevelopment project to be on an axis centered on the
pedagogical team. It should be taken into account that the
program to develop presents two aspects: the achievement of
technical quality, which is the responsibility of the technical
team and should be the main axis, and software design and
development, which is the responsibility of specialists in the
area. The determination of the tasks to assign to each of the
development team members at each of the stages plays a
crucial role when optimizing development times.
It should be mentioned that in some cases it may be
necessary to consult specialists as regards very specificcomputer and network technologies applied to the
educational field, as well as psycho-pedagogues to advise
the team when a product with a given characteristic isrequired. One of the aspects to take into account is a perfect
definition of the activities to be carried out by each member.
Knowing who does what, makes the identification of the
responsible of each of the development stages easier, and
allows an evolutive following of each of the software
components during their development.
On the other hand, depending on the proposed develop-
ment model, there will be evaluations of the product whereall the team members will take part.
SOME CRITICAL POINTS
The first critical points in the development of educational
software is related with the need of a common language
between the members of the team, the solution we have
given to this problem is to have in the development team
computer professionals with a teaching career and practice,
using both characteristics to continue gathering the rest of
the team.
The second critical point appears when trying to define
how would be the interaction with the software, because the
question What does interaction means? arises.
Interaction is produced by the mutual presence where
events take place y by the complementary circularity where
perceptions and cognition are modified being part of the
presence and conduct of the other [8]. In this case between
the program (mediator) and the user.
In order to define the pedagogical interactivity that
teaching materials allow, interactivity must be defined,
which comes from inter that means between us and
pedagogical activity which is to interfere or to interpose
teaching actions for working out concepts or the develop-
ment of competition, that allow to understand and to transfer
to the action the essence of the implicated o bjects in order to
act in an appropriate way [8]
The pedagogical interactivity implies promoting the
communication, which means to let the other to contribute
and to play a leading role through the devising of didactical
situations and hypermedial material for meaning exchange.
This led us to design a context of resignificance-recreation-answer with computers and didactical software as mediators.
These connotations must be interpreted by the programmers,
with the aim of achieving the wanted interactivity in each
environment.
The third critical point is related with the concept of
quality and its polysemy. Educational programs have some
very particular characteristics according to the curricular
goals and the specific needs of the target group. That is why
to specify the quality of educational programs is a process
which consists of its grade of adaptation to a specific context
where a series of variables converge, such as: curricular
characteristics, target type, ages, teaching style, etc, and so
require a proper analysis.To make a proper analysis the quality of an educational
software must be evaluated according to three basic aspects
according to this order: first pedagogical-educational aspect,
communication aspect, and finally technical-economic.
FIRST DESIGN OF PROGRAM
The starting point is to detect the educational need for thedevelopment of the program; this can be achieved through
an interview and by an opinion poll between teachers that
use educational software. Starting from now an underlying
educational theory must be chosen for the application: be-
haviorist, constructivist, cognitive, or others. Although manytimes it is the institution the one who states the educational
theory to follow, many others it is determined by the curricu-
lum or it is established by the teacher who later will use the
program.
In this design the adopted perspective is the cognitive
constructivist, that is to say citing authors such as Ausubel
and Novak [1], Vigostkii [17], Bruner [3], there is a review
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
5/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-17
of these authors in Cataldi &Lage [4] in reference to the
production of learning materials.
Afterwards, a good representation of knowledge must be
obtained, where it is possible to use Novaks [11] conceptual
maps as a graphics representation that will allow the incor-
poration of new information to the one already existent in asignificative way. They can also be used nets of meanings
that are a kind of conceptual maps with some characteristics
of semantic nets. Specialists in contents design these nets or
maps.
In every subject or unit some things need to be very
clear: the goals to achieve, the identification of concepts,
their connections and the previous knowledges required.
After that, the activities that lead to the attainment of the
proposed learnings should be looked for, as a way of select-
ing the ones that are the most advisable for implementation
with problematic situations looking for the strengthening of
the superior thinking functions, as Vigotzkii [1] points out.
Computer design allows to convert nets or maps of
meanings into algorithmic structures, with actions and mes-
sages according to different events. To design the communi-cations environment, and when the team has little knowledge
about computer systems, the technique known as storyboard
is commonly used. These series of sketches should be con-
sidered as a way of grouping the needs, and are carried out
based on a previous agreement between team members.
Expert software developers and human interfaces design
specialists elaborate some prototypes of the screens for this
purpose. Therefore, storyboards are not used here, which is
not the case from the viewpoint of professors and program-
mers, who use them to interpret the requirements.
DESIGN
After the analysis of educational requirements follows the
analysis of software requirements. Then, the stage of the
design of the educational software is one of the most impor-
tant stages of the life cycle of this product, and specialists
both in pedagogy and in contents interact with software
design specialists from a computational point of view.
The design stage can be divided into two large sub-
stages: the process of contents design and the process ofsoftware design. Later on, the contents design will be inte-
grated to that of software, this being a key point in the proc-
ess because cognitive strategies are tested here so that stu-
dents have the possibility of acquiring knowledge by means
of the different tasks proposed.A proper structure of the concepts is extremely impor-
tant; topic, objectives proposed and activities should be
correctly defined for students to be able to acquire knowl-
edge. It could be said that both tasks and activities - these
being the different problem situations related to the topic
under study and which are presented to students to solve -
should be defined. In some cases, the tasks to be carried out
by the students can be defined with increasing difficulty and
complexity levels.
However, this could be a questionable point, since if the
software is to be used as teaching support, tasks and activ i-
ties should be proposed by the professor by means of clear
and precise instructions, and not by the program.Some authors consider the possibility of carrying out a
subjective analysis, i.e., a general panorama of the task from
the point of view of the task itself and of the subject solving
it, as well as from the standpoints of difficulty level, struc-
ture, and organization and articulation with the objectives
and possible solution paths. [15]. Valencia considers the
analysis from an objective description of the instructions, as
well as the analysis taking into account factors that present
problems and/or make knowledge significant, from a cogni-
tive point of view.
DOCUMENTATION
One key aspect to consider is the development of both in-
ternal and/or external technical documentation throughout
the life cycle of the product. The former includes all those
program comments that will be useful when carrying on
modifications at later stages, be it by the same developmentteam or not. On-line help for users needs also to be planned,
and for this purpose - if it is to be implemented - a special
module shall be developed.
External documentation is all documentation referring to
the material created since the initial stage of analysis, with
the relations and entities diagrams, data structures, processes
flow diagrams, descending modular design, etc., and all
other information considered to be relevant for the interpre-
tation of the development of the program.
Finally, it should be mentioned that there is a need for aclear and didactic user's manual, to be used by the professor
as assistance. This manual should include all the technicalaspects required for the program to work, and it can also
include a solutions guide for frequent problems.
A didactic manual or guide can also be made, in order
to provide the professor with all the information needed to
use the program. This didactic applications guide or manual
should include objectives, contents, addressees, proposed
activities, and it would be interesting to include which edu-
cational theory or theories were considered to develop the
program, and what kind of treatment the program allows for
the mistakes made by students during the learning process.
The results of the evaluations carried out should also beconsidered, taking technical aspects into account - be these
positive or negative -, and functionalities, with a detailed
presentation of statistical results and taking into account the
instrument created to collect those results and sample selec-
tion and type of those evaluating the product.
-
7/31/2019 Aritculo 01 - An Extended Methodology for Educational Software Design
6/6
Session T2G
0-7803-6669-7/01/$10.00 2001 IEEE October 10 - 13, 2001 Reno, NV31th ASEE/IEEE Frontiers in Education Conference
T2G-18
EVALUATION
The evaluation of a program designed according to the
proposed methodology of extending the activities matrix,
has been carried out. During the development students with
similar characteristics to potential users, evaluated two
prototypes as it is described in Cataldi & Lage [6] makingthe appropriates alterations and changes.
The development team evaluated the program internally
[2], whereas teachers and students evaluated the final prod-
uct externally [2,6], being carried out the pertinent modifica-
tions then.Finally, in order to make a contextualized evaluation (in
a context similar to the one for which was created the pro-
gram) in a course of students counterpart pairs were made
with the Raven [14] test of progressive matrixes. The aim of
this was to obtain two groups: a control and an experimental
one, working with two programs. The control group with a
software that did not consider pedagogical aspects, and the
experimental groups with the one developed with the ex-
tended methodology. It was then when we confirmed the
thesis: that a software which considers the pedagogical
aspects in his life cycle produces a better learning of the
concepts, that one developed with a methodology that does
not contemplate them. [7].
The results of this test through the use of the not para-
metric test by Wilcoxon [9] applied to the grades obtained
by students, makes evident a significant difference in favour
of the program developed with this methodology. Saying
this it is not trying to validate the methodology but to repeat
similar experiences [7].
CONCLUSIONS
It has been described the extended methodology for pre-
ventive the pedagogical aspects in the life cycle, for which
specific learning activities were added. With the intention ofcontrasting a software developed with methodology a prod-
uct was developed, it was evaluated and tested in a contextu-
alized way. The results indicate that the students' learnings
are significantly improved. This kind of results should be
gathered in order to validate or refute the methodology
through time.
To produce educational programs it is required a good
coordination between technical and pedagogical aspects, this
leads to bear the critical aspects pf the project due to the lack
of common reference frames between software engineeringand the educational science. This leads to negotiation of
meanings and the production of a common language to ex-plain concepts such as interactivity and quality for educa-
tional software.
Lastly, it is thought to develop as future investigation
lines the extensions of other life cycles in order to adequate
them to the educational needs, contrasting the efficiency of
the products.
REFERENCES
[1]. Ausubel D., Novak J., y Hanessian H. (1997): PsicologaEducativa. Un punto de vista Cognitivo. Trillas. 3ra Edicin.
[2]. Bork A. (1986): El ordenador en la enseanza. Anlisis yperspectivas de futuro, Barcelona, Gustavo Gili.
[3]. Bruner J. (1988): Desarrollo cognitivo y educacin. Morata.Madrid.
[4]. Cataldi, Z., Lage, F., Pessacq, R. y Garca Martnez, R. (1999):Revisin de Marcos Tericos Educativos para el Diseo y Uso deProgramas Didcticos. Proceedings del V Congreso Internacionalde Ingeniera Informtica. Pginas 172-184. Editado por
Departamento de Publicaciones de la Facultad de Ingeniera.
[5]. Cataldi Z., Lage F., Pessacq R. y Garca Martnez R., (2000a).Metodologa de Diseo y Desarrollo de Software Educativo. VICongreso Internacional de Ingeniera Informtica ICIE 2000. 26-28de abril de 2000. ISBN 987-98197-0-5. Pgs. 330-347.
[6]. Cataldi Z., Lage F., Zubenko Y., Pessacq R. y GarcaMartinez R.(2000b): Evaluacin contextualizada de software educativo.
CACIC 2000. Congreso Argentino de Ciencias de la Computacin.2-7 de octubre, Ushuaia.
[7]. Cataldi Z., Lage F., Pessacq R. y GarcaMartinez R. (2000c):Evaluation of educational software from an integral perspective.CACIC 2000, 2-7 de octubre, Ushuaia.
[8]. Fainholc B. (1998):La interactividad en la Educacin a distancia.Paidos, Buenos Aires.
[9]. Ledesma D. A. (1980):Estadstica Mdica. Eudeba
[10]. Marqus P. (1995):Metodologa para la elaboracin de softwareeducativo en Software Educativo. Gua de uso y metodologa dediseo. Barcelona Estel. www.xtec.es/~pmarques ,www.doe.d5.ub.es
[11]. Novak J. y Gowin D. (1988):Aprendiendo a aprender. MartnezRoca. Barcelona.
[12]. Piattini M. (1996):Anlisis y Diseo Detallado de AplicacionesInformticas de Gestin. Rama. Madrid.
[13]. Pozo Municio I. (1994): Aprendices y maestros. Alianza.
[14]. Raven J. C. (1979): Test de Matrices Progresivas. Escala General.Vol. 3b. Paids. Buenos Aires.
[15]. Valencia M. E., Toro I. y Donneys C. (1998): Desarrollo deaplicaciones hipermedia: propuesta para el diseo educativo.
TISE98. Consultado el 28/9/99 10 hs. enwww.sofia,univalle.edu.co/gidse
[16]. Vigotzkii L. (1978):Mind in Society . The development of higherpsychological process. Cambridge. M. A. Harvard UniversityPress.
NOTES(1) The activities matrix for software design was adapted from JuristoJuzgado N. (1996): Proceso de Construccin del Software y Ciclos deVida en mdulos de Proyectos de Software. Universidad Politcnicade Madrid. (2) CPM: Critical Path Method. (3) DFD: Data Flow Dia-gram (4) DD: Data Dictionary (5) E/R: Entity/Relation Diagram