Revista Ingeniería Informática, edición 13, noviembre de 2006

El ciclo de vida y la matriz de actividades como base para el diseño y

desarrollo metodológico de software educativo
Zulma Cataldi

Laboratorio de Informática Educativa y Medios Audiovisuales. liema@fi.uba.ar

Paseo Colón 850. C1063ACV. Ciudad de Buenos Aires
Facultad de Ingeniería. Universidad de Buenos Aires.

Resumen
Este trabajo forma parte de una serie de investigaciones relacionadas al diseño, desarrollo y evaluación del softwa-
re educativo. Estas investigaciones no sólo pretenden dar cuenta de la problemática con que se enfrentan quienes
desean incorporar las aplicaciones informáticas a sus prácticas educativas, sino de brindarles una solución infor-
mática para sus desarrollos fundamentada en los principios de la ingeniería de software.
En este caso en particular, se considera importante el abordaje metodológico, ya que este el punto es crucial para
cimentar las decisiones en cada etapa a fin de construir un producto de calidad. Es por ello que se presenta a la
matriz de actividades ampliada incluyendo procesos que integran los aspectos didácticos pedagógicos a la matriz de
actividades convencional, siendo esta integración el núcleo central de la propuesta.

Palabras clave: software educativo, prototipos evolutivos, matriz de actividades.

1. Introducción
En esta comunicación se propone y se justifica el ciclo de vida elegido para el diseño del software educativo, consi-
derándose cada una de las etapas del ciclo y se define la matriz de actividades, a partir de la cual se describen las
herramientas y las técnicas que se utilizarán en cada uno de los procesos considerados.
Para la propuesta metodológica se eligió un ciclo de vida basado en de prototipos evolutivos con refinamientos suce-
sivos como punto de partida. En la etapa metodológica de diseño se integra el enfoque dado por las teorías cogniti-
vistas y constructivistas (Ausubel y Novak, 1997; Coll, 1974; Vigotzkii, 1978) a los instrumentos de representación
clásicos que provee la ingeniería de software.
El aspecto más novedoso de la propuesta metodológica es que considera la construcción de programas educativos
desde un aspecto integrali, teniendo en cuenta los aspectos pedagógicos en el ciclo de vida, poniendo un interés espe-
cial en la configuración de los perfiles de los diferentes profesionales del equipo de desarrollo, especialmente en el
diseño del programa y en la confección de la documentación de los procesos.

2. La elección del ciclo de vida

Para esta propuesta el modelo de ciclo de vida elegido es el de prototipos evolutivos con refinamientos sucesivos, por
varios motivos entre los que se deben tener en cuenta:
− Cuando el software a desarrollar es por encargo, es interesante tener una idea de cómo será el programa lo antes
posible. De este modo, y a fin de disminuir las expectativas del cliente o usuario, se le podrán ir entregando pro-
totipos con funcionalidades en forma incremental, para que se los pueda ir probando durante un período de tiem-
po a convenir. Prontamente, podrá hacer las sugerencias de cambios en etapas lo más tempranas posibles del ci-
clo de vida.
− Por otra parte, el ciclo de vida elegido es pertinente cuando se desea que el usuario sepa cuanto antes si el produc-
to tal cómo se lo interpretó está de acuerdo a sus necesidades y consideraciones.
− En muchos casos, el usuario no puede dar una idea acabada de lo que desea, y debido a ello, el desarrollador no
termina de saber exactamente lo que éste quiere, por lo que cada prototipo realizado, permite efectuar una revi-
sión de los requerimientos y un refinamiento de dichos requerimientos a fin de aproximarse al producto final con
un acercamiento del que el usuario tiene en mente.

En el ciclo de vida elegido de prototipado incremental se definen las once etapas básicas siguientes:
http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

1. Factibilidad (FAC)
2. Definición de requisitos del sistema (RES)
3. Especificación de los requisitos del prototipo (REP)
4. Diseño del prototipo (DPR)
5. Diseño detallado el prototipo (DDP)
6. Desarrollo del prototipo (codificación) (DEP)
7. Implementación y prueba del prototipo (IPP) Refinamiento iterativo de las especificaciones del
prototipo (aumentando el objetivo y/o el alcance). Luego, se puede volver a la etapa 2 o conti-
nuar si se logró el objetivo y alcance deseados. (RIT)
8. Diseño del sistema final (DSF)
9. Implementación del sistema final (ISF)
10. Operación y mantenimiento (OPM)
11. Retiro (si corresponde) (RET)

Cada una de estas etapas del ciclo de vida elegido formará parte de la matriz de actividades, que es el documento
donde se plasman las actividades relativas al desarrollo para cada proceso involucrado. Las etapas básicas son las
que se describen a continuación y se debe señalar que para cada una de ellas se ha elegido una sigla arbitraria que
está entre paréntesis.
− Factibilidad (FAC): En esta etapa se define el producto software y se determina su factibilidad en el ciclo de vida
desde la perspectiva de la relación costo –beneficio, como así las ventajas y desventajas respecto de otros produc-
tos.
− Requisitos del sistema (RES): En esta etapa se deben definir las funcionalidades requeridas para el desarrollo del
sistema (o programa), las interfaces y el tipo de diseño.
− Especificación de requisitos del prototipo (REP): Consiste en especificar las funciones requeridas, las interfaces
y el rendimiento para el prototipo. Aquí se considerarán incrementos en porcentajes de la funcionalidad total del
sistema.
− Diseño del prototipo (DPR): Es poner en ejecución del plan del prototipo, ya que una vez fijadas las restricciones
con el usuario, hay que mostrar el mismo funcionando, aunque sean sólo algunas funcionalidades restringidas.
Aquí, hay que hacer un análisis de cómo se va a trabajar, qué módulos se van a hacer, con qué lógica y qué fun-
ciones se van a usar.
− Diseño detallado del prototipo (DDP): Esta etapa es una especificación verificada de la estructura de control, la
estructura de los datos, las relaciones de interfaces, el tamaño, los algoritmos básicos y las suposiciones de cada
componente del programa. En esta etapa no sólo se definen y sino que se documentan los algoritmos que llevarán
a cabo la función a realizar por cada uno de los módulos. El diseño de software, es un proceso que se centra en
cuatro atributos distintos del programa: la estructura de datos, la arquitectura del software, el detalle procedimen-
tal y la caracterización de la interface. En este proceso deben traducirse los requisitos a una representación del
software que pueda ser establecida de forma que se obtenga la calidad requerida antes de que comience la codifi-
cación.
− Desarrollo del prototipo (codificación) (DEP): Consiste en realizar la codificación o diseño detallado, en forma
legible para la máquina.
− Implementación y prueba del prototipo (IPP): Consiste en lograr un funcionamiento adecuado del producto soft-
ware en el sistema informático, funcionando operacionalmente, incluyendo objetivos tales como la conversión
del programa y datos (si la hubiere), la instalación y el entrenamiento. La prueba debe asegurar que se han proba-
do toas las sentencias del mismo, y que en las funciones externas se han realizado pruebas que aseguren que la
entrada definida produce los resultados que se esperan realmente.
− Refinamiento iterativo de las especificaciones del prototipo (RIT): Es un aumento de la funcionalidad del siste-
ma, para luego volver REP a fin de aumentar la funcionalidad del prototipo o continuar, si se logró el objetivo y
alcance deseados.
− Diseño del sistema final (DSF): Consiste en ajustar las restricciones o condiciones finales e integrar los últimos
módulos.
− Implementación del sistema final (ISF): Es el sistema de informático funcionando operativamente, incluyendo
tales objetivos como conversión del programa y datos, (si la hubiere), la instalación y La capacitación del perso-
nal.
http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

− Operación y mantenimiento (OPM): Es la puesta en funcionamiento del sistema informático, objetivo que se
repite para cada actualización.
− Retiro (RET): Es una transición adecuada de las funciones realizadas para el producto y sus sucesores

Una vez especificadas las etapas, se definen los procesos básicos a considerar para este ciclo de vida, y se definen las
actividades para cada uno de ellos. Los procesos incluyen aquellos concernientes al desarrollo de software a los que
se han incorporado actividades nuevas a fin de tener en cuenta aspectos pedagógicos y didácticos, aunque en la pro-
puesta, no se define una teoría de aprendizaje en particular, sino que las actividades se centran en un enfoque cogni-
tivista-constructivista. Por otra parte, se agregaron algunos procesos nuevos que consideran aspectos no contempla-
dos en el ciclo de vida tradicional, obteniéndose de este modo la matriz ampliada.
En la Figura 1, se presenta el diagrama del el ciclo de vida elegidoiiiii y en la Tabla 1, se puede ver la matriz de acti-
vidades, con el desglose de actividades para cada uno de los procesos para el ciclo de vida elegido utilizando las
abreviaturas mencionadas anteriormente para designar cada etapa.
En la matriz de actividades, se pueden observar sombreadas en color gris, las etapas del ciclo de vida involucradas al
incrementar las funcionalidades para la obtención de los diferentes prototipos, que se han de desarrollar. En fuente
normal se destacan las actividades relativas al desarrollo de software propiamente dicho y en fuente cursiva a aque-
llas actividades concernientes a definir y considerar los aspectos educativos didáctico-pedagógicos para desarrollar el
software pertinente.
Una vez definidas cada una de las actividades, queda por considerar cuáles son los métodos, las herramientas y las
técnicas disponibles para utilizar para cada una de ellas, teniendo en cuenta el modelo de ciclo de vida elegido (pro-

Estudio de
Factibildad
Requisitos
del sistema
Especificación
requisitos prototipo

Diseño del
prototipo
Diseño detallado del Evaluación
prototipo
interna
Desarrollo del
prototipo
Ajustes

Implementación y Evaluación
prueba del prototipo
externa
refinamiento
especificaciones Ajustes
prototipo

Diseño del
sistema final

Implementación del
sistema final

Operación y
mantenimiento

Retiro

Equipo Multidisciplinario

totipado evolutivo) y la teoría de aprendizaje o la visión global que sustenta al desarrollo.

Figura 1: Esquema del ciclo de vida elegido: prototipado evolutivo

3. La matriz de actividades
En la Tabla 1 se muestra la matriz de actividades completa para el software educativo basado en prototipos evoluti-
vos.

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

OPM
DDP
FAC

DPR

DEP

RET
RES

REP

DSF
Actividades de los procesos

RIT
IPP

ISF
Proceso de identificación de la necesidad educativa
Identificar necesidad del programa
educativo
x
Identificar o seleccionar la teoría de
aprendizaje a utilizar para el desarrollo
de acuerdo a la necesidad
Proceso de selección del modelo de ciclo de vida
Identificar de los posibles modelos ciclos
de vida el que más se adapta a las nece- x
sidades.
Seleccionar un modelo para el programa
de acuerdo a la teoría de aprendizaje x
elegida.
Proceso de iniciación, planificación y estimación del proyecto
Establecer la matriz de actividades para
el ciclo de vida considerando la teoría x
de aprendizaje a usar
Asignar los recursos del proyec-
to/programa
x x x x x x x x x x x x
Definir el entorno del proyecto/programa x x x x x
Planificar la gestión del proyec-
to/programa
x x x x
Proceso de seguimiento y control del proyecto
Analizar los riesgos x x x x x x x x x x
Realizar la planificación de contingen-
cias
x x x x x x x x x
Gestionar el proyecto/programa x x x x x x x x x x x x
Implementar el sistema/programa x x x x x x x x x x x x
Archivar registros x x x x x x x x x x
Proceso de gestión de calidad del software
Planificar la garantía de calidad del soft- x x x x
ware
Desarrollar métricas de calidad x x x x x x
Gestionar la calidad del software x x x x x x x x x x x x
Identificar a los responsables de cada x x x x x x x x x x x x
tarea
Implementar el sistema de informes de x x x x x x x x x x
problemas
Archivar registros x x x x x x x x x x
Proceso de exploración de conceptos
Identificar las necesidades educativas x
Formular las posibles soluciones poten- x x x
ciales
Identificar las necesidades del soporte x x x x
lógico
Formular soluciones potenciales compa- x x x
tibles

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Realizar los estudios de viabilidad x x x

Refinar y concretar la idea o necesidad x x x
Proceso de asignación del sistema
Analizar las funcionalidades del siste- x
ma/programa
x x x
Definir las funcionalidades del progra-
ma
x x x
Desarrollar la arquitectura del siste-
ma/programa en base a la teoría de x x x
aprendizaje elegida.
Descomponer los requisitos del siste-
x x
ma/programa
Proceso de análisis de requisitos educativos
Definir los objetivos educativos x x x
Definir las características del grupo
destinatario
x x x
Definir los contenidos y el recorte de
contenidos
x x x
Definir las estrategias didácticas x x x
Definir las actividades mentales a des-
arrollar
x x x
Definir el nivel de integración curricular x x x
Definir el tipo de uso del programa y
nivel de interactividad
x x x
Definir los efectos motivantes x x x
Definir los posibles caminos pedagógi-
cos
x x x
Definir el tiempo y modo de uso x x x
Definir el hardware necesario x x x
Proceso de análisis de requisitos del software
Definir el tipo de programa a desarro-
llar
x x x
Definir los requerimiento de las interface x x x x
Definir el tipo de interactividad x x x
Definir y desarrollar los requisitos del x
software
x x x
Priorizar e integrar los requisitos educa-
tivos con los del software
x x x x
Proceso de diseño
Definir la organización de los menús x x
Definir el tipo de íconos a usar x x
Seleccionar los efectos a usar: sonidos,
música, animaciones, vídeos, etc.
x
Seleccionar los textos a usar x
Asegurar la facilidad de lectura x
Realizar el diseño de las pantallas x x
Realizar el diseño de los menús x
Realizar los storyboards (si correspon-
de)
x x
Realizar el diseño preliminar x
http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Analizar el flujo de información x x

Diseñar la base de datos (si la hubiere) x x
Diseñar las interfaces x x
Definir los criterios de navegación x
Definir las actividades: Información,
preguntas, búsqueda, resolución de x
ejercicios, etc.
Definir los tipos de módulos a usar: de
evaluación, de problemas, de preguntas, x
etc.
Definir los tipos de ayudas didácticas:
x
errores, mensajes de ayuda, etc.
Desarrollar los algoritmos x x x x
Realizar el diseño detallado
Confeccionar la documentación x x
Proceso de implementación e integración de módulos
Crear los datos para las pruebas x x x x
Crear el código fuente x x x x
Generar el código objeto x x x x
Crear la documentación de operación x x x
Planificar la integración de los módulos x x x x
Proceso de instalación y aceptación
Planificar la instalación x x
Distribuir el software x x
Instalar el software x x
Cargar la base de datos si la hubiere x x
Aceptar el software en el entorno de x x
operación
Realizar las actualizaciones pertinentes x x
Proceso de operación y soporte
Operar el sistema/programa x
Proveer asistencia técnica y consultas on x
line.
Mantener el historial de pedidos de so- x
porte
Proceso de mantenimiento
Realizar el mantenimiento correctivo x
Reaplicar el ciclo de vida del software x
Proceso de retiro
Notificar al usuario x x
Conducir operaciones en paralelo x
Retirar el sistema x
Proceso de verificación y validación
Planificar la verificación y validación del x x x
software
Ejecutar las tareas de verificación y x x x x
validación
Recoger y analizar los datos de las mé- x x x x x x x x x x
tricas
Planificar las pruebas de V y V x x x x x x x
Desarrollar las especificaciones de las x x
http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

pruebas
Ejecutar las pruebas x x
Archivar los resultados x x x
Proceso de evaluación de los prototipos del software
Confeccionar el instrumento de evalua- x
ción
Evaluar internamente el programa x
Elaborar los resultados x
Identificar los cambios y ajustes a reali- x
zar
Llevar a cabo las modificaciones perti- x
nentes
Archivar los resultados x
Proceso de evaluación interna y externa del software
Confeccionar el instrumento de evalua- x
ción externa
Realizar la evaluación externa el pro- x
grama
Elaborar los resultados x
Llevar a cabo las modificaciones perti- x
nentes
Obtener la versión final del programa. x
Archivar los resultados x
Proceso de evaluación contextualizada
Diseñar la evaluación: definir grupo/s x
(caso de control y experimental), tiempo,
docente, materiales a usar y modo.
Aplicar de la prueba x
Identificar posibles problemas. x
Realizar las modificaciones y ajustes a x
la versión
Archivar los resultados x
Proceso de configuración
Planificar la gestión de la configuración x x x
Realizar la gestión de la configuración x x x x x x x
Realizar el control de la configuración x x x x x x x x x
Realizar la información del estado de la x x x x x x x x x
configuración
Proceso de documentación técnica
Planificar la documentación interna x x x
Planificar la documentación externa x x x
Implementar las documentaciones x x
Incluir los resultados de las evaluacio-
x x
nes
Elaborar el manual de usuario con in-
x x x x x x x
formación técnica.
Producir y distribuir la documentación x x x x x x x x x x
Proceso de documentación didáctica
Planificar la documentación didáctica x x x
Elaborar una guía didáctica, con ejem-
x x
plos de uso.
http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Adjuntar la información didáctica perti-

nente, los caminos pedagógicos, las
x
teorías de aprendizaje y la programa-
ción didáctica.
Producir la documentación y adjuntarla
x x x x
al programa.
Proceso de formación del personal
Planificar el programa de formación x x x
Desarrollar los materiales de formación x x x x x x
Validar el programa de formación x x x x
Implementar el programa de formación x x
Tabla 1: Matriz de actividades básica para un programa educativo, con ciclo de vida de prototipado evolutivo.

En la Tabla 2 se presentan los observar los métodos, las técnicas y las herramientas a emplear en cada uno de los
diferentes procesos descriptos en la matriz de actividades:

Procesos Documento de salida Métodos/Técnicas/

Herramientas a emplear
Proceso de selección del mode- Ciclo de vida adoptado
lo de ciclo de vida
Plan de gestión del proyecto Diagrama de Gantt o Pert
Proceso de iniciación, planifi-
(CPM)
cación y estimación del pro-
Modelos empíricos de estima-
yecto
ción
Análisis de riesgos y plan de contin- Modelizado. Prototipado.
gencias. Revisiones.
Proceso de seguimiento y con-
Registro histórico del proyecto Auditorías.
trol del proyecto (programa),
Análisis CPM.

Plan de garantía de calidad. Técnicas de planificación.

Proceso de gestión de calidad
Recomendaciones de mejora de
del software
calidad.
Proceso de exploración de Informe de necesidades
conceptos Posibles soluciones factibles
Especificación de requisitos funcio-
nales de hardware y software.
Proceso de asignación del
Especificación de interfaces del
programa (sistema).
sistema o programa. Descripción
funcional. Arquitectura.
Proceso de análisis de requisi- Especificación de los objetivos y
tos educativos estructuración de conceptos. Selec-
ción de contenidos y pertinencia.
Especificación de requisitos del
Proceso de análisis de requisi- software, de interfaces de usuario y
tos del software otros software. Interface de hardwa-
re y con el sistema físico.
Métricas de calidad del softwa-
re (Pressman, 2005)
Análisis Costo Beneficio.
DFD. Prototipazo
DFO
Módulos
Enfoques cognitivistas.
Enfoques constructivistas.
Estrategias cognitivas.
Análisis estructurado.
DFD. DD. Diagramas E/R.
Técnicas de Prototipación.
(Piattini, 1996).

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Identificación de los procesos men- Uso de estrategias cognitivas.

tales a estimular. Teoría de Ausubel y Novak.
Proceso de los Definición de las actividades a reali- (1998)
de diseño contenidos zar por los alumnos. Uso de mapas conceptuales.
Jerarquización de los conceptos. Novak y Gowin ( 1994)
Descripción del diseño del software Programación estructurada.
del softwa- y de la arquitectura. Programación Orientada a
re Descripción del flujo de informa- objetos.
ción, bases, interfaces y algoritmos. Técnicas de prototipado.
Datos para las pruebas. Lenguajes de Programación
Proceso de implementación e Documentación del sistema o pro-
integración de módulos grama y del usuario. Plan de integra-
ción.
Proceso de instalación Plan de instalación. Lenguajes de Programación
Informe de Instalación.
Proceso de operación y sopor- Histórico de pedidos de soporte Análisis estadístico.
te
Proceso de mantenimiento Recomendaciones de mantenimiento Reaplicar el ciclo de vida
Proceso de retiro Plan de retiro
Plan de verificación y validación Pruebas de caja negra y prue-
Proceso de verificación y vali- Plan de pruebas. Especificación y bas de caja blanca
dación resumen de la prueba.
Software probado.
Diseño del instrumento de evalua- Cuestionario estructurado, semi
Proceso de evaluación de los
ción. Resumen de la prueba. Selec- y abierto.
prototipos del software
ción de la muestra.
Diseño del instrumento de evalua- Cuestionario estructurado, semi
Proceso de evaluación interna
ción. Resumen de la prueba. Selec- y abierto.
y externa del software
ción de la muestra.
Diseño de la experiencia. Definición Técnicas de análisis pre-post.
Proceso de evaluación contex- de los grupos de control y experi- Test de Raven (1973)
tualizada mental. Prueba paramétrica de Wil-
coxon (Ledesma, 1998)
Proceso de configuración Plan de gestión de la configuración Base de datos
Proceso de documentación Plan de documentación técnica.
técnica
Diagramas
Proceso de documentación Plan de confección de la documenta- PERT y Gantt
didáctica ción didáctica.
Proceso de formación y capa- Plan de formación y capacitación
citación del personal
Tabla 2: Definición de los métodos, técnicas y herramientas a utilizar en cada proceso

4. El equipo de trabajo
La creación de programas educativos, es una tarea que compete a diferentes áreas del saber y para este tipo de pro-
yectos educativos es fundamental la formación y la conformación de los equipos de desarrollo.
Para ello, es necesario recurrir a especialistas en: desarrollos de software, planificadores eficaces y docentes conoce-
dores del área de experticia en que se desarrollará el programa, ya que en cada caso habrá que generar un modelo
pedagógico específico de acuerdo a las necesidades.

Profesionales del área en la Profesores y especialistas en pedagogía para

que se quiere desarrollar el determinar los contenidos a incluir y exper-

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

software tos en el área de desarrollo

Profesionales desarrollado-
res de software
Coordinador del proyecto
Personal técnico de apoyo
(diseño gráfico y sonido)
Tabla 3: Perfiles de lo profesionales del equipo de desarrollo.
Analistas y programadores. Para el análisis
del proyecto y la codificación.
Como en todo proyecto soportado por una
ingeniería de base, recaerá en el ingeniero
de software.
De acuerdo a las dimensiones del desarrollo
habrá operadores, diseñadores gráficos,
especialistas en sonido, vídeo.

Si bien, la conformación de los equipos de desarrollo para software comercial, es una instancia que requiere de la
habilidad del líder del proyecto y de la buenas relaciones entre los integrantes, en este caso en particular, la situación
se torna crítica, debido a la interdisciplinariedad del equipo, centrado en la tarea de integrar y coordinar profesionales
de campos disciplinares diferentes en pos del objetivo.
Básicamente; se necesitan los profesionales con los perfiles que se describen en la Tabla 3.
Algunos investigadores en tecnología y software educativos, como Marquès (1995) consideran que el proceso de
desarrollo del software debe estar centrado en el equipo pedagógico, pero como se deberá tener en cuenta que en el
programa a desarrollar se plasman las contribuciones de dos áreas del saber a través del logro de la calidad técnica la
cual es responsabilidad del equipo técnico y ése debe ser el eje central para un funcionamiento apropiado, ya que
diseñar y desarrollar software es responsabilidad de profesionales del área informática. Por otra parte, la determina-
ción de las tareas a asignar a cada uno integrantes del equipo de desarrollo en cada una de las etapas, juega un rol
crucial ya que el progreso de las mismas permite optimizar los tiempos de desarrollo.
Cabe señalar que en algunos casos que así lo requieran se recurrirá a asesores en tecnologías informáticas y de redes
muy específicas aplicadas a la educación, y a los psicopedagogos que orientarán al equipo cuando se requiera un
producto con alguna característica particular como ser destinatarios con necesidades especiales, cuya población se
deberá caracterizar.
En todo equipo de trabajo, uno de los aspectos a tener en cuenta es la definición precisa de las actividades que deberá
realizar cada uno de los miembros, es decir: “quién hace qué parte”, que facilita la identificación de los responsables
en cada una de las etapas de trabajo, y permite un seguimiento evolutivo de cada uno de los componentes del soft-
ware a lo largo de su desarrollo.
Por otra parte, de acuerdo al modelo de desarrollo propuesto, se llevarán a cabo evaluaciones del producto en las que
deberán intervenir todos los integrantes del equipo.

5. Acerca del diseño

Para diseñar el entorno de comunicación y cuando el equipo de desarrollo tiene poco conocimiento de programación,
comúnmente se utiliza la técnica de guiones o de “storyboard” o series de bosquejos de lo que serán las pantallas las
que se consideran como una puesta en común en común de las necesidades, y se llevan a cabo a partir del acuerdo de
todas las partes del equipo. De otro modo son los desarrolladores de software, con experticia en el diseño de interfa-
ces humanas los que elaborarán algunos prototipos de las pantallas a tal efecto. En este sentido, los guiones se usarán
solo como un punto de partida o base común entre docentes y programadores para interpretar los objetivos del traba-
jo.

Luego del análisis de los requisitos educativos, sobreviene el análisis de requisitos de software y la etapa de diseño
del software educativo que es una de las etapas más importantes en el ciclo de vida de este producto, donde deben
interactuar los especialistas en pedagogía y en contenidos con los de diseño software desde la perspectiva computa-
cional.
La etapa de diseño, se puede dividir en dos grandes subetapas: una es el proceso de diseño de los contenidos educati-
vos y la otra el proceso de diseño del software. Posteriormente, el diseño de los contenidos se integrará con el del
software, siendo este un punto crucial, ya que aquí es donde se ponen a prueba las estrategias cognitivas, para que el
alumno tenga la posibilidad de acceder al conocimiento a través de las diferentes actividades propuestas.

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Aquí, resulta fundamental la buena estructuración de los conceptos, considerando la definición correcta del tema, de
los objetivos propuestos y sobre todo de las actividades para que el alumno pueda acceder al conocimiento desde la
visión considerada.
En este sentido, es preciso definir claramente las tareas y las actividades, a través de las diferentes situaciones pro-
blemáticas referidas a la temática en cuestión que se le presenten al alumno. Se busca, que las tareas a ejecutar por
los estudiantes pueden estar definidas de acuerdo a dificultades incrementales y diferentes niveles de complejidad.
Se trata también de que el software sirva de soporte a la tarea docente, es decir que el mismo sea del tipo abierto por
lo que las tareas y actividades a realizar las podría proponer el mismo enseñante, a través de consignas claras y preci-
sas para sus propias necesidades.
Algunos autores, como Valencia (1998) plantean necesidad de llevar a cabo la realización de un análisis subjetivo o
sea, obtener un panorama total de la tarea, desde la perspectiva de la tarea misma y del sujeto que la resuelve, de su
nivel de dificultad, de la estructura, y de la forma en cómo se organiza y articula con los objetivos y posibles modos
de solución. Este autor plantea llevar a cabo un análisis desde la descripción objetiva de la consigna y el análisis
desde los factores que desde el punto de vista cognitivo problematizan y hacen significativo el conocimiento.

7. La documentación técnica y didáctica

Un aspecto a considerar que es de especial relevancia es el desarrollo de la documentación técnica a lo largo del ciclo
de vida del producto: ya sea esta documentación interna o externa. La primera considera a todos aquellos comenta-
rios del programa que serán útiles a la hora de realizar modificaciones posteriores, ya sea por el mismo equipo de
desarrollo o por otro. Aunque también hay que prever las ayudas on-line a los usuarios, para lo cual se deberá des-
arrollar un módulo especial a tal efecto.
La documentación externa, es la que se refiere a todo el material confeccionado a partir de la etapa inicial de análisis,
conteniendo los diagramas de entidades y relaciones, estructuras de datos, diagramas de flujos de procesos, diseño
modular descendente, etc., y toda aquella documentación que se considere pertinente para interpretar el desarrollo
del programa.
Por último hay que señalar la necesidad de incluir un manual del usuario claro y didáctico, para que el docente pueda
recurrir a él como elemento de ayuda. En este manual, se considerarán todos los aspectos técnicos requeridos para el
funcionamiento del programa y se podrá incluir una guía de soluciones, para aquellos problemas más frecuentes.
Se puede considerar también la confección de una “guía o manual didáctico”, para brindarle al docente todo aquello
que se considere necesario para su aplicación. En esta guía o manual de aplicaciones didácticas se debe dar referen-
cias acerca de: objetivos, contenidos, destinatarios, actividades propuestas, y sería adecuado incluir la teoría de
aprendizaje que sustenta al desarrollo y sobre todo cuál la forma del tratamiento de los errores de los estudiantes en
sus procesos de aprendizajes, que permite el programa.
También se deberán incluir los resultados de las evaluaciones efectuadas sean éstos positivos o negativos y detallar
cada una de las funcionalidades, considerando los aspectos técnicos, detallando los resultados estadísticos y teniendo
en cuenta el tipo de instrumentos elaborados para la toma de dichos resultados, pormenorizando como se hizo la
selección y se determinó el tipo de las muestras, y como se llevó a cabo la evaluaron el producto además de los crite-
rios que se utilizaron para la evaluación desde los puntos de vista técnico y pedagógico.

7. Otras cuestiones
Hay que señalar que tanto para proyectos grandes o pequeños, se podrán emplear algunos de los modelos disponibles
para realizar la estimación del esfuerzo, del tiempo y los recursos mediante un método convencional, del tipo CO-
COMOivv, puntos funcionales u otros. De este modo, se obtendrá el tiempo estimado de duración del proyecto, el
personal PSF (personal software full–time) requerido, y sobre todo el costo del proyecto, teniendo en cuenta la esti-
mación de las LDC (líneas de código) para realizar el cálculo lo que presupone experiencia previa en proyectos simi-
lares.

Recordando el principio de Gilb (1988) de los objetivos difusos: “los proyectos que no tienen objetivos claros, no
lograrán sus metas claramente”, se puede afirmar que l para poder llevar a cabo un proyecto de esta envergadura o
simplemente un conjunto de programas, es necesario partir de una buena planificación. Una buena planificación se
basa en una distribución eficiente de los recursos en el tiempo y para ello, se plantean metas y submetas, las que se
deberán cumplir de acuerdo a los diagramas calendario (o tipo Gantt) establecidos.

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

Para una buena distribución de los recursos es necesario partir de la definición clara de los requerimientos, y conti-
nuar haciéndolo a lo largo del ciclo de vida del software. Esto conlleva a un conocimiento acabado de todas las acti-
vidades involucradas con previsión de los recursos necesarios en cada una de ellas. Además se debe considerar la
serie de etapas que conforman el camino crítico y su repercusión sobre la duración total de proyecto (o programa) a
fin de estimar los posibles retardos y las holguras.
Desde el punto de vista metodológico, esta definición de los pasos a seguir, con las herramientas involucradas en
cada uno de ellos, significa disponer de una manera clara y precisa de una “hoja de ruta” para llevar a cabo el pro-
yecto. Piattini (1996) señala la necesidad y la importancia de las metodologías, para los desarrollos de software, y en
este caso particular se trata de un trabajo interdisciplinario lo que hace que tal necesidad sea mucho más importante,
ya que se deben realizar tareas coordinadas en conjunto y en paralelo.

8. Conclusiones
El aportes original de este trabajo consiste en la identificación de “carencias” en las metodologías de diseño de
software aplicadas al software educativo, ya que los aspectos pedagógicos que deben ser contemplados, por lo que se
planteó una solución partiendo de la una metodología de diseño basada en la Ingeniería de Software, ampliándose la
definición de las fases del ciclo de vida fases para dar solución al problema identificado.
Aunque no se describe en esta comunicación, fueron evaluados dos prototipos y el producto final, llevándose a cabo
evaluaciones internas y externas al equipo de desarrollo y en contexto similar al de uso. Como cita Cabero (2000),
habría que considerar la reacción de los alumnos más allá del efecto novedad y corroborar la prueba experimental a
fin de desechar posibles sesgos. Finalmente, se entregó una copia del trabajo de investigación a los docentes a quie-
nes se entrevistó inicialmente a fin de saber si la metodología respondió a sus expectativas, luego de un período de
aplicación deberán elevar un informe con las sugerencias vertidas.

9. Trabajo Futuros
Se prevé extender la matriz de actividades para otras metodologías de Ingeniería de Software con base en otras teorí-
as de aprendizaje y orientación a objetos a fin de comparar la eficiencia de las distintas metodologías que se propo-
nen y al ámbito de aplicabilidad y por otra parte, se piensa diseñar estrategias de infoalfabetización para docentes que
deseen aplicar y/o diseñar software educativo utilizando estas metodologías. Finalmente, se pensó la creación de
ambientes integrales de trabajo-estudio “diferenciadores” (Cabero Almenara, 2000) que estimulen los diferentes
sistemas simbólicos de los usuarios como favorecedores de los aprendizajes.

10. Referencias Bibliográficas y Obras de Consulta General

Ausubel D., Novak J., y Hanessian H. (1997): Psicología Educativa. Un punto de vista Cognitivo. Trillas.
Boehm B. (1978): Characteristics of Software Quality. Nueva York. North Holland.
Boehm B. (1981): Software Engineering Economics, Englewood Clifs, Nueva Jersey.
Cabero Almenara, J. (1992): Diseño de Software Informático. Universidad de Sevilla. Bordón, 44,4; 383-391.
Cabero Almenara, J. (2000): Tecnología Educativa. Editorial Síntesis.
Coll, C. (1994): Psicología y Curriculum. Paidós.
Fenton, N. (1991): Software Metrics. A rigorous and practical approach. PWS Publishing Company. Boston.
Gilb, T. (1988): Principles of software project management. Nueva York. Addison Wesley.
Ledesma, D. A. (1980): Estadística Médica. Eudeba
Novak, J. y Gowin, D. (1988): Aprendiendo a aprender. Martínez Roca. Barcelona
Piattini M. (1996): Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Rama. Madrid.
Pressman, R. (2005): Ingeniería de Software. Un enfoque práctico. Mc Graw Hill.
Raven, J. C. (1979): Test de Matrices Progresivas. Escala General. Vol. 3b. Paidós. Buenos Aires.
Raven, J. C. (1979): Test de Matrices Progresivas. Manual para la Aplicación. (con notas de Jaime Berns-
tein).Paidós. Buenos Aires
Valencia, M. E.; Toro, I. y Doneys, C. (1998): Desarrollo de aplicaciones hipremedia: propuesta para el diseño
educativo. TISE´98. Consultado en www.sofia,univalle.edu.co/gidse el 22/01/06.
Vigotzkii, L. (1978): Mind in Society. The development of higher psychological process. Cambridge. M. A. Harvard
University Press.

http://www.inf.udec.cl/revista
 Revista Ingeniería Informática, edición 13, noviembre de 2006

i
Esta comunicación ha sido publicada parcialmente en el Congreso Internacional de Ingeniería Informática ICIE 200 realizado en la Facultad de
Ingeniería de la Universidad de Buenos Aires.

iii
Por razones de claridad, en la Figura 1, no se ha represen las iteraciones a las etapas anteriores.
iv
El Modelo Constructivo de Costos (Constructive Cost Model) fue desarrollado por Boehm a finales de los 70 y comienzos de los 80, detallán-
dolo en su libro "Software Engineering Economics" (1981). Dicho modelo, COCOMO es una jerarquía de modelos de estimación de costes soft-
ware que incluye submodelos básico, intermedio y detallado.

http://www.inf.udec.cl/revista