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


2/6

Session T2G


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.


3/6

Session T2G


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


4/6

Session T2G


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


5/6

Session T2G


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.


6/6

Session T2G


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

aritculo 01 - an extended methodology for educational software design

Documents