Propuesta de proceso de evaluación de la calidad del software educativo

Transcripción

1 Propuesta de proceso de evaluación de la calidad del software educativo Osiris Perez Moya 1, Rislaidy Pérez Ramos 2 Universidad de las Ciencias Informáticas, Ciudad de la Habana (C.P ) Cuba 1,2 {operez, rpramos}@uci.cu Resumen La evaluación de la calidad del software educativo desde el proceso de producción constituye el tema de esta investigación. Se fundamenta una propuesta de un proceso para evaluar la calidad del software educativo desde el inicio de su producción, identificando artefactos necesarios, artefactos resultantes y las personas que participan en cada etapa identificada. Además, se describe una propuesta de métricas que ayudan al control y buen desempeño de las etapas de Análisis & Diseño. Résument L'évaluation de la qualité du logiciel éducatif depuis le processus de production est le sujet de cette recherche. Une proposition d'un processus repose pour évaluer la qualité du logiciel éducatif depuis le commencement de sa production, en identifiant des machines nécessaires, des machines résultantes et les personnes qui participent à chaque étape identifiée. De plus une proposition se fait de métriques qui aident au contrôle et la bonne performance de étape d'analyse et de Dessin. Palabras claves Software educativo, proceso de evaluación. Des mots cloue Logiciel éducatif, processus d'évaluation. Abstract The evaluation of the quality of the educational software from the defined production process is the topic of this investigation. A proposal a process based to evaluate the quality of the educational software from the beginning of its production, necessary artifacts, resulting artifacts and people that participate in each stage identifying. In addition an offer does to itself of metric that help to the control and good performance of the stages of Analysis & Design. Key words Educational software, evaluation of educational software, evaluation process. Introducción En la actualidad los mayores esfuerzos para mejorar la calidad del software se realizan fuera de la línea de producción, lo que trae como consecuencia que no se definan los parámetros de calidad del producto que se deben seguir durante su producción. La gestión de la calidad ha sido una necesidad de las empresas de dicadas a la producción de software, tanto en el proceso de desarrollo como en el producto final. El auge de este tema en los últimos años ha estado motivado por el fracaso de algunos productos de software a los que no se le han efectuados pruebas durante su etapa de producción o a los cuales no se les han planificado pruebas, en el contrato inicial, para su ciclo de desarrollo. Otra de las causas que influye en esta problemática es que los documentos de

2 gestión y aseguramiento de la calidad de un proyecto de software no tienen seguimiento durante todo el proceso y al final del ciclo no se cumplen, lo que conlleva a la insatisfacción del cliente. Diversas investigaciones abordan la temática de la calidad del software, pero pocas lo hacen enfocadas desde el propio proceso productivo. De la revisión a la literatura especializada se aprecian dos limitaciones: a) los modelos y estándares internacionales plantean qué se debe hacer pero no cómo; b) la mayoría de estos modelos están en inglés y son muy genéricos, lo que dificulta su adaptación a proyectos específicos. El objetivo de esta investigación es desarrollar una propuesta de un instrumento para la evaluación de la calidad del software educativo. Proceso de producción de software educativo El proceso de producción de software educativo inicia cuando un cliente realiza la solicitud de desarrollo de un producto y se procede a ejecutar la contratación o definición del proyecto, etapa en la que se llega a un acuerdo entre las partes sobre las necesidades del cliente, y se acuerdan los precios. La etapa siguiente en este proceso es la gestión de requisitos y análisis, en la que se define el contenido del software y el conjunto de actividades que conducen al logro de los objetivos de aprendizaje propuestos para la construcción del conocimiento. Para ello se hace una evaluación técnica del proyecto, se gestionan las medias que se utilizarán en el producto y se confecciona el diseño que debe ser aprobado por especialistas en el tema. La etapa de gestión de medias es la que permite seleccionar los recursos mediáticos que se utilizarán en la confección del producto. Las etapas de análisis y diseño son idénticas a las que propone el Rational Unified Process (RUP) para la aproximación a la solución del problema. El diseño gráfico es la etapa que permite crear los componentes visuales y que nos proporciona la estética del producto final. A continuación se procede a la construcción del producto y al concluir se realizan las pruebas de aceptación por parte del cliente. La gestión de configuración es una etapa horizontal que tiene participación en todo el proceso de producción. (Piñero Perez & Perez, 2007) Propuesta del proceso de evaluación del software educativo Etapa 1: Evaluación de la definición del proyecto En esta etapa se revisan los resultados de la definición del proyecto. Los artefactos que se generan en la definición del proyecto son: (Piñero Perez & Perez, 2007) Solicitud del proyecto. Guión de contenidos. Definición de estrategia de trabajo. Definición del líder de proyecto (identificar las competencias que debe tener). Definición del equipo de trabajo (definir conocimientos básicos o cursos para capacitar). Control de los contactos de los integrantes del equipo. Establecimiento de las políticas de Gestión de configuración y salvas. Registro de eventos en el documento bitácora. (fechas de entregas, acuerdos e incumplimientos). Cronograma general e inicial del proyecto. Documento Visión. En cada una de las etapas de revisión que se proponen, se incluye una actividad encargada de corregir los errores encontrados. A continuación se muestran los roles que estarían involucrados en la revisión. generados en la definición del proyecto, centra su atención en el cumplimiento de las plantillas destinadas para los artefactos resultantes en la definición del proyecto, y en la redacción de estos. (Rational, 2003) Experto en pedagogía: Se encarga de revisar el guión de contenidos, así como su estructura. Asegura que el contenido es el adecuado para la audición seleccionada, y que se cumplen con los parámetros pedagógicos establecidos como formas de evaluación, objetivos del contenido, etcétera.

3 Experto en aspectos técnicos: Analiza los temas referentes a la gestión de configuración. Asegura el cumplimiento de las pautas definidas para aplicar la gestión de configuración y salvas del proyecto, así como la definición de los elementos de configuración, el comité de control de cambios y el proceso de cambios en el proyecto. Experto en aspectos de producción: Encargado de revisar el cronograma general e inicial del proyecto, la definición de estrategia de trabajo, identifica además las competencias que debe tener el líder de proyecto, así como los conocimientos básicos o cursos que se deben impartir para capacitar al equipo de desarrollo; revisa el control de los contactos que tienen intereses en el proyecto y asegura que el proyecto sea viable para la organización, o sea, revisa el contrato. Experto en software educativo: Encargado de garantizar que exista concordancia entre el contenido del producto y el mapa de navegación. Solicitud del proyecto [revisado y Guión de contenidos [revisado y Definición de estrategia de trabajo chequeada [revisado y Definición del líder de proyecto (identificar las competencias que debe tener). Definición del equipo de trabajo (definir conocimientos básicos o cursos para capacitar). Control de los contactos de los integrantes del equipo. Establecimiento de las políticas de gestión de configuración y salvas [revisado y Registro de cada evento en el documento bitácora. (fechas de entregas, acuerdos e incumplimientos) [revisado y Cronograma general del proyecto [revisado y Documento Visión [revisado y Ilustración 1 Etapa de evaluación para la Definición del Proyecto Etapa 2: Evaluación de la gestión de requisitos y análisis En esta etapa se revisan los resultados de la Gestión de requisitos y análisis. Los artefactos que se generan en la Gestión de requisitos y análisis son: (Piñero Perez & Perez, 2007) Guión técnico. Planillas de medias. Documento técnico. Documento bitácora [actualizado]. A continuación se muestran los roles que estarían involucrados en la revisión. generados en la Gestión de requisitos y análisis, centra su atención en el cumplimiento de las plantillas destinadas para los artefactos resultantes y en la redacción de estos. (Rational, 2003) Experto en pedagogía: Se encarga de revisar el guión de contenidos y su estructura. Asegura que el contenido es el adecuado para la audición seleccionada y que se cumplen

4 con los parámetros pedagógicos establecidos como formas de evaluación, etcétera. Experto en software educativo: Se encarga de revisar, en conjunto con el revisor técnico y la persona designada por la entidad que solicita el producto, el guión técnico. Cliente: Se encarga de revisar el guión técnico. Guión técnico chequeado [revisado y Planillas de medias [revisadas y aprobadas]. Documento técnico [revisado y Actualización del documento bitácora [revisado y Donde : Consistencia de la interpretación de los revisores para cada requisito. : Número de requisitos en una especificación. : Número de requisitos funcionales. : Número de requisitos no funcionales. : es el número de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de uno este el valor de menor será la ambigüedad de la especificación. Compleción de los requisitos funcionales La compleción de los requisitos funcionales puede determinarse calculando la relación: (Acosta Zamora, Betancourt, & Perez Moya, 2008) Donde : Número de funciones necesarias que se han especificado para un sistema : Número de requisitos de función únicos, Ilustración 2 Etapa de evaluación para la Gestión de Requisitos y Análisis En esta etapa se proponen las siguientes métricas que facilitarán la retroalimentación estadística: Especificidad de los requisitos Para evaluar la especificidad de los requisitos existe una métrica basada en la consistencia de la interpretación de los revisores para cada requisito, tal como: (Acosta Zamora, Betancourt, & Perez Moya, 2008) : Número de entradas (estímulos) definidos o implicados por la especificación : Número de estados especificados. Mientras más próximo este de 1 mayor va a ser el número de funciones que se han especificado para un sistema, sin embargo, no trata los requisitos no funcionales. (Acosta Zamora, Betancourt, & Perez Moya, 2008) Etapa 3: Revisión de la evaluación técnica

5 Durante esta etapa se revisa la especificación de los productos a elaborar, se revisa la recomendación de la arquitectura a utilizar para la producción del software así como la arquitectura organizativa para acometer la producción, para la cual se necesitan los siguientes artefactos generados en la etapa de evaluación técnica: (Piñero Perez & Perez, 2007) Documento de diagnóstico de producción. Documento de la arquitectura. A continuación se muestran los roles que estarían involucrados en la revisión. Experto en aspectos técnicos: Encargado de revisar la arquitectura propuesta por el equipo de desarrollo. generados en la evaluación técnica, centra su atención en la redacción de estos. (Rational, 2003) Documento de diagnóstico de producción [revisado y Documento de la arquitectura [revisado y Etapa 4: Evaluación de la gestión de medias En esta etapa se revisan las medias gestionadas para la producción del software educativo, para la cual se necesitan los siguientes artefactos generados en la etapa de Gestión de medias: (Piñero Perez & Perez, 2007) Documento de Solicitud de Media. Definición de una prioridad a la solicitud. Planilla de medias entregadas. Medias copiadas en el servidor de medias. Listado de las medias no aceptadas. Carta de Aceptación de Medias. A continuación se muestran los roles que estarían involucrados en la revisión. Jefe de líneas: Se encarga de chequear que las medias cumplan con las pautas definidas en la organización para gestionar las medias; además, revisa el listado de las medias que no fueron aceptadas y verifica que las medias se ajusten a los parámetros definidos, pautas y que exista concordancia entre los nombres de las medias con los de la plantilla de solicitud. Líder del proyecto y Guionista: Encargado de revisar las decisiones tomadas ante las medias que no fueron posible encontrar y que no se pueden producir. Experto en aspectos de producción: se encarga de chequear el avance del proyecto: el cumplimiento del cronograma definido, así como la gestión de los recursos necesarios para que el proyecto se desarrolle con calidad. generados en la Gestión de medias, además revisa la carta de aceptación de medias, centra su atención en el cumplimiento de las plantillas destinadas para los artefactos resultantes, y en la redacción de estos. (Rational, 2003) Ilustración 3 Etapa de evaluación para la Evaluación Técnica Documento de Solicitud de Media [revisado y Definición de una prioridad a la solicitud [revisado y

6 Planilla de medias entregadas [revisadas y aprobadas]. Medias copiadas en el servidor de medias. Listado de las medias no aceptadas [revisado y Carta de Aceptación de Medias [revisado y Experto en aspectos de producción: se encarga de chequear el avance del proyecto: el cumplimiento del cronograma definido, así como la gestión de los recursos necesarios para que el proyecto se desarrolle con calidad. Diseñador: Encargado de verificar que el diseño visual cumple con las pautas exigidas por el cliente. Guionista: Analiza la concordancia entre el guión de contenidos y las medias gestionadas. Asesor: Es la persona designada por el/los clientes que aprueban las medias gestionadas. Documento bitácora [revisado y Pautas de Diseño Gráfico [revisado y Propuesta inicial, Carta de Aceptación de Propuesta de diseño [revisado y Propuesta de diseño [revisado y Cronograma de realización [revisado y Ilustración 4 Etapa de evaluación para la Gestión de Medias Etapa 5: Evaluación de la gestión de diseño gráfico El objetivo de esta etapa es revisar los resultados de la etapa de Gestión de diseño gráfico. Se debe definir un tiempo de respuesta de entrega de cronograma, las pautas y la propuesta inicial de diseño, para ello se necesitan los siguientes artefactos: (Piñero Perez & Perez, 2007) Documento bitácora. Pautas de Diseño Gráfico. Propuesta inicial, Carta de Aceptación de Propuesta de diseño. Propuesta de diseño. Cronograma de realización [actualizado]. Ilustración 5 Etapa de evaluación para la Gestión de Diseño Grafico Etapa 6: Evaluación de la construcción En esta etapa se revisan los resultados de la etapa de construcción, para ello se necesitan los siguientes

7 artefactos: (Piñero Pérez, Martínez Pérez, Lorente Rodríguez, & Báez Deniz, 2007) Cronograma de trabajo. Documento bitácora [actualizado]. Entregables parciales. Plan de corrección de errores. Carta de aceptación. Asegurador de calidad del proyecto: es el responsable de velar por la calidad dentro del proyecto y de los entregables que se generen, define un grupo de documentos con el objetivo de asegurar y controlar la calidad del proyecto y del producto, además de contribuir a la organización interna. Cliente o Asesor: Se encarga de validar los entregables una vez que han sido probados y están listos para ser liberados. generados en esta etapa, centra su atención en el cumplimiento de los documentos destinados para los artefactos resultantes, y en la redacción de estos. (Rational, 2003) Experto en aspectos de producción: Se encarga de chequear el avance del proyecto y asesorar en los temas relacionados con la producción. Probador: Es el encargado de probar el entregable y asegura si este cumple con las especificaciones pactadas. Cronograma de trabajo [revisado y actualizado]. Documento bitácora [revisado y actualizado]. Entregables parciales [revisado y actualizado]. Plan de corrección de errores [revisado y actualizado]. Carta de aceptación [revisado y actualizado]. Ilustración 6 Etapa de evaluación para la Construcción Etapa 7: Evaluación de la aceptación final del producto En esta etapa se revisan todos los artefactos definidos en la aceptación del producto, estos son: (Piñero Pérez, Martínez Pérez, Lorente Rodríguez, & Báez Deniz, 2007) Carta de aceptación del producto. Aplicación (producto). Especificación del producto. generados en la aceptación final del producto, además revisa la Carta de Aceptación del producto, centra su atención en el cumplimiento y en la redacción de esta. (Rational, 2003) Experto en software educativo: Encargado de revisar la carta de aceptación del producto. Cliente: Encargado de revisar que el software cumpla con las necesidades solicitadas por él. Líder de proyecto: Trabaja en conjunto con el revisor técnico y el experto en software educativo. Carta de aceptación del producto [revisado]. Versión inicial del producto.

8 Líder de proyecto: Verifica el cumplimiento de las políticas definidas. Arquitecto: Es la persona encargada de velar, junto con el líder del proyecto, por el cumplimiento de las políticas de gestión de configuración. Informe sobre la aplicación de las políticas [revisado y actualizado]. Ilustración 7 Etapa de evaluación para la Aceptación Final del Producto Etapa 8: Evaluación de la gestión de configuración En esta etapa se verifica que se estén aplicando las políticas para el desarrollo de los proyectos, las herramientas para la gestión del control de versiones, las herramientas de trabajo colaborativo Web, los servidores en los cuales podrán encontrar dichas herramientas, la documentación básica para el uso de estas herramientas, etcétera. Se revisa también que todas las definiciones de políticas y procedimientos están en total concordancia con las definiciones establecidas por la Infraestructura Productiva para todos los proyectos productivos. (Piñero Pérez, Martínez Pérez, Lorente Rodríguez, & Báez Deniz, 2007) Para esto es necesario que se tengan los siguientes documentos ya definidos: Ilustración 8 Etapa de evaluación para la Gestión de Configuración En esta etapa se propone la siguiente métrica que facilitará la retroalimentación estadística: Probabilidad de cambios en el modelo (Acosta Zamora, Betancourt, & Perez Moya, 2008) Políticas de gestión de configuración y salvas. Configuración de las estaciones de trabajo. Políticas de organización de la información de los proyectos. Políticas de salvas. Experto en aspectos técnicos: Analiza y verifica la aplicación de las políticas de gestión de configuración definidas por la entidad. Donde X= registrabilidad de cambios en el diseño. A= número de cambios a funciones que tienen comentarios confirmados. B = total de funciones modificados. ( ), Entre más cercano a 1 más registrable, 0 indica un control de cambios deficiente o pocos cambios y alta estabilidad en el modelo. Validación de la propuesta

9 Para validar técnicamente la propuesta se utilizó el método de experto, que permite tomar decisiones para aceptar o no la propuesta de acuerdo con los criterios definidos. Luego de haber calculado el índice de aceptación se procede a determinar el éxito de la propuesta, para ellos se tuvieron en cuenta los rangos definidos por el método. Rangos predefinidos de Índice de Aceptación. IA > 0,7 Existe alta probabilidad de éxito. 0,7 > IA > 0,5 Existe probabilidad media de éxito. 0,5 > IA > 0,3 Probabilidad de éxito baja. 0,3 > IA Fracaso seguro. Por lo que la probabilidad de éxito es: alta. Concluyendo la evaluación técnica de la propuesta Se consultaron 7 expertos para que dieran su opinión y valoraran la propuesta. Primeramente los expertos emitieron su juicio para darle peso a cada criterio con la cual se elaboró la tabla de los valores de peso relativo de cada criterio. Después de tener todos los datos en la tabla se calcula el valor del Índice de Aceptación (IA) que sería: , se compara el valor con los valores que aparecen a continuación para saber la valoración de la propuesta. alta, lo que implica desde el punto de vista teórico, que si se aplica el proceso que se propone, se espera aumente la calidad del software educativo que se produce y se detecten los errores en etapas tempranas de la producción para obtener productos más eficientes, disminuyendo así el tiempo que actualmente se le dedica a las etapas de pruebas. Referencias bibliográficas Acosta Zamora, A., Betancourt, D., & Perez Moya, O. (2008). Propuesta de métricas para evaluar el flujo de trabajo Análisis y Diseño. Ciudad de la Habana: Universidad de las Ciencias Informáticas. Martínez, Y. R., & Goliath, K. D. (2007). Documentación imprescindible para los flujos de trabajo de diseño e implementación de software de gestión. Ciudad de La Habana: UCI. Piñero Perez, Y., & Perez, Y. (2007). Sistema metodológico para el desarrollo de Software Educativo. Ciudad de la Habana, Cuba: Universidad de las Ciencias Informáticas. Piñero Pérez, Y., Martínez Pérez, Y., Lorente Rodríguez, A. E., & Báez Deniz, D. C. (2007). Sistema Metodológico para el desarrollo de Software Educativo. Ciudad de la Habana: Universidad de las Ciencias Informáticas. Rational. (2003). Rational Unified Process. IA > 0,7 Existe alta probabilidad de éxito. Conclusiones El estudio teórico realizado permitió determinar las características del software educativo y los servicios que este puede cubrir en el proceso de Enseñanza-Aprendizaje. El análisis de los modelos y estándares de calidad permitió concluir que un proceso que evalúe la calidad del producto desde el proceso de producción es más eficiente en la eliminación de errores y defectos y en la complacencia de las necesidades del cliente. Mediante la profundización en el desarrollo de la propuesta, se identificaron un grupo de trabajadores que ayudan a la obtención de un producto con calidad, que fueron representados en un Diagrama junto con las actividades en las que participan y los artefactos que en estas se generan. Para la validación de esta investigación se aplicó el criterio de expertos el cual arrojó que la probabilidad de éxito es