BIBLIOTECAS DEL TECNOLÓGICO DE MONTERREY
PUBLICACIÓN DE TRABAJOS DE GRADO
Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de
grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como
parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en
versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor
(LFDA).
Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de
comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.
Cabe mencionar, que la Colección de
Documentos Tec,
donde se encuentran las tesis, tesinas y
disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del
Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,
para asegurar el uso restringido de dicha comunidad.
El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna
inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de
Formulación de un Modelo para Desarrollar Software
Educativo-Edición Única
Title
Formulación de un Modelo para Desarrollar Software
Educativo-Edición Única
Authors
Martha Yolanda Rodríguez Avilés
Affiliation
Tecnológico de Monterrey, Campus Monterrey
Issue Date
1995-12-01
Item type
Tesis
Rights
Open Access
Downloaded
18-Jan-2017 23:53:04
FORMULACIÓN DE UN MODELO PARA DESARROLLAR
SOFTWARE EDUCATIVO
TESIS
M A E S T R Í A E N A D M I N I S T R A C I Ó N D E S I S T E M A S D E I N F O R M A C I Ó N
I N S T I T U T O T E C N O L Ó G I C O Y D E E S T U D I O S S U P E R I O R E S D E M O N T E R R E Y
P O R
M A R T H A Y O L A N D A R O D R Í G U E Z A V I L É S
FORMULACIÓN DE UN MODELO PARA DESARROLLAR
SOFTWARE EDUCATIVO
TESIS
M A E S T R Í A E N A D M I N I S T R A C I Ó N D E S I S T E M A S D E I N F O R M A C I Ó N
I N S T I T U T O T E C N O L Ó G I C O Y D E E S T U D I O S S U P E R I O R E S D E
MONTERREY
P O R
M A R T H A Y O L A N D A R O D R Í G U E Z A V I L É S
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE
MONTERREY
DIVISIÓN DE GRADUADOS E INVESTIGACIÓN
PROGRAMA DE GRADUADOS EN INFORMÁTICA
Los miembros del comité de tesis recomendamos que la presente tesis de la
Lic. MArtha Yolanda Rodríguez Avilés sea aceptada como requisito parcial
para obtener el grado académico de Maestra en Administración de Sistemas
de Información
F O R M U L A C I Ó N D E U N M O D E L O P A R A D E S A R R O L L A R
S O F T W A R E E D U C A T I V O
POR
MARTHA YOLANDA RODRÍGUEZ AVILES
TESIS
Presentada a la División de Graduados e investigación.
Este trabajo es Requisito Parcial
para obtener el Título de
Maestra en Administración de Sistemas de Información
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE
MONTERREY
AI Dr. Javier Carrillo.
A mis sinodales:
A mi mamá y mi hija Maidi
Í N D I C E GENERAL
P R E S E N T A C I Ó N i
R E C O N O C I M I E N T O S v
Í N D I C E G E N E R A L vi
L I S T A D E F I G U R A S xi
L I S T A D E C U A D R O S xii
1. I N T R O D U C C I Ó N 1
1.1 D E L I M I T A C I Ó N D E L A I N V E S T I G A C I Ó N 2
1.2 I M P O R T A N C I A D E L E S T U D I O 2
1.3 O R G A N I Z A C I Ó N Y P R E S E N T A C I Ó N D E L T R A B A J O 2
2. D E S C R I C P C I Ó N DE LO Q U E ES UN S O F T W A R E 4
2 . 1 A N T E C E D E N T E S 4 2.2 C A R A C T E R Í S T I C A S D E L S O F T W A R E 5
2.3 S O F T W A R E E D U C A T I V O 6 2.4 C A R A C T E R Í S T I C A S D E L O S P R O G R A M A S EDUCACIONALES
P O R C O M P U T A D O R A 7
3. B A S E S C O N C E P T U A L E S PARA S U S T E N T A R EL M O D E L O 10
3.1 E L P R O C E S O D E L D E S A R R O L L O D E L S O F T W A R E 10 3.2. M O D E L O S D E D E S A R R O L L O D E S O F T W A R E 11
3.2.1 E L M O D E L O D E LAISSEZ-FAIRE PARA DESARROLLAR
S O F T W A R E 12 3.2.2 M O D E L O D E D E S A R R O L L O D E S O F T W A R E EN CASCADA... 13
3.2.3 M O D E L O R E U S A B L E PARA EL DESARROLLO
3.2.4 M O D E L O D E D E S A R R O L L O I N C R E M E N T A L 17 3.2.5 M O D E L O P R O T O T I P O P A R A EL D E S A R R O L L O
D E S O F T W A R E 2 0 3.2.6 M O D E L O D E D E S A R R O L L O D E S O F T W A R E E N E S P I R A L 2 3
3.3 O T R O S M O D E L O S D E D E S A R R O L L O D E S O F T W A R E 27
3.4 UN MODELO GENÉRICO DE DESARROLLO DE SOFTWARE 30
3.4.1 P O L Í T I C A S D E L M O D E L O G E N É R I C O D E D E S A R R O L L O
D E S O F T W A R E 3 5 3.4.2 P O L Í T I C A S D E A S E G U R A M I E N T O D E C A L I D A D 3 6
3.4.3 P O L Í T I C A S D E A D M I N I S T R A C I Ó N D E P R O Y E C T O S
D E S O F T W A R E 37
4 . C R E A C I Ó N D E L M O D E L O 3 9
4 . 1 . 1 A N Á L I S I S 4 0 4 . 1 . 1 . 1 A N Á L I S I S D E O B J E T I V O S 4 0
4 . 1 . 1 . 2 A N Á L I S I S D E R E Q U E R I M I E N T O S 41
4 . 1 . 2 D I S E Ń O 4 2 4 . 1 . 2 . 1 D I S E Ń A R L O S O B J E T I V O S 4 2
4.1.2.2 F L E X I B I L I D A D E N L O S C U R S O S A D I S E Ń A R 4 2 4.1.2.1MTNIMIZAR L A M E M O R I A D E L U S U A R I O 4 3
4.1.2.2 A D A P T A C I Ó N A LA E X P E R I E N C I A D E L
U S U A R I O 4 3 4.1.2.2.1 S O F T W A R E C O M E R C I A L 4 4
4 . 1 . 3 D E S A R R O L L O 57 4.1.3.1 E S P E C I F I C A R E V E N T O S Y A C T I V I D A D E S
D E A P R E N D I Z A J E 5 7
4 . 1 . 3 . 2 D O C U M E N T A C I Ó N D E L P R O G R A M A 5 8 4.1.3.3 S E L E C C I O N A R L O S M E D I O S Q U E SE V A N
4.1.3.3.1 I N T E R A C C I Ó N C O N P E R I F É R I C O S 5 9 4 . 1 . 3 . 3 . 2 M I N I M I Z A C I Ó N D E E R R O R E S 6 0 4 . 1 . 3 . 3 . 3 D E P U R A C I Ó N D E L O S D A T O S 61 4 . 1 . 3 . 3 . 4 R E C U P E R A C I Ó N D E E R R O R E S 61
4 . 1 . 3 . 3 . 5 A Y U D A S E N L Í N E A 61 4 . 1 . 3 . 3 . 6 I N T E R F A S E A M I G A B L E 6 2 4 . 1 . 3 . 3 . 7 C O M A N D O S R Á P I D O S 6 3 4 . 1 . 3 . 3 . 8 R E S P A L D O D E V E R S I O N E S 6 3
4 . 1 . 3 . 3 . 9 E D I C I Ó N 6 4 4 . 1 . 3 . 3 . 1 0 C O N T R O L D E F L U J O 6 4
4 . 1 . 3 . 3 . 3 . 1 1 A N Á L I S I S D E R E S P U E S T A 6 5
4 . 1 . 4 E J E C U C I Ó N 6 5 4 . 1 . 4 . 1 P U E S T A E N M A R C H A 6 5
4 . 1 . 5 C O N T R O L 6 6 4 . 1 . 5 . 1 C O N T R O L D E L A P R E N D I Z A J E 6 6
4 . 1 . 5 . 2 C O N T R O L D E L S I S T E M A 67
5 . C O N C L U S I O N E S 6 8
5.1 R E L E V A N C I A D E L M O D E L O P R O P U E S T O 68 5.2 B E N E F I C I O S D E L M O D E L O P R O P U E S T O 7 3
5.3 D I F E R E N C I A C I Ó N D E L M O D E L O P R O P U E S T O 7 4
L I S T A DE F I G U R A S .
Página
Figura 1. M o d e l o Laissez-Faire de Desarrollo de Software 12
Figura 2. M o d e l o de Desarrollo de Software en Cascada 13
Figura 3.Modelo Reusable para el Desarrollo de Software 16
Figura 4 . M o d e l o Incremental para el Desarrollo de Software 18
Figura 5.Actividades de un Incremento del Modelo Incremental 18
Figura 6.Las tres actividades típicas del modelo de Prototipo 21
Figura 7 . M o d e l o de Desarrollo de Software con prototipos 22
Figura 8.Modelo de Desarrollo de Software en Espiral 24
Figura 9.Modelo de desarrollo de sistemas de información 29
Figura 10.Modelo Genérico de Desarrollo de Software 34
F i g u r a 11.Modelo para desarrollar software educativo 68
F i g u r a 1 2 . A n á l i s i s 69
F i g u r a 1 3 . D i s e ń o 70
F i g u r a 1 4 . D e s a r r o l l o 70
Figura 15.Selección de los medios que se van a utilizar 71
F i g u r a 1 6 . E j e c u c i ó n 72
[image:14.612.69.484.101.619.2]L I S T A D E C U A D R O S
Página
C u a d r o 1. P r o g r a m a s e d u c a t i v o s por nivel 52
C u a d r o 2. H e r r a m i e n t a s para elaborar materiales 54
C u a d r o 3. P r o c e s a d o r d e m e d i o s 55
C u a d r o 4. U t i l e r í a s 57
Cuadro 5. Comparación de modelos para desarrollar software con
1. INTRODUCCIÓN
La tecnología para el aprendizaje es un campo dinámico y en expansión. Los padres y los educadores no cesan de intentar un mayor conocimiento de la naturaleza de las dificultades de aprendizaje y de la metodología para conseguir éxitos académicos y sociales .
Actualmente, el desarrollo de software educativo es un campo en crecimiento en el área de la enseńanza. Mediante el software educativo el hacer de la enseńanza una experiencia agradable y divertida es una posibilidad real. Asi, esta tecnología se ha ido convirtiendo en una herramienta de enseńanza efectiva lo cual se puede percatar en el programa Computación Electrónica en la Educación Básica (COEEBA), el cual se incorporó en la educación primaria en 1990. (ILCE, informe anual 1991).
La utilización de la computadora en el salón de clases es una de las experiencias pedagógicas más interesantes que se han puesto en práctica en el sistema educativo. Una sala de apoyo didáctico es un "Salón de clases común, en el cual se introducirá un elemento adicional que es la microcomputadora, y un monitor de 19 pulgadas en un mueble diseńado para la seguridad del equipo. Este será utilizado por el profesor como auxiliar didáctico para reforzar el proceso enseńanza-aprendizaje en los momentos que lo requiera." (SEP-ILCE,
1986).
Actualmente se desarrolla software educativo a todos los niveles, para preescolar, primaria, secundaria, tanto para personas con todas sus facultades mentales como para personas especiales. Existe software educativo para desarrollar las habilidades matemáticas, verbales y psicomotoras. (Buschman ,1992).
Sin embargo las rutinas de enseńanza permanecerán aplicándose en la escuela mientras " Jos maestros no diseńen sus propias estrategias instruccionales, mientras se sigan descifrando métodos de enseńanza importados de otras realidades." (Hernández, 1993).
En el presente trabajo se formula un modelo para el desarrollo de software educativo, debido a que por medio de la observación y la experiencia adquirida al trabajar durante ocho ańos, con profesores que de alguna u otra forma llevan a cabo software educativo, de una manera "artesanal", se propone el problema general que se enuncia a continuación:
"Formulación de un modelo para el desarrollo
de software educativo"
1.1 D E L I M I T A C I Ó N DE LA I N V E S T I G A C I Ó N
Esta investigación comprende el desarrollo de un modelo para realizar sofware educativo, en base a los modelos para desarrollar software ya existentes y a los modelos de aprendizaje convenientes.
1.2 I M P O R T A N C I A D E L E S T U D I O .
Se formulará un marco teórico para sustentar el modelo del desarrollo de software educativo y se establecerán los referentes o lincamientos de diseńo.
1.3 O R G A N I Z A C I Ó N Y P R E S E N T A C I Ó N DEL T R A B A J O Los temas se desarrollaron de acuerdo como se explica a continuación.
1. Descripción del software educativo, de la educación asistida por computadora y de la educación programada.
2. Modelos para desarrollar software, en este capítulo se expone el marco teórico que sustente el modelo de software a proponer.
3. Aplicación del modelo, en este capítulo se propone un modelo para desarrollar software educativo en base a los modelos mencionados.
4. Conclusiones, en donde se describen los beneficios del modelo y se hace la diferenciación con los vistos en el marco teórico.
5. Referencias bibliográficas, en donde se da la bibliografía utilizada en la elaboración de la presente tesis.
2 .
DESCRIPCIÓN DE SOFTWARE.
2.1 A N T E C E D E N T E S .
Durante las décadas de 1950, 1960 y 1970, los usuarios finales (o simplemente usuarios) dejaban las necesidades de información a los profesionales en computación, como los programadores o analistas de sistemas, quienes entonces trabajaban con el sistema de cómputo para generar la información requerida. En los "viejos tiempos", el tiempo total tardaba tanto, que la información resultante era a menudo obsoleta o de poco valor al momento de llegar al interesado. Como respuesta a las demandas de información más oportuna, se diseńaron los sistemas de cómputo interactivos, que permiten al usuario comunicarse directamente con el sistema por medio de un software que es "amigable con el usuario".
Generalmente son designados como programas de Enseńanza asistida por Computadora (EAC), la mayoría de los programas de aplicación didáctica, exceptuando el aprendizaje de un lenguaje de programación (Johnson,1978). Las clases de programas de EAC más conocidos según Johnson son:
- Ejercicios y prácticas - Programas de demostración - Programas de simulación - Sistemas expertos - Juegos educativos - Evaluaciones y tests.
Gran parte de las raíces de la EAC se funda en la psicología conductual y los trabajos de Skinner . "Si el conocimiento o las habilidades aprendidas pueden ser definidas
cuidadosamente, entonces, la secuencia de instrucciones para orientar la conducta puede ser desarrollada." (Moursund,1992')
2.2 C A R A C T E R Í S T I C A S D E L S O F T W A R E .
El nombre de software se refiere a los programas de computadora; puede referirse asimismo a los manuales que sirven de auxiliares a las personas que trabajan con el sistema computacional, como guías de lenguajes de programación y manuales técnicos para operadores de computadoras. (Parker,1987).
Los programas dirigen el sistema computacional para realizar tareas específicas, así como los pensamientos dirigen al cuerpo para hablar o moverse de cierta manera. Hay dos clases de software: el de sistemas y el de aplicaciones.
El software de sistemas consta de programas base que hacen posible que el software de aplicaciones se ejecute con facilidad. Una de las partes más importantes del software de sistemas es el sistema operativo, que es un conjunto de programas de control que supervisan el trabajo del sistema computacional. Visto de otra manera el sistema operativo hace posible que el software de aplicaciones interactúe con un conjunto específico de hardware.
El software de aplicaciones es escrito por usuarios o programadores para realizar tareas como el cálculo de interés, jugar juegos, diagnosticar las enfermedades de los pacientes de un hospital, en otras palabras, el software de aplicaciones es lo que hace posible el trabajo por computadora que las personas tienen presente cuando adquieren un sistema de computación.
En el presente trabajo la definición de software educativo que se utilizará es:" Los programas que tienen como misión controlar el sistema computacional con el fin de producir resultados concretos " (Parker, 1987).
2.3 S O F T W A R E E D U C A T I V O .
Un sistema computacional no hace nada hasta que se le ordena. Un programa, que consiste en instrucciones para la computadora, es el medio por el cual le mandamos ejecutar ciertas operaciones. Estas instrucciones son ordenadas y agrupadas en forma lógica mediante la etapa de programación. Los programadores utilizan varios lenguajes de programación, para comunicar instrucciones a la computadora. (Long, 1990).
Una computadora no es capaz de realizar cálculos o manipular datos sin instrucciones exactas dadas paso a paso. Dichas instrucciones toman la forma de un programa computacional. Para un sistema de información pueden requerirse cinco, cincuenta o hasta cientos de programas. El software de la hoja electrónica está constituido por docenas de programas que trabajan a la vez para poder realizar tareas de hoja electrónica. Esto mismo se aplica al software de procesamiento de palabra.
Cada programa resuelve un problema específico: calcular y asignar calificaciones, permitir la actualización de una base de datos, vigilar el ritmo cardíaco de un paciente, analizar datos de mercado, etc. De hecho, cuando se elabora un programa se está resolviendo un problema, debe llegarse a una solución, y para ello, deben usarse los recursos de la lógica.
Un programa es corno los materiales utilizados para construir un edificio. Mucho del trabajo intelectual involucrado en la construcción de un edificio está dentro del preproyecto.
El lugar, apariencia y la función de un edificio están determinados antes de que se coloque el primer ladrillo. Así sucede en la programación. El diseńo de un programa o su lógica de programación (preproyecto), son determinados antes de escribir el programa (o de que el edificio se construya).
Un programa Educativo es aquel escrito en cualquier lenguaje, para cualquier computadora, cuyo objetivo primordial sea el participar, como sustituto del maestro o como apoyo a aquel, en la tutoría de conocimientos o habilidades específicas que se enseńen en alguna asignatura o disciplina del conocimiento. (Johnson, 1978).
Las ventajas de un programa educativo en computadora son que se tiene disponibilidad las 24 horas, trabajo continuo y repetitivo sin descanso, almacenamiento de grandes volúmenes de información, capacidad de hacer grandes cantidades de cálculos en pocos segundos, capacidad para la utilización de imágenes, capacidad de interacción, instrucción personalizada. (Long, 1990)
2.4 C A R A C T E R Í S T I C A S D E L O S P R O G R A M A S E D U C A C I O N A L E S A I S I T I D O S POR C O M P U T A D O R A .
Las características de un programa para la enseńanza asistida por computadora (EAC) dependen de las circunstancias de la lección que quiere ser evaluada. Estas pueden ser según Michael Hannafin las siguientes:
1. Estar basada en objetivos instruccionales. los objetivos ayudan a desarrollar las actividades apropiadas, deben estar claros para que el diseńador, los estudiantes y los maestros puedan leerlos y entenderlos.
2. Las características de los aprendices deben ser iguales, el primer paso es estimar el conocimiento de la población estudiantil que usará el programa ya que las instrucciones deben ser apropiadas para el nivel de ellos.
3. Se debe maximizar la interacción, tal vez la mayor ventaja de la instrucción computarizada es el potencial de interacción que se tiene.
4. Se debe adaptar a las necesidades individuales de los estudiantes, la computadora tiene el potencial de adaptarse a la secuencia instruccional de los aprendices individualmente.
5. Debe mantener el interés en los estudiantes, la lección debe ser motivante intrínsecamente.
6. Debe acercarse a un aprendizaje positivo, la lección propiciará una conversación entre el programa y el estudiante en cada una de las sesiones, en muchos de los casos es actualmente innecesario informar al estudiante el número de preguntas contestadas incorrectamente.
7. Debe dar una gran variedad de retroalimentación, a los estudiantes les gusta aprender y tal vez en la mayoría de las veces una positiva retroalimentación es lo indicado cuando lo están haciendo bien.
8. Debe estar dentro de un ambiente instruccional, muchas de las lecciones desarrolladas por la escuela pueden ser utilizada individualmente por los estudiantes en un salón de clases estándar mientras el maestro y otros estudiantes están ocupados en diferentes actividades.
9. la evaluación debe ser apropiada, se debe ser cuidadoso al escoger los objetivos los cuáles deben ser medibles con facilidad.
10. Debe usarse el recurso de la computadora de una manera juiciosa, esto quiere decir que hay que aprovechar todos los recursos que nos da la computadora y que no parezca como una hoja de cualquier libro de ejercicios, hay que utilizar colores, gráficas, movimientos.
11. Debe estar basado en los principios del diseńo instruccional, una lección bien diseńada motiva al estudiante, informa al estudiante sobre los objetivos de la lección, revisa las destrezas que necesita el estudiante para lograr con éxito la lección presenta instrucciones bien organizadas, evalúa el progreso frecuentemente, da una adecuada retroalimentación permite una práctica adecuada y evalúa la ejecución final del estudiante y de la lección en si. (Gagné y Briggs, 1979).
12. Debe ser evaluada completamente, las lecciones deben ser evaluadas en varios niveles, por su calidad instruccional, sus consideraciones afectivas, y su relevancia curricular. Se debe evaluar qué tan atractiva es la lección para los alumnos, se eliminarán combinaciones ofensivas de colores, el abuso de información intermitente.
Para crear un software educativo de calidad es indispensable tener un buen modelo que sirva de guía en sti elaboración.
3 . BASES CONCEPTUALES
3.1 El p r o c e s o del desarrollo del software.
Desarrollar software no es una actividad rutinaria que pueda ser estructurada y reglamentada como si se tratara de maquila. No hay que olvidar que se trata de un trabajo intelectual que, además de ajustarse en forma dinámica a las necesidades, expectativas e intereses de quienes participan en su elaboración (practicantes, usuarios o clientes), debe dar lugar a un producto bien concreto: un sistema de software de buena calidad.
Bajo estas condiciones, no es difícil imaginar que la naturaleza del problema rebasa con frecuencia las capacidades de los profesionales involucrados, dando por resultado un trabajo desordenado. Por ello, es de gran utilidad contar con un proceso explícito de desarrollo de software, que:
Organice el conocimiento para desarrollar software y guíe al practicante para que pueda escoger entre varias alternativas de solución en forma consistente y ordenada.
• Ayude a los clientes y usuarios a comprender la naturaleza del proceso de desarrollo de software, sus ventajas, riesgos y limitaciones.
Facilite la comunicación entre el equipo de desarrollo de software, permitiendo compartir experiencias, soluciones a problemas, e incluso reutilizar programas. En síntesis, que permita crear una cultura en ingeniería de software.
O sencillamente, como Descartes lo dice categóricamente en su IV regla para dirigir el espíritu (Descartes, 1980):
"El método es necesario para la investigación de verdad."
Sin embargo, modelar un proceso de desarrollo de software no es trivial, implica poder balancear las necesidades de estandarización y consistencia organizacional, por un lado, y la necesidad personal de creatividad y flexibilidad, por el otro.
La reflexión de estas ideas pone de manifiesto la inexistencia de un proceso universal de desarrollo de software. Otros factores que confirman esto, son:
Dado que los proyectos de desarrollo de software pueden tener diferencias significativas; sus procesos también deben reflejar esas diferencias.
• Dado que los objetivos de cada organización, la naturaleza del software que produce, y la experiencia de su personal son distintos; sus procesos también deben ser distintos.
En conclusión, las organizaciones que desarrollan software deben adoptar, de acuerdo con sus necesidades, alguna forma sistemática de llevar a cabo su proceso de producción o, en su defecto crear un modelo propio.
3.2. M o d e l o s de desarrollo de software.
En términos generales, un modelo de desarrollo de software se puede visualizar como una descomposición del proceso de desarrollar software en actividades concretas que pueden ser planeadas y controladas.
Cada actividad debe proporcionar productos que puedan ser revisados para evaluar el avance del proyecto y programar los ajustes necesarios para cumplir los compromisos contraídos.
3.2.1 El modelo de Laissez-Faire para desarrollar software.
Este modelo de desarrollo de software es el más viejo y artesanal, se caracteriza por ser un proceso lineal donde el practicante codifica, sin mayor planeación, análisis o diseńo del sistema; las necesidades que sus clientes o usuarios le indican. Esta forma de trabajar prevalece en numerosas organizaciones, entre otras cosas porque la gerencia puede recibir resultados inmediatos de sus peticiones pero posee grandes desventajas, entre las que destacan:
F i g u r a 1. M o d e l o L a i s s c / . - F a i r c d e D e s a r r o l l o d e S o f t w a r e
• Generalmente, el software que se produce no satisface las necesidades de quién
lo solicita, porque no se analizan los verdaderos requerimientos del cliente.
• Casi siempre, el software que se produce no es fácil de mantener porque su
diseńo "adhoc", es muy poco flexible y no está documentado. La única
documentación es el código fuente del programa.
C o d i f i c a c i ó n
N e c e s i d a d e s d e l c l i e n t e
S o f t w a r e c o d i f i c a d o
Por regla general, el software que se produce tiene múltiple fallas, porque nunca se prueba sistemáticamente, y porque se modifica continuamente sin dejar huella de los cambios realizados.
• El software que se produce no es económico, porque no es posible planear las
actividades de programadores que trabajan a su modo, artesanalmente.
3.2.2 Modelo de Desarrollo de Software en Cascada.
Este modelo que surgió en 1970 (Royce,70), es hoy en día el modelo clásico y, considera
una de las mejores formas de desarrollar software en forma sistemática. Es un modelo que
se le ha llamado "En Cascada" por lo indispensable de cada actividad (caída) para realizar la
sucesiva.
Definición de objetivos
Especificación de requerimientos
A n á l i s i s d e o b j e t i v o s
A n á l i s i s d e r e q u e r i m i e n t o s
Documento de diseńo
D i s e ń o del Código
s i s t e m a
C o n s t r u c c i ó n del Doc. Pruebas s i s t e m a
P r u e b a s Man. Usu.
P u e s t a en m a r c h a
Figura 2. El M o d e l o de Desarrollo de Software en C a s c a d a
[image:28.612.78.530.386.627.2]A continuación se describen brevemente cada una de estas actividades:
Análisis de Objetivos, se destacan y analizan las necesidades de los clientes y usuarios hasta definir los objetivos de una solución viable cuyos beneficios justifican la realización del desarrollo de software.
Análisis de Requerimientos. Con base en los objetivos sintetizados en la actividad inicial, se analizan posibles alternativas de solución hasta que se definen y especifican los requerimientos del sistema de software por desarrollar.
Diseńo del Sistema de Software. Los requerimientos del sistema de software se traducen en una representación del sistema de software (diseńo) que ya se puede codificar.
Construcción del Sistema de Software. Se codifican los módulos o componentes que el diseńo del sistema de software describe, y se integran hasta obtener una representación ejecutable del mismo.
Pruebas de Software. Se verifica que cada componente del sistema de software realice su objetivo apropiadamente, y se valida que las funciones que realiza cumplen con los requerimientos del sistema.
• Puesta en marcha. Se instala el sistema de software a los usuarios y se deja el
sistema operando.
Probablemente la principal ventaja del modelo de desarrollo en cascada con respecto al
modelo de LaissezFaire es que se introduce una disciplina de trabajo bien estructurada que
redunda en los beneficios siguientes:
• Permite obtener software de calidad, porque es posible validar el sistema de
software contra sus requerimientos, mismo que fueron acordados en el análisis.
• Permite controlar la calidad del trabajo, previniendo los errores en cada actividad en
lugar de heredarlos a las actividades sucesivas.
• Permite aumentar la productividad del desarrollo del sistema de software porque su
aplicación disciplinada se puede planear, seguir y controlar.
• Permite reducir el costo real del desarrollo del sistema de software porque evita la
construcción de sistemas cuyos requerimientos no se han establecido.
• Permite reducir el costo real de mantenimiento del sistema de software porque
durante su desarrollo se genera documentación detallada de su diseńo, código y
operación.
Estos beneficios han hecho del modelo de desarrollo en cascada, el modelo clásico; sin
e m b a r g o , los resultados de su aplicación no siempre han sido tan halagüeńos
porque:
• Requiere de una estricta disciplina y control que pueda burocrati/arse cuando el
modelo se usa mecánicamente, sin criterio.
• Supone que una vez definidos los requerimientos del sistema de software, estos no
cambian durante el desarrollo. La verdad es que el usuario casi siempre solicita
cambios, entre otras cosas porque no sabe lo que quiere con nitidez.
La naturaleza intelectual del desarrollo de software impide que el trabajo pueda realizarse en actividades secuenciales, tal y como lo pide el modelo.
Por estas razones es recomendable el uso de este modelo cuando las necesidades del usuario se comprenden bien y no cambian durante el proyecto.
Existen diversas variantes del modelo de desarrollo en cascada, entre los cuales destacan los modelos de desarrollo reusable e incremental que ahora se describen.
3.2.3 Modelo Reusable para el Desarrollo de Software.
La idea que hay detrás de este modelo es valerse de la preconstrucción, pues es mucho más económico crear un sistema de software a partir de módulos o componentes preconstruídos o reusables; que crearlo a partir de ladrillos; instrucción por instrucción.
Definición de Objelivos
A n á l i s i s d e O b j e t i v o s
A n á l i s i s d e R e q u e r i m i e n t o s
Kspecificación de Requerimientos
Doc. de Diseńo (módulos nuevos)
D i s e ń o S i s t e m a
Código reusable
C o n s t r u c c i ó n Software integrado
I n t e g r a c i ó n
S i s t e m a Doc. IVuebas
P r u e b a s Doc. Usuario
[image:31.612.68.504.379.643.2]Puesta e n m a r c h a
Figura 3. El M o d e l o Reusable para el Desarrollo de Software
El punto débil de este modelo es que aunque la organización sea grande existan muchas posibilidades de que funciones similares hayan sido implementadas con anterioridad en aplicaciones distintas, casi siempre los módulos no son lo suficientemente generales para ser utilizados en las aplicaciones nuevas. Este problema se está resolviendo mediante el uso de nuevas técnicas que se están incorporando en forma sostenida a la práctica profesional: el diseńo y la programación de software orientadas a objetos (Meyer,1988).
Una variante importante de este enfoque es recurrir a paquetes comerciales de software cuando se trata de aplicaciones convencionales como una nómina, una contabilidad, un sistema de control de la producción, etc., pero aun decidiéndose por esta opción, es conveniente evaluar con cuidado, que paquete puede satisfacer los requerimientos del sistema de software de mejor forma.
3.2.4 Modelo de desarrollo Incremental.
El modelo incremental surgió de la necesidad de no perder el control en tiempo y costo de los grandes proyectos de desarrollo de software.
Para ello, tanto el análisis de objetivos como el de requerimientos se realiza de la misma forma que en el modelo de cascada. Sin embargo, el sistema se diseńa globalmente buscando una arquitectura que permita su construcción parcial en versiones increméntales. Finalmente, se construye el sistema en incrementos sucesivos que producen versiones más completas del sistema hasta obtener la versión definitiva.
D e f i n i c i ó n d e o b j e t i v o s
A n á l i s i s d e o b j e t i v o s
H s p c c i f i c a c i ó n d e R e q u e r i m i e n t o s
A n á l i s i s d e R e q u e r i m i e n t o s
A r q u i t e c t u r a del S i s t e m a
D i s e ń o G l o b a l del S i s t e m a
I n c r e m e n t o 1
I n c r e m e n t o n
F i g u r a 4. El M o d e l o Incremental para el Desarrollo de Software
Arquitectura del Sistema
Doc. Diseno (detalle)
D i s e ń o
D e t a l l a d o Código
C o n s t r u c c i ó n del S i s t e m a
Doc. Pruebas
P r u e b a s
Manual Usuario
Puesta en m a r c h a
F i g u r a 5. Actividades de un Incremento del M o d e l o Incremental
[image:33.612.74.547.70.301.2] [image:33.612.72.423.376.614.2]Cada incremento comienza con un diseńo detallado de la versión que se va a desarrollar, seguido de la construcción, las pruebas y la puesta en marcha, como en el modelo clásico.
Algunos consideraciones para la aplicación efectiva de este modelo son:
• Que los requerimientos puedan ser satisfechos en versiones parciales del sistema por
realizar.
• Que los cambios en las necesidades de los usuarios no destruyan la arquitectura del
sistema de software.
• Que las funciones que satisfacen las necesidades más estables del
usuario sean cubiertas desde las primeras versiones.
• Que exista un estricto control de la documentación del sistema para evitar
confusiones que se multipliquen conforme se desarrollan las versiones nuevas.
Entre los beneficios del modelo incremental destacan los siguientes:
• Menor rigidez. Permite que dentro de las restricciones de diseńo que se hayan
impuesto originalmente, sea posible adaptar el sistema a los cambios de necesidades
del usuario.
• Permite proporcionar versiones operativas del sistema, en un tiempo y a costo
mucho más razonables.
• Permite, en un corto plazo, demostrar al usuario muchas de las bondades que el futuro sistema va a poseer.
En términos generales, se recomienda el tiso del modelo incremental cuando el sistema por desarrollar es muy grande o demanda tiempos de desarrollo muy largos, y cuando se está cierto que las necesidades de los usuarios evolucionan paulatinamente.
Buscando darle una mayor flexibilidad al desarrollo de software han surgidos nuevos modelos entre los que destacan los modelos de Prototipo y en Espiral que aparecen en seguida.
3.2.5 M o d e l o Prototipo para el Desarrollo de Software.
Realizar un prototipo (Smith,91) es un proceso que permite al practicante crear un modelo del software por construir. Por ello, la aplicación de este modelo de desarrollo es particularmente útil para concretar los requerimientos del software, sobretodo cuando estos son muy volátiles. En esta situación, el modelo del prototipo permite tender un puente de comunicación con el usuario para conocer sus necesidades auténticas.
Una vez elegido este modelo, puede ser necesario la creación de más de un prototipo (prototipo evolutivo) para determinar los requerimientos que el usuario desea.
Para hacer un prototipo sin caer en un desarrollo Laissez-Faire, se sugiere considerar las tres actividades típicas que aparecen en la figura.
Definición del Prototipo.
Desarrollo del Prototipo.
(Bosquejo de Diseńo y Construcción)
evaluación del Prototipo obtenido.
Figura 6. L a s tres actividades típicas del m o d e l o de Prototipo
Definición del Prototipo. Primero se justifica el uso de este modelo, y después se establece el objetivo del prototipo, su alcance, el plan de trabajo, y los recursos requeridos, tanto de hardware como de software.
Desarrollo del Prototipo. Se bosqueja el diseńo del prototipo y se construye usando un medio propicio (diagramas en papel, programa automático, etc.).
• Evaluación del Prototipo. Se analizan las fuerzas y debilidades del prototipo con
el usuario y se documentan los requerimientos del sistema que se hallan
Una vez que se han experimentado las soluciones que se deseaban, a través de uno o más
prototipos, todavía falta una actividad más por realizar:
• Liberación del Prototipo. Se implanta el sistema de software en forma sistemática
(usando cascada, incremental u otro) a partir de los requerimientos obtenidos por los
prototipos a menos que estos hayan evolucionado hasta alcanzar un prototipo operativo detectado.
[image:36.612.87.434.74.262.2]que el usuario desea tal como está. En esta situación, el usuario debe recibir apoyo directo para corregir las fallas de un sistema que no se hizo en forma sistemática.
Prototipo 1
Prototipo n
Liberación
F i g u r a 7. M o d e l o de Desarrollo de Software con Prototipos
Un uso adecuado del modelo de prototipo requiere que exista:
Necesidad de capturar las verdaderas necesidades del usuario, mediante la experimentación de soluciones que el usuario pueda ver.
Factibilidad de realizar el prototipo en un corto periodo de tiempo.
Familiaridad de los desarrolladores con herramientas que faciliten un trabajo eficaz.
• Participación activa de los usuarios.
Sin embargo, el uso del modelo de prototipo puede acarrear los problemas siguientes:
[image:37.612.92.484.114.361.2]Muchas veces es difícil saber cuando parar de hacer prototipos.
No es fácil hacer un contrato.
Si no se toman las medidas adecuadas, el proceso de desarrollo del sistema puede degenerar en el modelo Laissez-Faire.
• El mantenimiento de la documentación puede ser difícil debido a los múltiples cambios.
Todo esto nos conduce a recomendar el uso de este modelo cuando:
• Las funciones o interfases de la aplicación no se entienden.
• No se sabe si el sistema podrá tener el desempeńo que exige la aplicación.
• El usuario tiene poca preparación o tiempo para el análisis del sistema, o
simplemente hace falta que el usuario se involucre en el desarrollo del sistema.
• No se sabe de que manera diseńar el sistema en un producto sólido.
3.2.6 M o d e l o d e D e s a r r o l l o de S o f t w a r e en Espiral.
El modelo de desarrollo de software en Espiral (Bohem,88)surgió de la necesidad de contar
con un modelo que superara las deficiencias del modelo clásico.
Desarrollar software usando el modelo de cascada implica mucha disciplina y poca
flexibilidad algo que se ha ido superando mediante el uso de variantes como los modelos
incremental y reusable o, a través de incorporaciones de prototipos; sin embargo, su
principal inconveniente prevalece: la necesidad de contar con documentos totalmente
elaborados como criterio de terminación de una actividad y requisito para pasar a la
siguiente. Esto ha dado como resultado que con frecuencia se especifiquen documentos elaborados de problemas pobremente comprendidos, especialmente cuando se trata de aplicaciones con una alta interacción con el usuario directo.
Para superar estas dificultades, el modelo de desarrollo en espiral avanza paulatinamente de los objetivos de la aplicación hacia el producto final tan rápidamente como sea necesario, según se vayan resolviendo los riesgos de la aplicación, es decir, el modelo de desarrollo en espiral está dirigido por riesgos y no por la elaboración de documentos.
O B J E T I V O S R E S T R I C C I O N E S A L T E R N A T I V A S
E V A L U A C I Ó N D E A L T E R N A T I V A S ( A N Á L I S I S DE R I E S G O S )
R E S O L U C I Ó N D E R I E S G O S
P r o l o l i p o 1 P r o t o t i p o 2
P r o t o t i p o P r o t o t i p o 3 \ O p e r a t i v o
Inic
Plan d e Definición
C o n c e p t o d e la O p e r a c i ó n
Plan d e D e s a r r o l l o
Definición S o f t w a r e
D i s e n o
S o f t w a r e C o d i f i c a c i ó n Plan d e
P r u e b a s
P L A N E A C I O N
( S I G U I E N T E S E T A P A S )
P r u e b a s
D E S A R R O L L O D E P R O D U C T O S
Figura 8. M o d e l o de Desarrollo de Software en Espiral
[image:39.612.77.554.234.621.2]En cada ciclo de la espiral, este modelo contempla actividades que surgen dinámicamente al plantearnos las preguntas adecuadas y responderlas, en forma similar a como George Polya lo propone en su libró clásico (Polya,65).
A continuación aparece un bosquejo del esquema general de preguntas por considerar:
Determinación de objetivos, alternativas y restricciones, (primer cuadrante de la figura)
żCuáles son los objetivos del producto o la porción de éste que se desea realizar y Porqué? (el sistema, o sus funciones, o su velocidad respuesta, etc.; y que se gana con lograrlo)
żCuáles son las alterativas para alcanzar los objetivos planteados? (compra de software, desarrollo interno, contratación externa, mantenimiento del software que existe, etc.)
żQué restricciones debe satisfacer la solución y cualquier alternativa factible? (costo, tiempo, equipo, etc.).
Evaluación de alternativas, identificación y resolución de riesgo, ( s e g u n d o cuadrante de la figura)
Desde la perspectiva de cada alternativa factible, żcuáles son las principales áreas de incertidumbre que pueden causar mayor riesgo el logro de los objetivos?
• Si hay incertidumbres o riesgos, żCon qué estrategia se pueden resolver?
(análisis, prototipo, simulación, benchmarks, uso de cuestionarios, literatura,
etc.)
• żCuál(es) alternativa(s) satisface(n) los objetivos y restricciones del ciclo con
menos rieseo?
Se resuelven los riesgos de la alternativa escogida.
Desarrollo y verificación del producto. Siguiente producto, (tercer cuadrante de la figura).
Se elabora el producto a partir de la estrategia de la alternativa escogida
Se verifica el producto
Se indica el siguiente producto a obtener.
Planeación de los ciclos sucesivos, (cuarto cuadrante de la figura)
Se planea la obtención del siguiente producto
• Se revisan los productos obtenidos durante el último ciclo.
Las partes involucradas se comprometen a realizar el siguiente ciclo.
Algunas de las ventajas más importantes de este modelo son:
• Su universalidad. Dependiendo de los riesgos de cada proyecto, el modelo en espiral se puede transformar en cualquiera de los modelos antes citados.
Se previenen errores, en lugar de propagarlos como bien puede suceder en el modelo de cascada.
• Se absorben los cambios a los productos del desarrollo.
Permite poner en un mismo contexto el desarrollo y el mantenimiento de hardware y software.
Entre sus principales desventajas (actuales) podemos citar:
• La contratación de software, porque la aplicación del modelo requiere de una
flexibilidad qtie no tiene la rigidez de los contratos del software comercial.
• La necesidad de contar con expertos en análisis de riesgo. En ausencia de tales
expertos el modelo puede convertirse en un proceso sin rumbo, caótico.
La necesidad de una mayor elaboración de las actividades que forman el modelo.
3.3 O t r o s m o d e l o s d e d e s a r r o l l o d e software.
Hasta el momento se han revisado algunos de los modelos más utilizado este campo; sin
embargo existen muchos otros, como ahora veremos en área aparentemente dominada: los
sistemas de información (Galván,92); pero, antes de continuar vale la pena preguntarnos:
żPorqué considera modelo diferente al modelo clásico para el desarrollo de sistemas de
información?
La pregunta parece extrańa, pues desde los 7()'s (Codd,70) se conocen técnicas efectivas
para el diseńo de bases de datos, y ahora los lenguajes de cuarta generación se han
encargado de facilitar el diseńo de pantallas y reportes, el mantenimiento de las bases de
datos e incluso el manejo de la información dentro de una red de computadoras. En
resumen, desarrollar sistemas de información ya no se considera un reto tecnológico, sin
embargo, a pesar de todos estos avances, los problemas siguen siendo de naturaleza no
técnica y fundamentalmente los mismos (Martin,88).
• Tiempo insuficiente de desarrollo.
• Revisiones insuficientes o ineficientes con los usuarios.
• Diferencias de opinión.
• Cambios políticos.
• Falta de conocimiento técnico.
• Incapacidad para comunicarse bien.
Como podrá observarse, estos problemas tienen que ver con la manera de concebir el sistema, con buscar un consenso entre patrocinadores, desarrolladores y usuarios acerca de lo que el sistema debe realizar, evitando caer en situaciones como esta (usuario incomprendido) (Pressman,88):
" Si que crees haber comprendido lo que piensas que dije, pero no estoy seguro de que te des cuenta, que lo que tu oíste no es lo que yo quería decir".
T r a t a n d o de solucionar esta problemática, Alavi puso a dos grupos de estudiantes de la Universidad de Florida a desarrollar sistemas de información (Alavi,91). El primero usó el modelo del prototipo (evolutivo) encontrando buenos resultados, aunque superados por el segundo. En éste, también se uso el mismo modelo de desarrollo, pero antes de construir los prototipos, se modelaron las bases de datos de los sistemas.
Estos resultados parecen lógicos, pues:
a) La base de datos es la columna vertebral de los sistemas de información y
b) El uso de prototipos es muy conveniente para involucrar al usuario en definición de procesos complejos o de las E/S, en forma de mantenimientos o consultas a la base de datos; o también reportes informativos (estadísticos).
Definición de Objetivos ^
Determinación inicial de Requerimientos 2 F u n c i o n a l e s y de Información
Desarrollo del prototipo usando prototipos en papel una herramienta 4 G L
^ Evaluación del Prototipo 4
Si żes satisfactorio?
Si 5
- Liberación
N o
4 — Modificación del Prototipo 4
3
F i g u r a 9. M o d e l o de desarrollo de sistemas de información
1. Según este modelo, el desarrollo del sistema de información comienza identificando y describiendo las necesidades del usuario a fin de proponer un conjunto de objetivos, que de lograrse, implicarán la satisfacción de sus necesidades.
2. En este paso, se identifican los requerimientos iniciales del sistema tanto funcionales como de información . El trabajo se centra en comenzar a definir los servicios que ofrecerá
[image:44.612.89.479.63.504.2]el sistema. Para ello, se pueden utilizar diagramas conceptuales de usuario (Martin,88) pues proporcionan una idea clara y simple del sistema (Galván,92).
Al mismo tiempo, que se modela conceptualmente la base de datos utiliza una variación muy adecuada del modelo de entidad-relacionamiento modelo ELKA (Rodríguez,81).
3. Durante los primeros prototipos se utilizaron los diagramas conceptuales de usuario como forma de comunicación con el usuario, pero posteriormente esta comunicación es menos en papel y más automática. Según las necesidades, el prototipo puede ser un cascarón de menús, el cascarón de uno o más servicios, etc.
4. Se recaban los requerimientos funcionales y de información obtenidos con el prototipo recién planteado y se modifica o se diseńa un nuevo prototipo según sea el caso. Únicamente se dejan de crear prototipos cuando los requerimientos son lo suficientemente claros y completos como para proceder a una liberación.
5. Se desarrolla el sistema siguiendo el modelo tradicional (cascada) una vez que existe acuerdo entre desarrolladores y usuarios acerca de los requerimientos del sistema.
3.4 U n M o d e l o G e n é r i c o de Desarrollo de Software.
Es muy factible que los modelos de desarrollo de software que se acaban de describir sean parcialmente adecuados a las necesidades concretas de una organización, ya sea porque no son lo suficientemente detallados o porque no contemplan algunas actividades de relevancia para el proceso de desarrollo de software que requiere la institución, por ejemplo: el estudio de mercado que identifica las necesidades de los usuarios potenciales de un paquete comercial de software en ciernes, (Digital, 89) es parcialmente irrelevante para desarrollar software hecho a la medida de una organización.
Estas ideas son útiles para ir tomando consciencia de que hacer un modelo completo de un proceso complejo como es el desarrollo de software, tiene que ser complejo.
Por esta razón, antes de comenzar a diseńar el proceso de desarrollo de software es conveniente tener una visión amplia del mismo, como lo dice la regla Vil para dirigir el espíritu de Rene Descartes (Descartes, 1680):
"Para completar la ciencia, es preciso, por un movimiento continuo del pensamiento, recorrer todos los objetos que se relacionan con el fin que nos proponemos, y así abarcarlos en una enumeración suficiente y ordenada."
El resultado de este esfuerzo puede resultar en un ordenamiento del trabajo que está dirigido por actividades, como en el modelo de desarrollo en cascada, o que está dirigido por riesgo como en el modelo en espiral, o en algún otro ordenamiento (Yeh,1991).
El problema de esta forma de proceder es que es muy probable que el modelo de desarrollo de software sea detallado en aspectos poco relevantes y pase por alto aspectos cruciales. Por esta razón, es recomendable partir de un modelo más conceptual, un modelo genérico de desarrollo de software que:
*Esté contextualizado dentro del marco de madurez. Esto significa que el modelo debe dar énfasis a las actividades siguientes (nivel repetible) (Humprey,89):
• Estimación, planeación y seguimientos de proyectos
• Organización y control de la documentación
• Aseguramiento de calidad en los proyectos
* Permita detallar los modelos de desarrollo de software que la organización necesita.
En nuestro caso, un modelo genérico lo más universal posible para que sea útil a
c u al q u i e r o rgan i zac i ó n.
Recurriendo a la regla Vil de Descartes bajo las consideraciones recién mencionadas, se puede visualizar el proceso de desarrollo de software desde dos ángulos distintos: como un proceso interdisciplinario que involucra la interacción cooperativa de distintas especialidades para construir el software disciplinadamente; y como un proceso de producción compuesto de etapas genéricas (no necesariamente secuenciales) que buscan, sistemáticamente, obtener un producto de calidad a partir de las necesidades de los usuarios.
Cabe reconocer que este modelo se originó del trabajo de caracterización de una guía de desarrollo de software para el Instituto de Investigaciones Eléctricas (Galván,91), una organización que desarrolla toda clase de aplicaciones de software para el sector eléctrico mexicano.
Desde el primer ángulo, se deben considerar cuando menos tres especialidades distintas para poder alcanzar el nivel repetible (Humphrey,89):
Desarrollo de Software
Administración de Proyectos de Software Aseguramiento de Calidad.
Sin embargo, la organización puede demandar otras, como la Trasferencia de Resultados, El Mejoramiento Institucional. El Trato al Cliente (Galván,91). etc. Las tres primeras se describen a continuación:
a) Desarrollo de Software.
Agrupa el conjunto de actividades para definir las necesidades del usuario hasta hacer explícitos los requerimientos de software, implementar estos requerimientos en un producto y liberar el producto para su uso operativo por los usuarios.
b)Aseguramiento de Calidad.
Agrupa el conjunto de actividades de control de calidad que permiten asegurar que el sistema de software producido satisface adecuadamente a las necesidades que demanda el usuario.
c) Administración de Proyectos de Software.
Agrupa actividades que permiten dimensionar la magnitud de las componentes que conforman los sistemas de software para estimar su de desarrollo, planear el trabajo, y dar seguimiento a su ejecución; asimismo establece la manera en que se organizará y controlará la documentación del trabajo.
Por lo que respecta a las etapas genéricas, se desean considerar sólo las necesarias para permitir la aplicación de cualquiera de los modelo de desarrollo de software que se han descrito u otros:
Etapa de Definición
• Etapa de Implementación
Etapa de Liberación
Etapa de Definición.
En esta primera etapa se entiende la naturaleza del problema por resolver
planteándose los objetivos, alcance y características del software por desarrollar. Se
proponen alternativas de solución, y. se recaban los requerimientos de la solución
escogida que definen el producto de software por implementar.
Etapa de Implementación.
El propósito de esta etapa es diseńar, construir, probar y/o evaluar software que
satisfaga los requerimientos que se estipularon en la etapa de definición. Los
productos típicos de esta etapa son el código, fuente y objeto; así como la
documentación, de diseńo y de usuario.
f) Etapa de Liberación.
Comprende el periodo de tiempo en que el sistema de software implementado se integra a su medio ambiente operativo y ahí se prueba para asegurar que se desempeńa como se requiere.
LIBERACIÓN
[image:49.612.76.519.139.506.2]A d m i n i s t r a c i ó n Desarrollo de P r o y e c t o s de Software
Figura 10. M o d e l o Genérico de Desarrollo de Software
La generalidad del modelo de desarrollo de software que se acaba de describir es tan abierta que permite desarrollar software como se desee, por ello es conveniente establecer algunas políticas: lineamientos de tiso apropiado del modelo.
A s e g u r a m i e n t o de Calidad
3.4.1 Políticas del m o d e l o genérico de desarrollo de software.
Organizadas por especialidad, las políticas que acompańan al modelo genérico de desarrollo de software son:
Políticas de Desarrollo de Software.
1. Juiciosamente se debe seleccionar y usar un modelo de desarrollo de software que sea un refinamiento del modelo genérico.
Esta política dice que para desarrollar software hay que utilizar alguna implantación del modelo genérico de desarrollo de software como son los modelos cascada, espiral, etc.
2. Se deben definir las necesidades de los productos antes de implantarlos.
Esta política pretende prevenir la implementación de un producto (sistema de software, prototipo, etc.) sin saber que es lo que se va a implantar. En particular, evita que el modelo Laissez-Faire de desarrollo de software pueda ser utilizado.
3. Se deben establecer las condiciones de la transferencia del sistema de software antes de liberarlo.
4. La nueva tecnología en forma de equipos, herramientas de trabajo ométodos debe seleccionarse e incorporarse al trabajo con cuidado, pues puede deteriorar el control del proceso de desarrollo de software.
La incorporación de nuevas tecnologías puede implicar la necesidad de: usar nuevos modelos de desarrollo de software, ajustar o crear estimadores de tamańo, tiempo y costo de proyectos de software; y por supuesto capacitar al equipo de desarrollo. Un conjunto de factores que pueden convertir un proceso de desarrollo de software que ya es predecible en otro caótico.
3.4.2 Políticas de A s e g u r a m i e n t o de Calidad.
1. El aseguramiento de calidad debe tener un canal de reporte independiente al del equipo de desarrollo de software.
El aseguramiento de calidad requiere de independencia del equipo de desarrollo de software con el fin de que sus juicios sean confiables, y en base a ellos, la dirección pueda tomar decisiones apropiadas.
2. Los productos que se obtengan de cada etapa genérica deben verificarse.
Esta política pretende establecer el mínimo de revisiones que cualquier desarrollo de software debe tener. Naturalmente, el modelo de desarrollo de software que se use puede requerir de verificaciones adicionales.
3. El sistema de software que resulte de la implantación debe satisfacer los requerimientos acordados con el cliente.
Esta política no es más que una forma de establecer lo que significa producir software de calidad.
4. Se debe capacitar a los recursos humanos, pues son el elemento más importante para producir software de calidad.
No importa que tan buenos recursos materiales tenga una organización que tan bien definido esté su proceso de desarrollo de software, si sus recursos humanos son incompetentes, el desarrollo de software será deficiente.
3.4.3 Políticas de Administración de Proyectos de Software.
1. Se requiere de un sistema de compromisos que vayan desde el programador hasta el director de la organización.
Desarrollar software es un trabajo de equipo con riesgos considerables que requiere de responsabilidades claras para todos los que participan.
2. Se deben usar modelos de desarrollo de software cuyas actividades se puedan estimar, planear y programar.
Esta es una característica que se pide a los modelos con el fin de que el desarrollo de software pueda ser predecible en tiempo y costo.
3. Antes de comprometerse se debe estimar juiciosamente: el tamańo del producto, el tiempo de desarrollo y el costo de los recursos humanos y materiales que requerirá el proyecto de desarrollo de software.
En ausencia de esta estimación, lo más probable es que se contraten proyectos de desarrollo de software cuyos compromisos no se cumplirán ni en tiempo, ni en costo, ni mucho menos en lo que se refiere a la calidad del producto.
4. El sistema de compromisos debe permitir la acción concertada de los participantes en los proyectos de desarrollo de software y un seguimiento efectivo de los mismos.
El sistema de compromisos debe permitir darle seguimiento al trabajo sin obstaculizar su ejecución, es decir sin burocratizarlo.
5. Durante el seguimiento de cada proyecto de desarrollo de software se deben recolectar mediciones administrativas, particularmente de tamańo, tiempo y costo.
Las mediciones administrativas son la base del control estadístico que permiten mejorar un proceso de desarrollo de software del nivel inicial al repetible.
6. La documentación del proyecto de desarrollo de software debe estar organizada y controlada para que el equipo de desarrollo de software pueda hacer un uso operativo de ella.
El proceso de desarrollo de software es un trabajo intelectual que se materializa en multitud de documentos que si no se organizan y controlan, generan una torre de babel para el equipo de desarrollo de software.
4. CREACIÓN DEL MODELO.
En base a los modelos expuestos en el marco teórico y a la descripción del software, se propone el siguiente modelo para desarrollar software educativo:
I. ANÁLISIS.
1.1 Análisis de objetivos.
1.1.1 Analizar el resultado deseado. 1.1.2 Presentar las metas a alcanzar.
1.1.3 Describir el comportamiento final esperado.
1.1.4 Describir las destrezas que el educando debe evidenciar. 1.2 Análisis de requerimientos.
1.2.1 Analizar el equipo de trabajo.
1.2.2 Analizar las herramientas de desarrollo.
II. DISEŃO.
2.1 Diseńar los objetivos.
2.1.1 Flexibilidad en las estrategias de los cursos a diseńar. 2.1.2 Minimizar la memoria de usuario
2.1.3 Adaptación a la experiencia del usuario. 2.1.3.1 software comercial
III. DESARROLLO.
3.1 Especificar ios eventos y actividades de aprendizaje. 3.2 Documentación del programa.
3.3 Seleccionar los medios que se van a utilizar. 3.3.1 Interacción con periféricos.
3.3.2 Minimización de errores. 3.3.3 Depuración.
3.3.4 Recuperación de errores
3.3.5 Ayuda en línea. 3.3.6 Interfase amigable 3.3.7 Comandos rápidos. 3.3.8 Respaldo de versiones. 3.3.9 Edición
3.3.10 Control de flujo. 3.3.11 Análisis de respuesta.
IV. EJECUCIÓN.
4.1 Puesta en marcha.
V. CONTROL.
5.1 Control del aprendizaje 5.2 Control del sistema.
El desarrollo de los pasos anteriores se da a continuación:
1. ANÁLISIS.
1.1 ANÁLISIS DE OBJETIVOS.
En donde se destaca y analiza el resultado deseado, se presentan las metas a alcanzar , se describe el comportamiento final esperado, esto es, el comportamiento que pueda ser observado más tarde por más de una persona, se describen las destrezas que el educando debe evidenciar.
Se indican las condiciones en las que el comportamiento debe manifestarse, asi como el criterio de apreciación del desempeńo, para que se le considera aceptable o no.
Se seleccionan, analizan y jerarquizan las conductas y/o competencias que se quieren lograr en los alumnos, determinando los posibles prerequisitos y conductas de entrada.
1.2 ANÁLISIS DE REQUERIMIENTOS.
Con base en los objetivos se analizan posibles alternativas de solución, hasta que se definen y especifican los requerimientos del sistema de software a desarrollar.
1.2.1 El equipo de trabajo, la preparación y el soporte técnico.
Un equipo de trabajo multidisciplinario logra resultados más rápidamente y obtiene productos más profesionales.
Para conformar el equipo interdisciplinario se sugieren los siguientes profesionistas:
educadores, programadores, diseńadores,
• ayudantes qtie preparen la documentación y los ejercicios.
Sin e m b a r g o , hay que considerar que el equipo de trabajo es mucho más difícil de
coordinar ya que puede haber serios problemas de motivación y que aunque un profesor
requiere de más tiempo inicial para obtener resultados, los productos en la madurez de su
trabajo son más creativos y el costo es mucho menor.
1.2.2 Las herramientas de desarrollo.
Tipos de herramientas que se puden utilizaren el desarrollo del software son:
a) Presentaciones: Power Point. Persuasión.
b) Mediana Interacción HyperCalc. HyperTalk. Director.
c) Programación con lenguajes Normales: C, Pascal, QBasic.
Específicos: cT, Tutor, Fantavisión, Visual Basic, Hypercard.
2 DISEŃO.
2.1 DISEŃAR LOS OBJETIVOS.
2.1.1 Flexibilidad en los cursos a diseńar.
Es muy importante tener flexibilidad en las estrategias de los cursos a diseńar,ya que el diseńo del sistema tiene que estar acorde a las necesidades que se tienen para el desarrollo del mismo, este además, deberá manejar un ambiente capaz de ser modificado para mejorarlo o adecuarle algunos otros requerimientos conforme se vaya necesitando, con un estilo predeterminado en la manera de estructurar el programa, para que sean más fácil los cambios.
Por otro lado, deberá existir un ambiente personalizado que permita al usuario controlar las funciones que el programa contenga, y también que tenga sesiones independientes para
poder trabajar con el de una manera ordenada y más rápida. Estas ventajas permitirán que el programa funcione de manera eficiente para los diferentes usos que se le quieran dar.
2.1.2. Minimizar la memoria del usuario.
El sistema deberá contener ayudas de tipo informativas que permitan al usuario ahorrar tiempo y espacio en la utilización de cuaderno de notas para llevar un control de las secuencias que utilice, para esto se utilizarán objetos gráficos que sean capaces de llevar en forma clara y precisa al usuario por el recorrido del programa sin tener dificultades.
El uso de gráficos para un programa es vital, ya que con la asociación de imágenes resulta más fácil el manejo de cualquier tipo de herramienta. Con esta ventaja puesta en manos del usuario, le permitirá dedicarse más a la actividad que va a desarrollar que a la utilización de memoria ( física incluso ) y con esto no perdiendo tanto tiempo en ello.
2.1.3 Adaptación a la experiencia del usuario.
La capacidad del software que se va a desarrollar debe estar adecuado a las necesidades y conocimientos que tenga el usuario, así como los requerimientos que se le puedan ir ocurriendo.
Podemos ver como referencia el caso de un software comercial que se vende con una estructura general y que por lo regular no es adaptable 100% a todos los usuarios de un sistema parecido, es decir las facilidades que proporciona nunca van a satisfacer completamente a los clientes.
Para esto es necesario dos cosas, una desarrollar un software personalizado y que se adapte a la experiencia y necesidad del cada usuario en forma independiente, así pues se le deben de presentar la mayor cantidad de opciones posibles para que pueda trabajar con ellas y el
sistema esté siempre al día, con esto se evita que en un futuro inmediato resulte obsoleto y
otra es adaptar diferentes softwares comerciales dependiendo de la necesidad de ese momento.
2.1.3.1 Software comercial.
1. P r o g r a m a s educativos por nivel.
Juanito y los frijoles mágicos. Juanito debe ir hasta la punta de su planta de frijoles o explorar el interior de una nube. Volverá a ver a su mejor amigo?. En esta versión del cuento clásico el nińo toma decisiones.
Juanito y los frijoles mágicos, ed TSnyder Productions, Mac, preescolar-3 primaria, en
inglés.
Sala de lectura de Stickybear. Programa bilingüe con efectos de sonido. Refuerza el aprendizaje de la lengua; el nińo lee y maneja dibujos y palabras; construye oraciones que se resuelven en imágenes en movimiento.
Stickyberar's Reading Room,ed Stikybear Software, Mac, Preescolar-Primaria
Línea del t i e m p o . Es un programa que permite hacer líneas de tiempo con la información que se desee e imprimirlas en formato horizontal, lo que permite construir una línea de hasta 99 páginas continuas.
Incluye varias líneas de tiempo histórico que se pueden editar intercalando información personal. Es fácil comparar dos líneas de eventos de un mismo periodo. El maestro podrá elegir la escala de tiempo que le convenga: día, semana, ańo, década etc. Se puede usar en cualquier grado y tema: en ciencias sociales, para comparar patrones históricos; en ciencias para planear y registrar experimentos científicos: en literatura, para elaborar un esquema de
