Modulo Evaluacion Software 2010

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA MÓDULO EVALUACIÓN DE SOFTWARE Código del Curso: 301569 Francisco Nicolás Javier Solarte Solarte

[email protected] [email protected] 2010

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 2 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________

TABLA DE CONTENIDO UNIDAD 1. PROCESO DE DESARROLLO DE SOFTWARE Capitulo 1 CICLO DE VIDA PARA PRODUCTOS SOFTWARE Lección 1 Conceptos Generales sobre ciclos de vida Lección 2 Ciclos de vida tradicionales Lección 3 Ciclos de vida alternativos Lección 4 Modelos de proceso de producción de software Lección 5 Ciclos de vida Ágiles Capitulo 2 DESARROLLO DE SOFTWARE Lección 1 Procesos de Gestión del Proyecto Lección 2 Procesos de Pre-desarrrollo Lección 3 Procesos de Desarrollo Lección 4 Procesos de Post-Desarrollo Lección 5 Procesos Integrales del Proyecto Capitulo 3 CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE Lección 1 Definición de Calidad Lección 2 Sistemas de Calidad en la empresa Lección 3 Normatividad de Calidad Lección 4 Ingeniería de Software y Calidad Lección 5 Gestión de la Calidad del Software UNIDAD 2. ESTÁNDARES, METRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE Capitulo 4 Calidad del Software Lección 1 La Calidad del Software Lección 2 Calidad del Producto Software – Norma ISO/IEC 9126 Lección 3 Calidad del Producto software – Norma ISO/IEC 14598 Lección 4 Calidad del Producto Software – Norma ISO/IEC 25000 (SquaRE) Lección 5 Modelos de Mejora de Procesos de Software Capitulo 5 MÉTRICAS DE CALIDAD DEL SOFTWARE Lección 1 Conceptos Básicos de Métricas Lección 2 Métricas del Software Lección 3 Métricas de Calidad del Software Lección 4 Métricas Técnicas del Software Lección 5 Estructura para las Métricas de Calidad del software Capitulo 6 PRUEBAS DEL SOFTWARE Lección 1 La Prueba del software Lección 2 Técnicas de diseño de Casos de Prueba Lección 3 Estrategias de Aplicación de Pruebas del Software Lección 4 Pruebas de Software para Objetos Lección 5 Pruebas de Software Basado en Componentes UNIDAD 3. EVALUACIÓN DE SOFTWARE Capitulo 7 METODOLOGÍA TÉCNICA PARA LA EVALUACIÓN DE SOFTWARE

Pag. 17 18 20 23 24 28 34 36 39 41 46 49 52 54 55 57 59 60 68 70 72 75 80 82 87 88 91 94 95 98 104 106 108 114 122 127 136


Lección 1 Lección 2 Lección 3 Lección 4 Lección 5 Capitulo 8 Lección 1 Lección 2 Lección 3 Lección 4 Lección 5 Capitulo 9 Lección 1 Lección 2 Lección 3 Lección 4 Lección 5

Modelos Tradicionales para la Evaluación de la Calidad del software Norma de Evaluación ISO/IEC 9126 Proceso de Evaluación de Software Métricas Externas Basados en ISO/IEC 9126 Métricas Internas Basados en ISO/IEC 9126 METODOLOGIAS DE EVALUACIÓN DE LA ARQUITECTURA DEL SOFTWARE Evaluación de la Arquitectura del software Técnicas de Evaluación de la arquitectura del software Métodos de Evaluación de la arquitectura de software Métodos de Evaluación de Arquitectura de un Atributo Específico Método de evaluación de la Arquitectura de Software MECABIT APLICACIONES DE LA EVALUACIÓN DE SOFTWARE Metodología para la Evaluación de la Calidad en Modelos UML Implementación de la Metodología con SPEM y EPFC Evaluación de Software Educativo Multimedia Modelos de Evaluación de Software Educativo Multimedia Plantillas de Evaluación de Software Multimedia

138 142 151 156 159 162 164 166 172 179 184 192 194 200 202 205 214


LISTADO DE TABLAS Tabla 1 Tabla 2 Tabla 3 Tabla 4 Tabla 5 Tabla 6 Tabla 7 Tabla 8 Tabla 9 Tabla 10 Tabla 11 Tabla 12 Tabla 13 Tabla 14 Tabla 15 Tabla 16 Tabla 17 Tabla 18 Tabla 19 Tabla 20 Tabla 21 Tabla 22 Tabla 23 Tabla 24 Tabla 25 Tabla 26 Tabla 27 Tabla 28 Tabla 29 Tabla 30 Tabla 31 Tabla 32 Tabla 33 Tabla 34 Tabla 35 Tabla 36 Tabla 37 Tabla 38 Tabla 39 Tabla 40

Proceso de Iniciación del Proyecto Proceso de Seguimiento y Control del Proyecto Proceso de Gestión de Calidad del software Proceso de Exploración de Conceptos Proceso de asignación de Sistema Proceso de requisitos o Requerimientos Proceso de requisitos o Requerimientos Proceso de Implementación Proceso de Instalación Proceso de Operación y Soporte Proceso de Mantenimiento Proceso de Retiro Proceso de verificación y Validación Proceso de gestión de la Configuración Proceso de Desarrollo de la documentación Proceso de Formación Características de Calidad interna y externa ISO/IEC 9126 Características de Calidad en Uso ISO/IEC 9126 Origen de Errores y Defectos en un Proyecto Software Tabla de Registro de Datos de Metricas Orientadas Hacia el Tamaño Tabla para Cálculo de Puntos de Funvión Características y definición de puntos de función (a) Características y definición de puntos de función (b) Factores de calidad de McCall Métricas para el esquema de puntuación Métricas del modelo de Calidad FURPS Características y Subcaracterísticas modelo ISO/IEC 9126 Actividades y definición de Métricas Técnicas de Software Métrica Bang Medidas de Compleción de pruebas Objetivos, Principios, y Características de los Atributos de la Prueba Pruebas de Caja Blanca Pruebas de Caja Negra Lista de comprobaciones para la prueba de interfaces Pruebas de Unidad de Software Orientado a Objetos Pruebas de Integración de Software Orientado a Objetos Pruebas de Sistema de Software Orientado a Objetos Tabla de criterios a tener en cuenta al evaluar un software Características y Subcaraterísticas ISO/IEC 9126 Métricas Externas ISO/IEC 9126

Pag. 37 37 38 39 41 42 45 46 47 47 48 48 50 50 51 51 73 74 90 92 92 93 94 95 96 97 98 99 100 102 108 109 111 115 125 126 126 153 155 156


Tabla 41 Tabla 42 Tabla 43 Tabla 44 Tabla 45 Tabla 46 Tabla 47 Tabla 48 Tabla 49 Tabla 50 Tabla 51 Tabla 52 Tabla 53 Tabla 54 Tabla 55 Tabla 56 Tabla 57 Tabla 58 Tabla 59 Tabla 60 Tabla 61 Tabla 62 Tabla 63 Tabla 64 Tabla 65 Tabla 66 Tabla 67 Tabla 68 Tabla 69

Métricas Internas ISO/IEC 9126 Descripción de atributos de calidad observables vía ejecución Descripción de atributos de calidad no observables vía ejecución Perfiles, Categorias, Pesos, y Métricas Asociados a atributos de Calidad Pasos para la Evaluación Basada en Simulación Pasos para la Evaluación Basada en Modelos Matemáticos Instrumentos asociados a las distintas técnicas de evaluación de arquitecturas de software Pasos contemplados por el método de evaluación SAAM Pasos del método de evaluación ATAM Pasos del método de evaluación ARID Pasos del método de evaluación CBAM Etapas contempladas por el método de evaluación de arquitecturas propuesto por Bosch Actividades del Método de Comparación de Arquitecturas Basado en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio Comparación entre los métodos ALMA, PASA, SALUTA y SNA Grupos de Trabajo en el Método MECABIT Fases Contempladas en el Método de evaluación de Arquitecturas MECABIT Subconjunto del Árbol de Utilidad Iinicial Propuesto por el Método MECABIT Algunas Preguntas para Analizar los Elementos de Diseño Identificados Tabla de Personas, grupos y Roles Catálogo de Elementos Fases del Proceso de Evaluación Características de los Productos de Software Educativo Multimedia Partes de la calidad educacional del MEC Calidad computacional del MEC y sus elementos Elementos considerados en la viabilidad del recurso informático Elementos Considerados en la Valoración Comprensiva del MEC Algunos elementos de la valoración por experto en contenido del MEC Elementos considerados en la valoración por experto en metodología Aspectos técnicos de la evaluación de software de Bostock

159 166 166 169 170 171 172 173 174 175 177 178 179 183 185 186 189 189 195 197 199 203 206 206 206 207 207 207 209


Tabla 70 Tabla 71 Tabla 72 Tabla 73 Tabla 74 Tabla 75 Tabla 76

Aspectos pedagógicos de la evaluación de software de Bostock Esquema de evaluación del producto final Criterios y Subcriterios para Evaluación de la Calidad del Software Educativo Características de las variables según criterios de calidad Algunas características de la ficha de evaluación de software Ficha de Catalogación y Evaluación Ficha de Diseño de actividades

210 211 211 212 213 215 218


LISTADO DE GRÁFICOS Y FIGURAS Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Figura 22 Figura 23 Figura 24 Figura 25 Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31 Figura 32 Figura 33 Figura 34 Figura 35 Figura 36 Figura 37 Figura 38

Modelo en Cascada Ciclo de vida en cascada con validación Ciclo de vida en espiral Ciclo de vida XP Metodología SCRUM Ciclo de vida FDD Modelo de Gestión de calidad ISO 9001: 2000 Esquema general de un modelo de calidad del software Ciclo de vida de la calidad Calidad en el ciclo de vida del software Modelo de calidad interna y externa del producto software Modelo de calidad del producto software para la calidad en uso Norma ISO/IEC 14598 Arquitectura de la serie de normas ISO/IEC 25000 Modelo de referencia para la arquitectura Square Métricas del Proceso y Mejoras en el Proceso de Software Análisis de Problemas y causas de calidad del software Identificación de causas de errores o defectos en un software Prueba de Caja Blanca Prueba de Caja Negra Integración Incremental Descendente Depuración de errores Norma de Evaluación ISO/IEC 9126 Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126 Característica de Funcionalidad Característica de Confiabilidad Característica de Usabilidad Característica de Eficiencia Característica de Mantenibilidad Característica de Portabilidad Característica de Calidad de Uso Clasificación de las Técnicas de Evaluación Método de evaluación de arquitecturas ALMA Método de evaluación de arquitecturas PASA Método de evaluación de arquitecturas SALUTA Método de evaluación de arquitecturas SNA Roles y relaciones en el proceso de evaluación Diagrama de actividad generado por EPFC para la actividad “Obtención y Análisis de Artefactos a Evaluar” de la fase 2 (Especificación), del proceso de evaluación

Pag. 20 22 27 29 30 33 58 70 71 72 73 74 76 80 81 89 90 91 109 110 118 122 143 144 145 146 147 148 149 150 151 165 180 181 182 183 195 202


ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO El presente módulo ha sido compilado y diseñado en el año 2010 por el Ingeniero de sistemas Francisco Nicolás Javier Solarte Solarte, docente de la UNAD, quien a la fecha labora en el CEAD de Pasto, dentro de su currículo formativo cuenta con los siguientes estudios: Ingeniero de Sistemas de la Universidad INCCA de Colombia, Especialista en Multimedia educativa, y Especialista en Auditoria de Sistemas de la Universidad antonio Nariño y Magister en docencia de la Universidad de La Salle. Además cuenta con experiencia en Docencia Universitaria desde 1995 en las diferentes universidades de la ciudad de san Juan de Pasto y actualmente se desempeña como docente auxiliar de la UNAD. Esta es la primera versión actualizada del curso y en el proceso de revisión participa la Escuela ECBTI con respecto a los contenidos y la VIMMEP en la revisión del CORE quienes apoyan el proceso de revisión del estilo del módulo y dan recomendaciones disciplinares, didácticos y pedagógicos para acreditar y mejorar el curso. El módulo fue iniciado el mes de julio de 2010, y se termina en el mes de noviembre del mismo año, a petición de la directora nacional de la Cadena de Formación de Sistemas, Ingeniera Alexandra Aparicio.


UNIDAD 1 Nombre de la Unidad Introducción

Justificación

Intencionalidades Formativas

Denominación de capítulos Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de capítulos Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones

PROCESO DE DESARROLLO DE SOFTWARE Esta unidad esta dedicada principalmente a la explicación de los modelos de cilo de vida de los sistemas, al proceso de de desarrollo de software y a los conceptos de calidad y calidad en el ámbito del software, estos temas sirven de base al proceso de evaluación del proceso y el producto software obtenido para que el ingeniero de software tenga los fundamentos y una perspectiva sufiecientes para poder evaluar el software. En la evaluación del software es importante recalcar que no solo se evalúa el producto, sino también, el proceso de desarrollo de software y es de vital importancia que el ingeniro de software y la empresa conozcan los modelos y la metodología basada en estándares para el desarrollo de un producto tan especial como lo es el software. - El estudiante reconoce los ciclos de vida aplicables para el desarrollo de los difrentes productos software - El estudiante conoce uno de los estándares y cada una de las etapas de desarrollo de software - El estudiante conoce los conceptos de calidad, calidad de software y algunos de los estándares más reconocidos aplicados al producto software. CAPITULO 1: CICLOS DE VIDA DEL SOFTWARE Lección 1. Conceptos Generales sobre ciclos de vida Lección 2. Ciclos de vida tradicionales Lección 3. Ciclos de vida alternativos Lección 4. Modelos de proceso de producción de software Lección 5. Ciclos de vida Ágiles CAPITULO 2: DESARROLLO DE SOFTWARE Lección 1. Procesos de Gestión del Proyecto Lección 2. Procesos de Pre-Desarrrollo Lección 3. Procesos de Desarrollo Lección 4. Procesos de Post-Desarrollo


Denominación de Lecciones Denominación de capítulos Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones Denominación de Lecciones

Lección 5. Procesos Integrales del Proyecto CAPITULO 3: CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE Lección 1.Definición de Calidad Lección 2. Sistemas de Calidad en la empresa Lección 3: Normatividad de Calidad Lección 4: Ingeniería de Software y Calidad Lección 5. Gestión de la Calidad del Software


INTRODUCCIÓN Hace algunos años, el desarrollo de aplicaciones informáticas se llevaba a cabo de forma individual, generando líneas de código y probando lo realizado. Este proceso se realizaba sin necesidad de documentación alguna y como había baja movilidad las empresas pensaban que cuando hubiera necesidad de la persona para realizar modificaciones él estaría allí para solucionar los problemas. A pesar de que esa forma de escribir código era un adelanto, nunca se llego a pensar que posteriormente se convertiría en un problema y que en el caso de software que contenía errores en la base de datos este debía desecharse completamente y comenzar nuevamente. Esta forma de desarrollar software es muy común en las empresas y sucede normalmente porque no se sigue un enfoque de desarrollo conocido como ciclo de vida, y es el escaso tiempo dedicado a la planificación, pues normalmente, se codifica y se prueba dando buenos resultados cuando el software es pequeño. Pero para otro tipo de proyectos resulta peligroso ya que no se conoce el progreso del proyecto, ni tampoco su calidad simplemente se codifica y se prueba hasta terminar el proyecto. Por este motivo es probable que las aplicaciones desarrolladas utilizando estos métodos sean poco flexibles y ante posibles modificaciones se puedan incrementar los costos de los proyectos y en algunos casos se vuelvan irrealizables por la no existencia de documentación para efectuarlas. Otro problema es que las aplicaciones resulten incompletas y no reflejen en su totalidad los requerimientos de los clientes, que no esten completamente funcionales o que tengan baja fiabilidad. Además pueden provocar el descontento en los clientes pues, pueden producir retrasos en la entrega o que aparezcan errores una vez entregados. Por lo tanto es necesario que todo el esfuerzo de desarrollo de software se enfoque en el uso de un ciclo de vida que contemple todas sus etapas desde la concepción hasta finalizar con el retiro del mismo cuando ya no se utiliza. Todas las organizaciones y estudiosos de la ingeniería de software se han ocupado del estudio de estos problemas para proponer nuevos enfoques y actividades tendientes a mejorar los procesos de construcción y revisión de software. Así se han desarrollado modelos de referencia para la adquisición, desarrollo, explotación, soporte y mantenimiento de software. El instituto de ingeniería de software ha desarrollado el Modelo de Madurez de la Capacidad ( Capability Maturity Model, CMM), el cual proporciona a las organizaciones de software una orientación sobre como hacerse con el control del proceso de desarrollo y mantenimiento de software, y como evolucionar hacia una cultura de la ingeniería de software y de gestión por excelencia.


Los organismos IEEE e ISO/IEC han publicado normas respectivamente, IEEE-1074, e ISO/IEC 12207-1. Actualmente, ISO/IEC ha desarrollado dentro del marco de la evaluación de software un informe técnico alineado con el anterior, ISO/IEC TR 15504-2, y específicamente la La serie de normas ISO/IEC 14598 para evaluación de software, la norma ISO/IEC 9126 que posteriormente se unificarían en la serie de normas ISO/IEC 25000 denominadas SQuaRE, que abarcará a la serie ISO/IEC 14598 e ISO/IEC 9126. Todos estos modelos establecen los diferentes procesos implicados a la hora de desarrollar sistemas informáticos, desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que estos se retiran de explotación. Sin embargo ninguno de estos modelos impone la utilización de un ciclo de vida específico o método de desarrollo concreto, sino que cada empresa debería seleccionar los procesos que considere necesario realizar, estableciendo sus propios ciclos de vida software. La Ingeniería de software y específicamente el curso de Evaluación de software es uno de los componentes fundamentales de la estructura curricular del programa de Ingeniería de sistemas, pues incorpora en su contenido todo lo referente a los ciclos de vida de los sistemas, el proceso de construcción de software, las métricas de software, las pruebas de software, los estándares de calidad, la evaluación de la arquitectura de los sistemas, y la evaluación general de productos software de diferente tipo, con el propósito de verificar y evaluar su correcta realización. Este curso, se enmarca dentro del campo de formación profesional y tiene como objetivo la preparación de los estudiantes y futuros profesionales en su labor como desarrolladores de software, auditores o consultores de productos informáticos dentro de una organización. El módulo esta compuesto de tres unidades generales, y cada una de ellas esta integrada por capítulos y lecciones, dentro de las cuales se distingue: Unidad 1: Proceso de Desarrollo de software dentro de esta unidad se incluye los ciclos de vida del software, los procesos de software, las metodologías de desarrollo de software, la gestión de proyectos de software y aspectos relacionados con estos temas. Unidad 2: Calidad del Software, dentro de esta unidad se incluye las métricas de calidad, estandares de calidad de software, pruebas del software, gestión de la calidad de software. Unidad 3: Evaluación de software, dentro de esta unidad se incluye la especificación de las métricas ISO/IEC 9126, los métodos de evaluación y las aplicaciones que aunque diversas, tratan de recoger las nuevas investigaciones sobre estos temas tan importantes para la vida profesional del ingeniero.


JUSTIFICACIÓN Uno de los intereses en la formación de los estudiantes del programa de ingeniería de sistemas y en ámbito disciplinar, es su formación integral a través del desarrollo de competencias, que le permitan interactuar en diferentes contextos, haciendo de ellos profesionales competitivos, generadores de cambio y progreso. El curso de evaluación de software no es la excepción, ya que centra al estudiante en aspectos relacionados con los sistemas de información empresarial donde con sus habilidades y conocimientos puede contribuir al desempeño y cumplimiento exitoso de los procedimientos de la organización. El estudiante como profesional estará preparado para planificar, diseñar, desarrollar y evaluar software, identificando situaciones de riesgo y sugerir controles que garantice la calidad de los productos de software. El curso, esta dirigido a estudiantes que se encuentren en la etapa final del proceso de formación y específicamente que conozcan el campo de la Ingeniería de Software, ya que los métodos de evaluación de software están ligados al proceso de construcción o adquisición del software. El curso permite el desarrollo de competencias cognitivas, comunicativas, contextuales y valorativas, fundamentales para la formación profesional y la interacción en otros contextos. El logro de estas competencias exige una planificación responsable en su proceso de aprendizaje autónomo si se quieren obtener resultados positivos en el desarrollo del curso, ya que el trabajo es en parte individual y otra la interacción en grupos colaborativos pequeños. La evaluación de software permite llevar a la práctica los conocimientos adquiridos en los cursos del componente de ingeniería de software que son la base del profesional en sistemas y permite integrar las otras áreas del conocimiento necesarias para realizar un proceso de evaluación bajo normas estándares. Además una de las tareas más difíciles en la elección de software, una vez conocidos los requerimientos del sistema, es el de determinar si un cierto producto de software cumple con los requerimientos. Después de la selección inicial, es necesario conocer los estándares de calidad y hacer una revisión exhaustiva del cumplimiento de las normas, y cuales son las ventajas frente a los otros productos.


INTENCIONALIDADES FORMATIVAS PROPÓSITO Fundamentalmente, el curso pretende desarrollar las capacidades, habilidades y destrezas de los estudiantes durante el proceso de evaluación de software, donde deberá conocer y aplicar los conocimientos acerca de ciclos de vida, estándares de calidad, las métricas de calidad y las para hacer la revisión de los diferentes tipos de productos software. Con esto se contribuirá al mejoramiento de los procesos de calidad del software en las organizaciones, a través de la aplicación de procedimientos y estándares de calidad tanto en el proceso de producción de software como en la búsqueda de soluciones apropiadas para dar solución a problemas del uso y la integración de sistemas de información computacionales. OBJETIVOS - Identificar dentro de los procesos de desarrollo de software los diferentes enfoques o ciclos de vida de acuerdo a cada proyecto, conocer cada una de las fases o etapas de cada ciclo de vida - Reconocer los conceptos básicos y las características de la evaluación de software - Conocer los tipos de pruebas, métricas y estándares de calidad para la evaluación de software y aplicar procedimientos para la evaluación de software tendientes a evaluar el proceso de desarrollo y los productos comerciales. - Identificar y analizar los estándares actuales utilizados para evaluar la calidad del software y cuales son los significados de los factores y requisitos que debe cumplir un software de calidad. - Aplicar los conceptos de la evaluación de software y aplicar procedimientos para la evaluación de software tendientes a evaluar el proceso de desarrollo y los productos comerciales. METAS El estudiante estará capacitado para: - Identificar los ciclos de vida para desarrollo de software - Identificar las fases o etapas de cada uno de los ciclos de vida. - Identificar los aspectos a tener en cuenta en la calidad de software


- Identificar y conocer los estándares y métricas de calidad de software - Conocer y comprender los procedimientos para la evaluación de software. COMPETENCIAS - El estudiante identifica, analiza, y comprende los diferentes enfoques o ciclos de vida utilizados para el desarrollo de software de acuerdo al tipo de proyecto, cada una de las fases y cómo asegurar la calidad durante cada una de las fases. - El estudiante esta en capacidad de identificar los estándares de calidad, las métricas, los factores y requisitos que se deben cumplir los productos software. - El estudiantes esta en la capacidad de realizar los procedimientos de evaluación de software de manera objetiva y respetando los principios de la ética profesional. - El estudiante esta en capacidad de comprender la realidad de un entorno empresarial y elabora propuestas para el desarrollo de software y evaluar posibles soluciones mejorando el desempeño de las mismas contribuyendo al desarrollo de la región.


UNIDAD 1

PROCESO DE DESARROLLO DE SOFTWARE


CAPITULO 1

CICLOS DE VIDA DEL SOFTWARE


1.1

LECCIÓN 1: CONCEPTOS GENERALES SOBRE CICLOS DE VIDA

El ciclo de vida de software es la descripción de las distintas formas de desarrollo de un proyecto informático. Es la orientación que se sigue para que a partir de los requerimientos del cliente se obtengan sistemas que puedan ser utilizados por los usuarios. Otra de las definiciones más técnicas, dice que un ciclo de vida es un conjunto de fases o etapas, procesos y actividades requeridas para el desarrollo y la explotación de un producto software. El ciclo de vida seleccionado en un proyecto, influye en el éxito del mismo, asegurando que cada actividad aporte al cumplimiento del objetivo que se ha propuesto. Dependiendo del ciclo de vida seleccionado, se puede aumentar la velocidad de desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar los costos y los riesgos, y mejorar las relaciones con los clientes. El ciclo de vida en cascada, fue uno de los primeros modelos de ciclo de vida que formalizó un conjunto de procesos de desarrollo de software. Este modelo describe un orden secuencial en la ejecución de los procesos asociados. El modelo espiral se postuló como una alternativa al modelo de cascada. La ventaja de este modelo radica en el perfeccionamiento de las soluciones encontradas con cada ciclo de desarrollo, en términos de dar respuesta a los requerimientos inicialmente analizados. El modelo de cascada y el modelo espiral suponen que los requerimientos del cliente no cambian radicalmente en el transcurso del desarrollo del sistema. Los prototipos apoyan diferentes modelos de ciclo de vida. Un prototipo tiene el objetivo de mostrar al cliente o a la gerencia del proyecto el resultado que se obtendrá de la implementación de cada uno de los requerimientos del cliente una vez terminado el desarrollo. La solución a algunos de los problemas presentados por las metodologías tradicionales se logra con una gran evolución del modelo espiral. El proceso unificado propone la elaboración de varios ciclos de desarrollo, donde cada uno finaliza con la entrega al cliente de un producto terminado. Este se enmarca entre los conocidos modelos iterativo-incremental. Algunos grupos de desarrollo han experimentado soluciones que basan su fundamento en la adaptabilidad de los procesos de desarrollo, esta comunidad de desarrolladores e investigadores han nombrado su trabajo bajo lo que se conoce como metodologías ágiles. Las metodologías ágiles, promueve la formalización de procesos adaptables. La compilación de los principios y valores que resaltan las metodologías ágiles fue formalizada en el manifiesto para el desarrollo de software ágil. La metodología XP, una de las metodologias ágiles más difundidas que define pocas reglas y pocas prácticas. XP promueve la adaptabilidad de los procesos de desarrollo basándose en los principios y prácticas que presenta.


Quienes trabajan usando XP deben seguir procesos disciplinados, además de combinar la disciplina con la adaptabilidad necesaria del proceso. Las metodologías de Cristal se basan en el principio de que tipos diferentes de proyectos requieren tipos diferentes de metodologías. La metodología escogida debe depender de dos factores: el número de personas en el proyecto, y las consecuencias de los errores. Conforme al principio de las metodologías ágiles, Scrum recalca la imposibilidad de encontrar procesos definidos y repetibles cuando no existen problemas, personas, ni ambientes definidos y repetibles. Al utilizar las metodologías tradicionales el problema es que casi nunca se logra planear bien el esfuerzo requerido para seguir la metodología. Pero si se logra definir métricas que apoyen la estimación de las actividades de desarrollo. El no poder predecir siempre los resultados de cada proceso significa que actualmente se debe hacer frente a la necesidad de adaptación de los procesos de desarrollo que son llevados por parte de los equipos que construyen software. Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta interesante ya que estas pueden involucrar prácticas tanto de metodologías ágiles como de metodologías tradicionales. De esta manera se puede plantear una metodología por cada proyecto, el problema se centrará en definir cada una de las prácticas, y en el momento preciso definir parámetros para saber cual usar. Al elegir el modelo de ciclo de vida se debe tener en cuenta algunos factores como el contexto, fundamentos básicos, los obstáculos y ventajas. Esto incluye realizar un estudio de las prácticas que se van a poner en ejecución dentro de un proyecto. Los modelos deben ser estructurados teniendo en cuenta las características propias del proyecto y pueden ser híbridos con una mezcla de modelos tradicionales y ágiles. Un modelo de ciclo de vida exitoso en un contexto, no necesariamente lo es en otro contexto. Por ejemplo, ante el surgimiento de los Parques Tecnológicos que incluyen empresas de desarrollo de software, se debe tomar en cuenta las características propias del contexto de un grupo de jóvenes emprendedores sin altos recursos para realizar inversión, con necesidad de poner en el mercado en relativo poco tiempo un software altamente funcional de excelente calidad. Ante este panorama se plantea la necesidad de redefinir el modelo de desarrollo con el fin de mejorar los resultados en términos de un conjunto de atributos como pueden ser la calidad del software y la precisión de los planes realizados. También surgen las preguntas de cómo evaluar el proceso de desarrollo, la identificación del conjunto de características que rodean los desarrollos, e impactan de manera significativa los resultados del equipo y cómo identificar el conjunto de prácticas adecuadas para incluir en un nuevo modelo de ciclo de vida de desarrollo. A continuación se hace un repaso de los diferentes ciclos de vida existentes, teniendo en claro que no existe un modelo de ciclo de vida general para cualquier tipo de proyecto. Cada proyecto debe seleccionar para cada caso


específico el ciclo de vida más adecuado, teniendo en cuenta la cultura empresarial, el deseo de asumir riesgos, el área de aplicación, la volatilidad de los requisitos y su entendimiento. El ciclo de vida elegido servirá para relacionar las tareas que forman parte del proceso software de cada proyecto. 1.2

LECCIÓN 2: CICLOS DE VIDA TRADICIONALES

1.2.1. Ciclo de vida clásico o en cascada Este modelo fue presentado por primera vez por Royce en 1970. Se representa frecuentemente como un simple modelo con forma de cascada de las etapas del software, como lo muestra la siguiente figura:

Figura 1. Modelo en Cascada En este modelo la evolución del producto software procede a través de una secuencia ordenada de transiciones de una fase a la siguiente según el orden lineal. Este modelo semeja una máquina de estados finitos para la descripción de la evolución del producto software. El modelo en cascada ha sido útil para ayudar a estructurar y gestionar grandes proyectos de desarrollo de software dentro de las organizaciones. Este modelo permite iteraciones durante el desarrollo, dentro de un mismo estado o de un estado a otro anterior. La mayor iteración se produce cuando una vez terminado el desarrollo y cuando se ha visto el software producido, se decide comenzar de nuevo y redefinir los requerimientos del usuario.


Sin embargo, durante el desarrollo se puede tomar decisiones que den lugar a las diferentes alternativas. Por ejemplo, dependiendo del análisis de requisitos se puede implementar el sistema desde cero, o adoptar uno ya existente, o comprar un paquete que proporcione las funcionalidades requeridas. El modelo en cascada ha sido transformado numerosas veces y es el más utilizado, aunque incorporando infinidad de variaciones que eliminan el carácter simplista del mismo. Aún hoy en día se asume que para que un proyecto tenga éxito, todas las fases del modelo deben cumplirse y cualquier desarrollo en diferente orden de estados dará un producto de inferior calidad. Entre las limitaciones que se argumentan a este modelo se pueden señalar las siguientes: El modelo asume que los requisitos se pueden conseguir antes de iniciar la etapa de diseño, eso para los sistemas nuevos es poco realista, el mantener los requisitos requiere seleccionar el hardware, pero la terminación de un proyecto puede llevar años, y dada la velocidad de obsolescencia de la tecnología, es probable que el software final utilice hardware obsoleto, en caso de sistemas no desarrollados para clientes específicos, y los desarrollados por terceros, que frecuentemente salen al mercado, los requisitos son determinados por los desarrolladores, por eso es mejor desarrollar primero una parte del sistema y posteriormente optimizarlo. Pero el punto más álgido de este modelo es que envía al cliente el producto solamente después de que se han consumido el 90% de los recursos, esto significa que la mayor parte de la retroalimentación del cliente sobre sus necesidades se obtiene al final. Este ciclo de vida tiene tres factores muy positivos: El primero, es que las etapas están organizadas de un modo lógico, una etapa no puede llevarse a cabo hasta que se haya tomado las decisiones de continuar a la siguiente, es así como, el diseño espera a los requisitos, la codificación espera al diseño, el segundo es que cada etapa incluye un proceso de revisión y se necesita la aceptación del producto antes de que la salida de la etapa pueda utilizarse, y el tercero es que el ciclo es iterativo, en cuanto a que reconoce que los problemas encontrados en etapas inferiores afectan a las decisiones de las etapas superiores. Existe una visión alternativa de este modelo que enfatiza la validación de los productos y el proceso de composición existente en la construcción de sistemas software. Este proceso consiste en lo siguiente: Los requerimientos generales se dividen en requerimientos de hardware y software, los requerimientos de software llevan al análisis preliminar de múltiples funciones, cada una de las cuales se expande en el diseño detallado que a su vez evoluciona en un número mayor de programas unitarios, al ensamblar el producto se procede al contrario, dentro de un proceso de síntesis o composición, donde primero se aceptan los programas unitarios probados, estos se agrupan en módulos que a su vez deben ser aceptados una vez probados, luego, los módulos se agrupan para certificar el grupo formado por todos ellos incluyen todas las


funcionalidades deseadas y finalmente, el software es integrado con el hardware hasta formar un único sistema informático que satisface los requerimientos globales. El producto obtenido en cada etapa no solo determina que debe hacerse en la fase siguiente del proceso, sino que también establece los criterios para determinar si el producto compuesto y ensamblado satisface los objetivos de la etapa. El ciclo de vida esta estructurado de tal modo que en cada etapa se define qué debe hacerse en el próximo paso de descomposición, pero también se documentan los criterios para determinar si el producto compuesto que resulta satisface las intencionalidades que se tenían hacia él. 1.2.2 Ciclo de vida de refinamiento sucesivo o mejora iterativa Las etapas que forman este ciclo de vida son las mismas que el modelo en cascada y su realización sigue el mismo orden. Sin embargo, este modelo recomienda desarrollar los sistemas software a través de un refinamiento y mejora continuos desde las especificaciones de alto nivel del sistema hasta los componentes de código fuente. Este modelo asume que el producto generado en cada etapa no se produce de manera lineal, del principio al final de la etapa, sino al contrario, predica la generación de productos de manera iterativa mediante un proceso de refinamiento. Debido a la marcha atrás permitida en el modelo en cascada, se abre un camino desde una etapa hacia otra anterior, el refinamiento iterativo puede producirse también a nivel global de todas las etapas.

Figura 2: ciclo de vida en cascada con validación


1.2.3 Ciclo de vida con emisión gradual Este modelo propone desarrollar sistemas produciendo, en primer lugar, las funciones esenciales de operación y posteriormente proporcionar a los usuarios mejoras y versiones más capaces del sistema a intervalos regulares. Este modelo combina el ciclo de vida clásico de software con mejoras iterativas a nivel del desarrollo del sistema global. También proporciona una manera de distribuir periódicamente actualizaciones del mantenimiento de software comercial. 1.2.4 Estándares militares y prácticas industriales Las empresas industriales adoptan con frecuencia alguna variación del modelo clásico como base de la práctica del desarrollo de software. Muchos proveedores de la administración americana organizan sus actividades de acuerdo con los modelos del ciclo de vida del estándar militar, tal como el de la norma MIL-STD-2167 de 1987. Tales estándares subrayan no solo alguna variación de las actividades del ciclo de vida clásico, sino que también contienen lo documentos que deben entregarse a los clientes que necesitan sistemas software o mecanismos complejos como sistemas software embebidos. Estos estándares deben ser compatibles con la garantía de calidad del software, la gestión de configuraciones y la verificación y validación independiente de servicios en un proyecto de desarrollo con más de un contratista. Estos modelos ponen especial énfasis en la definición de productos entregables, revisones, hitos y técnicas requeridas en cada caso. 1.3

LECCIÓN 3: CICLOS DE VIDA ALTERNATIVOS

Existen por lo menos tres conjuntos alternativos a los modelos de evolución de los productos software tradicionales. Estos modelos centran su atención bien sobre productos diferentes a los clásicos o sobre procesos especiales de producción o sobre entornos de producción. Dado que estos modelos no están aún muy extendidos, se considera fundamental su presentación aquí por las potencialidades que presentan. 1.3.1 Ensamblaje de componentes reutilizables El enfoque básico de la reutilización es configurar y especializar componentes de software ya existentes. Sin embargo, la granularidad de los componentes, es decir, el tamaño, complejidad y capacidad funcional, varía grandemente a lo largo de los distintos enfoques. La mayoría de ciclos de vida basados en ensamblaje de componentes intentan utilizar componentes similares a estructuras de datos con los algoritmos incorporados para su manipulación


denominados componentes de grano fino. Sin embargo, el uso de componentes de grano fino no constituye un enfoque distinto a la evolución del producto software tradicional. Otros enfoques intentan utilizar componentes ensamblando funcionalmente sistemas o subsistemas completos; por ejemplo, sistemas de gestión de interfaces de usuario, en este caso se trata de componentes de grano grueso. El uso o la reutilización de estos componentes aparecen como un enfoque alternativo al desarrollo de sistemas software. Hay probablemente, muchas formas de emplear componentes de software reutilizables al desarrollar software. Sin embargo, hasta ahora parece ser que la mejor forma de implementación rápida es usarlo durante el diseño arquitectónico. Los componentes reutilizables también pueden usarse con propósitos de prototipado. 1.3.2 Generación de aplicaciones Es un enfoque de desarrollo de software similar a la reutilización de componentes de software de grano grueso, pero en este caso, parametrizados. Tales componentes están especializados en un dominio de aplicación, vía un lenguaje de especificación formalizado usado como entrada para el generador de la aplicación. Ejemplos comunes de este enfoque son las interfaces estandarizados de aplicaciones de sistemas de gestión de bases de datos que incluyen generadores de informes, gráficos, editores específicos de la aplicación e interfaz de usuario. El uso de generadores da lugar a un modelo de evolución del producto software mediante el cual la actividad de diseño del software o es casi eliminada, o reducida a un problema de diseño de bases de datos. Similarmente los usuarios de los generadores de aplicaciones esperan habitualmente proporcionar especificaciones de entrada y servicios de mantenimiento de la aplicación. Estas capacidades son posibles dado que los generadores pueden producir solo sistemas software específico para un pequeño número de dominios de aplicación similares y en especial aquellos que dependen de un sistema de gestión de bases de datos. 1.4 LECCIÓN SOFTWARE

4:

MODELOS

DE

PROCESO

DE

PRODUCCIÓN

DE

1.4.1 Modelos operativos El enfoque operativo para el desarrollo de software supone la existencia de un lenguaje de especificaión formal y un entorno de proceso. Las especificaciones están codificadas en el lenguaje y constituyen un proptotipo funcional del sistema especificado. Cuando tales especificaciones son desarrolladas gradualmente, el prototipo resultante puede refinarse y desarrollarse en sistemas funcionalmente más completos que siempre están operativos durante su desarrollo. Variaciones dentro de este enfoque representan esfuerzos donde el prototipo es el fin


buscado, o bien situaciones donde los prototipos especificados se conservan operativos pero refinados dentro de un sistema completo. 1.4.1.1Automatización de la programación y del proceso software: La automatización del proceso y la programación están relacionados con el desarrollo de las especificaciones formales de cómo una familia de sistemas software debe desarrollarse, estas especificaciones deberían proporcionar una estimación para la organización y descripción de las distintas cadenas de producción software, como están interrelacionadas, cuándo iteran, y qué herramientas software deberían utilizarse. El desarrollo de software utilizando técnicas de cuarta generación se caracteriza por facilitar la especificación de algunas de las funcionalidades de alto nivel. La herramienta genera a continuación, el código o parte de él a partir de la especificación. Esta especificación se hace en un lenguaje lo más próximo al lenguaje natural. El concepto de desarrollo con uso de herramientas de cuarta generación se utiliza varias herramientas dentro de las cuales se encuentran los lenguajes no procedimentales para las bases de datos, generación de informes y pantallas de captura, para la generación de código y las capacidades gráficas de alto nivel combinados con hojas de cálculo. Una vez hecha la especificación de los requerimientos, la generación de código es casi automática, con lo que el tiempo de desarrollo se reduce drásticamente. Con el código generado se empieza a revisar las funcionalidades de la aplicación y se va añadiendo prestaciones de forma interactiva hasta completar el producto. Esta técnica permite la construcción de programas al usuario y permite la revisión y actualización personal, con lo que es muy difícil la equivocación en cuanto al cumplimiento de requerimientos. En la actualidad su uso se reduce a sistemas de gestión con un grado de complejidad no muy elevado. 1.4.1.2 Automatización del Software Basado en Conocimientos: Este modelo intenta llevar el proceso de automatización hasta sus límites al suponer que pueden usarse las especificaciones de proceso para desarrollar directamente sistemas software y configurar entornos de desarrollo para soportar las tareas en curso. Los sistemas expertos son un caso particular en el ciclo de vida del software, ya que su particularidad les hace disponer de sus propios ciclos de vida. En este ciclo de vida las fases se pueden activar en paralelo, y reactivar en cualquier momento, sin necesidad de ejecutar ciclos completos. Se pueden utilizar técnicas de prototipado, pero la expansión al sistema final a partir del prototipo es mucho más directa, ya que pueden bastar con incrementar la base de reglas de inferencia o la base de conocimientos.


Por otra parte, la definición interna de lo que debe hacer el sistema experto no queda clara ni siquiera al final del desarrollo, porque lo que se trata de modelizar es el razonamiento de los expertos humanos. Por lo tanto no existen nunca unos requisitos claros para poder validar el resultado. Las fases de desarrollo de un sistema experto son las siguientes: Identificación del problema, estudio de factibilidad, identificación de subproblemas, identificación de conceptos y relaciones, diseño conceptual, diseño detallado, código, prueba de razonamiento, prueba del conocimiento, validación, conversión, mantenimiento y mejoras. Muchas de estas etapas se producen en paralelo e influyen unas en otras, con lo que el diagrama de bloques que lo representa, en vez de ser secuencial es un grupo de cajas que interactúan, pero que están una al lado de la otra en el tiempo. El enfoque común a estos tres modelos mencionados es buscar la automatización del modelo de transformación continuo. A su vez, esto implica un entorno automatizable capaz de registrar el desarrollo formalizado de las especificaciones operativas, transformando y refinando sucesivamente dichas especificaciones en un sistema implementado, asimilando los requisitos de manteniemiento al insertar las especificaciones nuevas en el desarrollo, y luego llevando el desarrollo revisado a la implementación. 1.4.2 Modelos no operativos Estos modelos incorporan métodos de proceso dirigidos especificaciones y por los prototipos.

por las

1.4.2.1 Modelo en espiral: El modelo en espiral representa un enfoque dirigido al análisis de riesgos y estructuración de procesos de software. El enfoque incorpora métodos de proceso dirigidos por las especificaciones y por los prototipos. Esto se lleva a cabo representando ciclos de desarrollo iterativos en forma de espiral, denotando los ciclos internos del ciclo de vida análisis y prototipado temprano, y los externos el modelo clásico. La dimensión radial indica los costos de desarrollo acumulativos y la angular el progreso hecho en cada desarrollo en espiral. El análisis de riesgos, que busca identificar situaciones que pueden causar el fracaso o sobrepasar el presupuesto o el plazo, aparecen durante cada ciclo de la espiral. En cada ciclo, el análisis de riesgos representa la misma cantidad de desplazamiento angular, mientras que el volumen desplazado barrido denota el crecimiento de los niveles de esfuerzo requeridos para el análisis de riesgo como lo muestra la siguiente figura:


Figura 3: ciclo de vida en espiral Una de las ventajas de este modelo es que permite utilizar los modelos de proceso de construcción de software tradicionales, mientras su orientación al riesgo evita muchas dificultades. De hecho, en situaciones apropiadas, el modelo en espiral proporciona una combinación de los modelos existentes para un proyecto determinado. Otras ventajas de este modelo son las siguientes: Presta atención a las opciones que permiten la reutilización de software existente, está centrado en la eliminación de errores y alternativas poco atractivas, no establece una diferenciación entre desarrollo de software y mantenimiento del sistema, y proporciona un marco estable para desarrollos integrados hardware - software. 1.4.2.2 Modelos de Transformación contínua: Estos modelos proponen un proceso por el cual los sistemas software se desarrollan a través de una serie de transformaciones continuas de problemas establecidos en especificaciones abstractas dentro de implementaciones concretas. Se propone un esquema por el cual no hay ciclo de vida tradicional ni etapas separadas, en su lugar se llevan a cabo una serie de transformaciones y refinamientos graduales de especificaciones abstractas para llegar a programas más concretos. En este sentido, las frases que definen el problema y los sistemas


software pueden emerger de algunas coevolucionando.

maneras juntas

y así continuar

Los modelos de transformación continuada también se acomodan al interés de los formalistas del software que buscan de manera precisa, las propiedades formales de las especificaciones de los sistemas software. De acuerdo a esto, los formalismos especificados pueden ser transformados matemáticamente en propiedades que una implementación fuente debería satisfacer. 1.4.2.3 Modelos de Procesos Misceláneos: Se han propuesto muchas variaciones de los modelos de proceso y ciclos de vida no operativos. Esto incluye ciclos de vida completamente interconectados que se acomodan a las transiciones entre dos fases sujetas a la satisfacción de sus precondiciones y sus postcondiciones así como a las variaciones de los componentes sobre el ciclo de vida tradicional y modelos de transformación continúa. 1.4.2.4 Modelos de entorno de producción software: El proceso de producción o de producto de la evolución del software, los modelos del entorno de producción dirigen su atención a la organización y gestión de estrategias para desarrollar y producir sistemas software. Como tales, el foco es menos tecnológico y más estratégico. Pero debería quedar claro que tales estrategias afectan tanto a los productos software que consiguen desarrollarse, como a la forma que será organizado el proceso de producción del software. Entre estos modelos se pueden mencionar los siguientes: Modelos de proceso de Gestión de Proyectos software, Modelos Organizadores de Desarrollo de Software, Modelos de ciclo de Vida de Recursos de Clientes, modelos de Transición y Transferencia de tecnología software y otros modelos para la organización, fabricación y producción de sistemas software. 1.5

LECCIÓN 5: CICLOS DE VIDA ÁGILES

El término “Ágil” aplicado al desarrollo de software nace en el año 2001, tras una reunión en donde participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los grupos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Después de dicha reunión nace “The Agile Alliance”, una organización, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos, algunos de estos modelos propuestos y más difundidos pertenecientes a esta filosofía son:


1.5.1 Programación Extrema (XP) Kent Beck, el padre de XP, describe la filosofía de XP como una metodología ágil que potencia las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y disposición para enfrentar los cambios. XP se define como adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre.

Figura 4: Ciclo de vida XP 1.5.2 SCRUM Este un proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales. Es un proceso incremental iterativo para desarrollar cualquier producto o gestionar cualquier trabajo. Aunque este proceso estaba previsto que fuera para la gestión de proyectos de desarrollo de software, se puede usar también para la ejecución de equipos de mantenimiento de software o como un enfoque de gestión de programas. SCRUM define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden


resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días, el resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. SCRUM es un esqueleto de proceso que incluye un conjunto de prácticas y roles predefinidos, los roles principales son el “ScrumMaster” que mantiene los procesos y trabaja junto con el jefe de proyecto, el “Product Owner” que representa a las personas implicadas en el negocio y el “Team” que incluye a los desarrolladores. Durante cada iteración (sprint- periodos de tiempo), típicamente un periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea un incremento de software operativo.

Figura 5: Metodología SCRUM El conjunto de características que entra en una iteración viene del “backlog” del producto, que es un conjunto priorizado de requisitos de trabajo de alto nivel que se han de hacer. Los ítems que entran en una iteración se determinan durante la reunión de planificación de la iteración. Durante esta reunión, el Product Owner informa al equipo de los ítems en el backlog del producto que quiere que se completen. El equipo determina entonces a cuanto de eso puede comprometerse a completar durante la siguiente iteración.


1.5.3 Agile Unified Process (AUP) El proceso unificado ágil (AUP) es una versión simplificada de RUP desarrollada por Scout Ambler. Describe un enfoque simple, fácil de entender, del desarrollo de software de aplicación de negocios usando técnicas y conceptos ágiles. AUP aplica técnicas ágiles incluyendo desarrollo orientado a pruebas, modelado ágil, gestión de cambios ágil y refactorización de bases de datos para mejorar la productividad. La naturaleza en serie de AUP se presenta en cuatro fases: Inicio, el objetivo es identificar el alcance inicial del proyecto, una arquitectura potencial para el sistema y obtener fondos y aceptación por parte de las personas involucradas en el negocio; la elaboración, el objetivo es probar la arquitectura del sistema; la construcción, el objetivo es construir software operativo de forma incremental que cumpla con las necesidades de prioridad más altas de las personas involucradas en el negocio; transición, el objetivo es validar y desplegar el sistema en el entorno de producción. 1.5.4 Dynamic System Development Method (DSDM) Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases. El método de desarrollo de sistemas dinámico (DSDM) es una metodología de desarrollo de software originalmente basada en la metodología RAD. DSDM es un enfoque iterativo e incremental que enfatiza la participación continua del usuario cuyo objetivo es entregar sistemas software en tiempo y presupuesto ajustándose a los cambios de requisitos durante el proceso de desarrollo. DSDM es uno de los métodos ágiles para el desarrollo de software, y forma parte de la Alianza Ágil. Como extensión del desarrollo rápido de aplicaciones, DSDM se centra en proyectos de sistemas de información que se caracterizan por planificaciones y presupuestos estrictos. DSDM trata las características más comunes de los proyectos de sistemas de información, incluyendo presupuestos sobrepasados, plazos de entrega desaparecidos y falta de participación del usuario y compromiso de la alta gerencia. 1.5.5 Crystal Methodologies Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la


reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). Crystal Clear es un miembro de la familia de metodologías Crystal como describe Alistair Cockburn y se considera un ejemplo de metodología ágil. Crystal Clear está pensado para aplicarse a equipos pequeños de 6 a 8 desarrolladores ubicados en el mismo sitio trabajando en sistemas que no son críticos. La familia de metodologías Crystal se centra en la eficiencia y habitabilidad como componentes de la seguridad del proyecto. Crystal Clear se centra en las personas, no en los procesos o artefactos. Crystal Clear cuenta con las siguientes propiedades: Entrega frecuente de código usable a los usuarios, mejora reflexiva, comunicación osmótica preferiblemente estando en la misma ubicación, seguridad personal, fácil acceso a los usuarios expertos y pruebas automatizadas, gestión de la configuración e integración frecuente. 1.5.6 Adaptive Software Development (ASD) Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. 1.5.7 Feature-Driven Development (FDD) Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software.


Figura 6: Ciclo de vida FDD 1.5.8 Lean Development (LD) Definida por Bob Charette a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.


CAPITULO 2

DESARROLLO DE SOFTWARE


INTRODUCCIÓN A continuación se describe en detalle las fases o subprocesos que conforman el proceso base de construcción de software correspondiente al estándar IEEE 1074-1989. Cada subproceso detalla el nivel de propósito, actividades involucradas y documentación principal propuesta por el estándar. El estándar determina el conjunto de actividades esenciales, no ordenadas en el tiempo, que deben ser incorporadas dentro de un modelo de ciclo de vida de un producto software. Este modelo es seleccionado y establecido por el usuario para el proyecto a desarrollar, ya que la norma no define un ciclo de vida particular. El estándar ha sido escrito por organizaciones responsables de la gestión y desarrollo de software y está dirigido a los gestores de proyectos, a los desarrolladores de software, a los responsables de la garantía de calidad, a quienes ejecutan tareas de apoyo, y al personal de mantenimiento. El proceso base para la construcción de software consiste en analizar las necesidades de la organización en un dominio, bajo un marco de gestión, seguimiento, control y gestión de la calidad. El proceso de software está compuesto de cuatro procesos principales cada uno de los cuales agrupa una serie de actividades que se encargan de la realización de sus requisitos asociados. Estos son los siguientes: -

Proceso de selección de un modelo de ciclo de vida del producto que identifica y selecciona un ciclo de vida para el software que se va a a construir.

-

Proceso de gestión del proyecto, donde se crean la estructura del proyecto y aseguran el nivel apropiado de la gestión del mismo durante todo el ciclo de vida del software.

-

Procesos orientados al desarrollo del software, que producen, instalan, operan y mantienen el software y lo retiran de su uso. Se clasifican en procesos de pre-desarrollo, desarrollo y post-desarrollo.

-

Procesos integrales del proyecto, que son necesarios para completar con éxito lasa actividades del proyecto software. Aseguran la terminación y calidad de las funciones del mismo. Son simultáneos a los procesos orientados al desarrollo de software e incluyen e incluyen actividades de no desarrollo.

En el modelo de proceso software se puede detallar los cuatro procesos principales: el proceso de selección del ciclo de vida, el proceso de gestión dl proyecto, los procesos orientados al desarrollo del software y los procesos integrales del proyecto.


2.1

LECCIÓN 1: PROCESOS DE GESTIÓN DEL PROYECTO

La gestión del proyecto presupone establecer condiciones para el desarrollo del mismo, la gestión involucra actividades dentro de las cuales tenemos: La planificación de proyectos, define la predicción de la duración de las actividades y tareas a nivel individual, los recursos requeridos, la concurrencia y la superposición de tareas para que sean desarrollados en paralelo y el camino crítico a través de la red de actividades. La estimación, que se define como la predicción de personal, el esfuerzo y costos que se requerirá para terminar todas las actividades y productos conocidos asociados con el proyecto. La determinación del tamaño del producto a desarrollar, que es una de las primeras tareas en la gestión del proyecto, ya que sin conocerlo adecuadamente, no es posible planificar y estimar el esfuerzo necesario. El tamaño se define como la cantidad de código fuente, especificaciones, casos de prueba, documentación del usuario y otros productos tangibles que son la salida del proyecto. El seguimiento de proyectos, que es la recolección de datos y su acumulación sobre recursos consumidos, costos generados, e hitos asociados con el proyecto. La medición de un proyecto, que se define como el registro de todos los productos generados en el mismo, de todos los recursos requeridos, planificación y superposición de todas las actividades y de todos los factores que impactan en el proyecto como los conocimientos, métodos, herramientas, lenguajes, limitaciones, problemas y el entorno físico. 2.1.1 Proceso de iniciación del proyecto Abarca aquellas actividades de creación de la estructura del proyecto, aquí se define el ciclo de vida del software para este proyecto y se establecen los planes para su gestión. Se determinan los costos y recursos necesarios a fin de ejecutar las distintas tareas que demanda el proyecto. Se identifican y seleccionan estándares, metodologías y herramientas para la gestión, herramientas para la ejecución del mismo y por último se prepara y establece un plan para su implementación adecuada y oportuna. El plan de gestión de proyectos software que conducirá al desarrollo se produce como culminación de este proceso. A continuación se presenta una tabla de actividades a realizar, la documentación que se obtine y cuales técnicas se aplican.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 37 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Actividades a realizar •

• • •

Establecer el mapa de actividades para el ciclo de vida del software seleccionado Asignar los recursos del proyecto Definir el entorno del proyecto Planificar la gestión del proyecto

Documentación de salida • Plan de gestión del proyecto • Plan de retiro

Técnicas a utilizar •

Análisis de camino crítico (CPM) Análisis PERT Diagrama de GANTT Técnicas Estadísticas Técnicas de simulación (método de MONTECARLO) Puntos de función Modelos empíricos de estimación (COCOMO, PUTMAN) Técnicas de Descomposición Funcional

• • • • • • •

Tabla 1: Proceso de iniciación del proyecto 2.1.2 Proceso de seguimiento y control del proyecto Es un proceso iterativo de seguimiento, registro y gestión de costos, problemas y rendimiento de un proyecto durante su ciclo de vida. En este proceso se realiza un análisis de riesgos de tipo económico, técnico, operativo, de soporte, y del programa o calendario, que permite identificar los problemas potenciales, determinar su probabilidad de ocurrencia y su impacto, y establecer los pasos para su gestión. De aquí surge el plan de contingencias donde se identifica los riesgos, se evalúan y se gestionan. En la siguiente tabla se identifican las actividades a realizar, la documentación que se obtine y cuales técnicas se aplican. Actividades a realizar • • • • •

Analizar los riesgos Realizar la planificación de contingencias Gestionar el proyecto Archivar los registros Implementar el sistema de informes de problemas

Documentación de salida • Análisis de riesgos • Plan de contingencias • Registro histórico de proyectos

Técnicas a utilizar •

•

• •

Tabla 2: Proceso de seguimiento y control del proyecto

Análisis de riesgo técnico (Modelización y Simulación Estática y Dinámica, prototipado, revisiones, auditorias) Análisis de riego económico (Análisis de finanzas, Retorno de la inversión) Análisis de riesgo operativo y de soporte Análisis de ri riesgo de programa (Análisis del camino crítico CPM, Técnicas de nivelación de recursos)


2.1.3 Proceso de gestión de la calidad del software El objetivo es la planificación y administración de las acciones necesarias para proveer una confianza adecuada en la calidad de los productos software que satisfagan los requerimientos técnicos establecidos. En el proceso de gestión de la calidad del software se abarcan actividades en todo el ciclo de vida y se documenta en un plan de garantía de la calidad del software. Para abordar este proceso de protección del software globalmente se consideran los siguientes aspectos: Las métricas para el control del proyecto, la verificación y validación, incluyendo pruebas, procesos de revisión, y la gestión de la configuración del producto. Las métricas del software se definen como la aplicación continua de técnicas basadas en las medidas de los procesos de desarrollo de software y de sus productos para producir una información de gestión significativa y oportuna, a la vez que se mejoran los procesos y sus productos. La verificación y la validación del software involucran actividades imprescindibles para el control de la calidad del software. Se entiende por verificación al conjunto de actividades para la comprobación de que un producto software esta técnicamente bien construido, es decir, que el producto funciona. En general, comprobar si los productos construidos en el ciclo de vida satisfacen los requisitos establecidos en las fases anteriores, decidiendo si el producto hasta el momento es consistente y completo. De modo complementario la validación trata la comprobación de que el producto software construido es el que se deseaba construir, es decir que funciona como el usuario quiere y hace las funciones que fueron concertadas con él. En la siguiente tabla se identifican las actividades a realizar, la documentación que se obtine y cuales técnicas se aplican. Actividades a realizar • • • •

Planificar la garantía de la calidad del software Desarrollar métricas de calidad Gestionar la calidad del software Identificar necesidades de mejora de la calidad

Documentación de salida • Plan de garantía de calidad del software • Recomendacio nes de mejora de calidad del software

Tabla 3: Proceso de gestión de calidad del software

Técnicas a aplicar • •

Técnicas de planificación y Estimación Métricas de calidad del software


2.2

LECCIÓN 2: PROCESOS DE PRE-DESARROLLO

Son los procesos que se deben realizar antes de que comience el desarrollo propiamente dicho del software. El desarrollo se inicia con la identificación de una necesidad de automatización. Esta necesidad para ser satisfecha necesita de una nueva aplicación, o cambio de todo o parte de la aplicación existente. El proceso de pre-desarrollo abarca desde el reconocimiento del problema hasta la determinación de los requisitos funcionales a nivel de sistema, pasando por el estudio de viabilidad de la solución software. 2.2.1 Proceso de exploración de conceptos Este proceso incluye la identificación de una necesidad, la formulación de soluciones potenciales, el estudio de viabilidad, y refinamiento a nivel de sistema. Una vez establecidos sus límites, se genera el informe de la necesidad del sistema a desarrollar. Este informe inicia el proceso de asignación del sistema y/o el proceso de requisitos, y alimentan los procesos de gestión del proyecto. El informe de la necesidad es un documento que constituye la base de todo el trabajo de ingeniería posterior. En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican. Actividades a realizar • • • • •

Identificar ideas o necesidades Formular soluciones potenciales Conducir estudios de viabilidad Planificar la transición del sistema Refinar y finalizar la idea o necesidad

Documentación de salida • • • • • • •

Modelo de la situación actual Modelo del dominio del problema Informe preliminar de necesidades Soluciones alternativas posibles Soluciones recomendadas Plan de transición Informe del impacto de la transición

Técnicas a aplicar • • • • • •

Técnicas de adquisición de conocimientos Análisis económico Análisis técnico Análisis alternativos Técnicas de modelización (Diagramas DFD) Prototipado

Tabla 4: Proceso de exploración de conceptos 2.2.2 Procesos de asignación del sistema Este proceso se realiza cuando el sistema requiere tanto del desarrollo de hardware como el de software, o cuando no se está seguro que solo se necesita desarrollo de software. En el informe de necesidad se identifica las entradas, el procesamiento que se aplica a la entrada, las salidas requeridas y las funciones del sistema total, que permiten desarrollar la arquitectura del sistema e identificar las funciones del hardware, del software y de las interfaces. Este proceso culmina


con la especificación de requisitos del software, la especificación de requisitos del hardware y la especificación de la interfaz del sistema. Se comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando un subconjunto de estos requisitos del software, para su análisis y refinamiento en el proceso de requisitos. Este planteamiento del sistema es esencial cuando el software debe interrelacionarse con otros elementos, tales como hardware, personas y bases de datos. El análisis de sistema requiere una comunicación intensa entre el cliente y el analista. El cliente debe comprender los objetivos del sistema y ser capaz de exponerlos claramente. El analista debe ser qué preguntas hacer, que consejos dar y qué investigación realizar, pues si la comunicación se rompe, el éxito del proyecto entero estará en peligro. En el análisis del sistema se definen los objetivos del mismo, la información que se va a obtener, la información que se va a suministrar, las funciones, el comportamiento y el rendimiento requerido. Una vez que la función, el rendimiento y las interfaces están delimitados, se procede a realizar la tarea denominada asignación. Durante la asignación, las funciones son asignadas a uno o más elementos genéricos del sistema, es decir, software, hardware, personal, bases de datos, documentación, procedimientos. Esencialmente, lo que se hace es asignar a cada elemento del sistema un ámbito de funcionamiento y de rendimiento. Asignadas las funciones, se puede crear un modelo que represente las interrelaciones, entre los distintos elementos del sistema y establezca una base para los posteriores pasos de análisis de requisitos y de diseño. Se representa el sistema definido mediante modelos de la arquitectura del sistema (salida, entrada, proceso y control, interfaz de usuario, mantenimiento y autocomprobación). En primer lugar se realiza un diagrama de contexto de la arquitectura, que establece los límites de información entre los que se esta implementando el sistema y el entorno en el que va a funcionar. Luego, se refina el diagrama de contexto de la arquitectura considerando con más detalle la función del sistema. Se identifican los subsistemas principales que permiten el funcionamiento del sistema considerado en el contexto definido por el diagrama. Se definen los subsistemas principales en un diagrama de flujo de arquitectura. El diagrama de flujo de arquitectura muestra los subsistemas principales y las líneas importantes de flujo de información (control y datos). El diagrama inicial de flujo de la arquitectura se constituye en el nodo raíz de la jerarquía de diagramas de flujo. Se puede ampliar cada subsistema del diagarama de flujo inicial en otro diagrama de arquitectura dedicado exclusivamente a él. Este proceso de descomposición de arriba hacia abajo permite disponer de una jerarquía de diagramas de flujo del sistema, donde cada uno de ellos se puede utilizar como punto de partida para los posteriores pasos de ingeniería del subsistema que describe. En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican.


Actividades a realizar • • •

Analizar funciones sistema Desarrollar arquitectura sistema Descomponer requisitos sistema

Documentación de salida las del

• •

la del los del

• • •

Especificación de requisitos del sistema Especificación de requisitos funcionales del hardware Especificación de la interfaz del sistema Descripción funcional del sistema Arquitectura del sistema

Técnicas a aplicar • •

Técnicas de adquisición de conocimientos Técnicas de modelización (Diagramas DFD)

Tabla 5: Proceso de asignación del sistema 2.3

LECCIÓN 3: PROCESOS DE DESARROLLO

Son los procesos que se deben realizar para la construcción del producto software. Estos definirán qué información obtener y como estructurar los datos, qué algoritmos usar para procesar los datos y cómo implementarlos, y qué interfaces desarrollar para operar con el software y cómo hacerlo. A partir del informe de la necesidad, con el soporte de las actividades de los procesos integrales y bajo el plan de gestión del proyecto, los procesos de desarrollo producen el software (código y documentación). 2.3.1 Procesos de requisitos Incluye actividades iterativas dirigidas al desarrollo de la especificación de requisitos del software. Para la determinación completa y consistente de todos los requerimientos del software el análisis se enfatiza sobre la salida resultante, la descomposición de los datos, el procesamiento de los datos, las bases de datos y las interfaces de usuario, del software y del hardware. La especificación de requerimientos del software es el establecimiento conciso y preciso de un conjunto de requisitos que deben ser satisfechos por un producto software, indicando el procedimiento mediante el cual se puede determinar si se satisfacen los requerimientos dados. Describe los requisitos funcionales, de rendimiento y de interfaz de software y definen los entornos de operación y soporte. Este documento es la salida con la cual culmina este proceso. Existen tres tipos de requerimientos: Requerimiento Funcional, que especifica la función que un sistema componente de un sistema debe ser capaz de realizar.

o


Un requerimiento de rendimiento especifica una característica numérica tanto estática (número de terminales del sistema, número de usuarios simultáneos que soportará el sistema, número de archivos o registros del mismo, etc.) como dinámica (tiempo de procesamiento en el sistema) que debe tener un sistema o componente de un sistema. Los requisitos de interfaz, que determinan características que el software debe soportar para cada interfaz humano del producto software (interfaz de usuario), las características lógicas de cada interfaz entre el producto software y los componentes de hardware del sistema (interfaz del hardware), el uso de otros productos software (un sistema de gestión de base de datos, un sistema operativo, un paquete estadístico) e interfaces con otros sistemas de aplicación (interfaz de software). Existen además otros atributos del software (seguridad, consistencia, facilidad de traza, etc.) que pueden dar lugar a requisitos específicos del mismo, por ejemplo la restricción a determinados datos. En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican. Actividades a realizar • Definir y desarrollar los requerimientos del software • Definir los requerimientos de interfaz • Priorizar e integrar los requerimientos del software

Documentación de salida • Especificación de requisitos del software • Especificación de requisitos de interfaz con el usuario • Especificación de requisitos de interfaz con otro software • Especificación de requisitos de interfaz con hardware • Especificación de requisitos de interfaz con el sistema físico

Tabla 6: Proceso de requisitos o requerimientos

Técnicas a utilizar • Técnicas orientadas a los procesos: Análisis estructurado (Diagramas de flujo de datos DFD, Diccionario de datos DD, Especificación de procesos primitivos EPP), SADT, Diagramas de transición de estados, Diagramas de descomposición, WRS, RBS, OBS, Actigramas. • Técnicas orientadas a datos: Diagramas entidad-relación, datagramas • Técnicas orientadas a objetos: Diagramas de clases y objetos, jerarquía de clases y objetos • Técnicas formales de especificación: Técnicas relacionales (relaciones recurrentes, expresiones regulares), Técnicas Orientadas al estado (Tablas de decisión, tablas de eventos, tablas de transición, redes de PETRI), Técnicas de prototipos.


2.3.2 Proceso de diseño Su objetivo es realizar una representación coherente y organizada del sistema software que satisfaga la especificación de requisitos del software. La calidad de dicha representación se puede evaluar. El proceso de diseño traduce el “qué hacer” de las especificaciones de los requerimientos en el “cómo hacerlo” de las especificaciones de diseño. Inicialmente, la representación describe una visión sistémica y holística del software. Posteriores refinamientos de diseño conducen a una representación que se acerca al código fuente. El diseño de software puede verse desde dos perspectivas: la técnica y la de gestión del proyecto. Desde el punto de vista técnico el diseño comprende cuatro actividades: diseño de los datos, diseño arquitectónico, diseño procedimental y diseño de interfaces. Desde el punto de vista de gestión del proyecto, el diseño va del diseño arquitectónico (diseño preliminar o de alto nivel) al diseño detallado (diseño de bajo nivel). Desde el punto de vista de la gestión, el nivel de diseño arquitectónico se focaliza en las funciones y estructuras de las componentes que conforman el sistema software. El nivel de diseño detallado se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas que se usan para cada componente modular del software. El proceso de diseño de software comienza con la actividad de realizar el diseño arquitectónico. Esta actividad genera la descripción del diseño arquitectónico del software en donde se describe cada una de las componentes software, se especifican los datos, las relaciones y restricciones, y se definen todas las interfaces externas (usuario, software y hardware) y los internos (entre componentes). La última actividad del proceso de diseño es realizar el diseño detallado, donde se genera la descripción del diseño del software, que especifica la estructura de los datos, los algoritmos y la información de control de cada componente software, y los detalles de las interfaces (usuario, hardware y software). El diseño detallado se deriva del diseño preliminar; en consecuencia, sus correspondientes actividades se realizan en consecuencia mientras que el resto de las actividades de este proceso (analizar el flujo de información, diseñar la base de datos, diseñar las interfaces, desarrollar los algoritmos) se ejecutan en paralelo. Una actividad relevante es el diseño de la base de datos que comprende el diseño conceptual, lógico y físico, de la base de datos. Los requisitos se modelizan dentro de un esquema externo que describe las entidades de datos, atributos, relaciones y restricciones. Los distintos esquemas externos se integran en un esquema conceptual único. El esquema conceptual se aplica entonces en un esquema lógico dependiente de la implementación. Finalmente, se definen las estructuras físicas de datos y los caminos de acceso.


Como ya se mencionó, desde el punto de vista técnico y en el contexto de los diseños preliminar y detallado, se llevan a cabo varias actividades de diseño diferentes: diseño de datos, diseño arquitectónico, diseño procedimental y diseño de la interfaz. El diseño de datos, que transforma el modelo del campo de información, creado durante el análisis, en las estructuras de datos que se van a requerir para implementar el software. El diseño arquitectónico, que define las relaciones entre los principales elementos estructurales del programa. El objetivo principal de este diseño es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. El diseño arquitectónico mezcla la estructura de programas y la estructura de datos y define las interfaces que facilitan el flujo de los datos a lo largo del programa. El diseño procedimental, que transforma los elementos estructurales en una descripción procedimental del software; se realiza después de que se ha establecido la estructura del programa y de los datos. El diseño de la interfaz, que establece principalmente la disposición y los mecanismos para la interacción hombre - máquina. El diseño es el proceso en el que se asienta la calidad del desarrollo de software ya que produce las representaciones del software de las que puede evaluarse su calidad. El diseño es la única forma mediante la cual se puede traducir con precisión los requerimientos del cliente en un producto o sistema acabado. El diseño de software sirve como base de todas las posteriores etapas del desarrollo y del proceso de mantenimiento. Para evaluar la calidad de una representación del diseño se deben tener en cuenta las siguientes consideraciones: 1.

Jerarquización, es decir, que debe exhibir una organización jerárquica que haga un uso inteligente del control entre los componentes del software.

2.

Modularidad, esto es, que el software debe estar dividido de forma lógica en elementos que realicen funciones y subfunciones específicas.

3.

separabilidad, o contener representaciones distintas y separadas de los datos y de los procedimientos.

4.

Independencia funcional, de modo que lleve a conseguir módulos que exhiban características funcionales independientes.


5.

Conectividad, que lleva a producir interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior.

6.

Reproductibilidad, es decir, que debe obtenerse mediante un método que sea reproducible y que esté conducido por la información obtenida durante el análisis de los requerimientos del software.

En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican. Actividades a realizar • Realizar el diseño arquitectónico • Analizar el flujo de información • Diseñar la base de datos • Diseñar las interfaces • Seleccionar o desarrollar algoritmos • Realizar el diseño detallado

Documentación de salida • Descripción de diseño del software • Descripción de la arquitectura del software • Descripción del flujo de información • Descripción de la base de datos • Descripción de las interfaces • Descripción de los algoritmos

Técnicas a aplicar • Técnicas orientadas a los procesos: Diseño estructurado (Análisis de transformación, Análisis de transacción), Diseño del diálogo de las interfaces, Diseño lógico o diseño del perfil, HIPO. • Técnicas orientadas a datos: Modelo lógico de datos, modelo físico de datos, Warnier, Jackson. • Técnicas orientadas a objetos: Modelos de clases/objetos, diagrama de módulos. • Técnicas de diseño a bajo nivel: Programación estructurada (diagramas arborescentes, diagramas de chapin), Programación orientada a objetos (diagrama de procesos), warnier, Jackson, técnicas de prototipado, técnicas de refinamiento.

Tabla 7: Proceso de diseño 2.2.3 Proceso de Implementación Este proceso transforma la representación del diseño detallado de un producto software a una realización en un lenguaje de programación apropiado. El proceso de implementación produce el código fuente, el código de la base de datos y la documentación, que constituyen la manifestación física del diseño de acuerdo a los estándares y metodologías del proyecto. Además, en este proceso se debe integrar el código y la base de datos. En el caso de que el sistema conste de componentes hardware y software, se debe planificar y realizar la integración del sistema.


La salida de este proceso esta sujeta a las pruebas de verificación y validación adecuadas. El código y la base de datos junto con la documentación producida durante los procesos previos son la primera representación completa del producto software. En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican. Actividades a realizar • Crear los datos de prueba • Crear el código fuente • Generar el código objeto • Crear la documentación de operación • Planificar la integración • Realizar la integración

Documentación de salida • Datos para las pruebas • Documentación del sistema • Documentación de usuario • Plan de integración • Sistema software integrado

Técnicas a utilizar • Warnier • Jackson • Lenguajes de programación.

Tabla 8: Proceso de Implementación 2.4

LECCIÓN 4: PROCESOS DE POST-DESARROLLO

Son los procesos que se deben realizar para instalar, operar, soportar, mantener y retirar un producto software. Una vez terminada la prueba del software, éste está casi preparado para ser entregado a los usuarios finales. Sin embargo, antes de la entrega se llevan a cabo una serie de actividades de garantía de calidad para asegurar que se hayan generado y catalogado los registros, y documentos internos adecuados, que se ha desarrollado una documentación de alta calidad para el usuario, y que se han establecido los mecanismos apropiados de control de configuraciones. Tan pronto como se entregue el software a los usuarios finales, el trabajo del ingeniero del software cambia, en este momento el enfoque pasa de la construcción al mantenimiento; corrección de errores, adaptación al entorno y mejora de la funcionalidad. En todos los casos, la modificación del software no solo afecta al código, sino también a la configuración entera, es decir, a todos los documentos, datos y programas desarrollados en la fase de planificación y desarrollo. 2.4.1 Proceso de instalación Implica el transporte y la instalación de un sistema software desde el entorno de desarrollo al entorno de destino. Incluye la carga de la base de datos, las modificaciones necesarias del software, las comprobaciones en el entorno de destino y la aceptación del cliente. Si durante la instalación surge un problema se identifica e informa acerca de él.


El proceso de instalación verifica que se implemente la configuración adecuada del software y termina con la aceptación formal del mismo por parte del cliente conforme a lo especificado en el plan de gestión del proceso software y la realización con éxito de la prueba de aceptación del usuario. En la siguiente tabla se identifican las actividades a realizar y la documentación. Actividades a realizar • Planificar la instalación • Distribuir el software • Instalar el software • Cargar la base de datos Aceptar el software en el entorno de operación

Documentación de salida • Plan de instalación de software • Informe de instalación

Tabla 9: Proceso de instalación 2.4.2 Proceso de operación y soporte Involucra la operación del sistema por parte del usuario y el soporte continuo al usuario que incluye asistencia técnica, consultas con el usuario y registro de las peticiones de soporte en el histórico de peticiones de soporte. Así, este proceso puede desencadenar la actividad del proceso de mantenimiento que provee información de realimentación al ciclo de vida del software. En la siguiente tabla se identifican las actividades a realizar, y la documentación. Actividades a realizar • Operar el sistema • Proveer de asistencia técnica y consultas • Mantener el histórico de las peticiones de soporte

Documentación de salida • Histórico de las peticiones de soporte

Tabla 10: Proceso de operación y soporte 2.4.3 Proceso de mantenimiento Se interesa por los errores, defectos, fallas, mejoras y cambios del software. Un requisito de mantenimiento del software inicia los cambios del ciclo de vida del software; éste se reasigna y se ejecuta. El mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas por la evolución del entorno del software y a las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a reforzar o ampliar el sistema. El proceso de mantenimiento vuelve a aplicar los pasos del ciclo de vida, pero en el contexto del software ya existente. Durante el mantenimiento se encuentran tres tipos de cambios:


Corrección: Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. Adaptación: con el paso del tiempo es probable que cambie el entorno original para el que se desarrolló el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo. Mejora: conforme utilice el software, el cliente o usuario puede descubrir funciones adicionales que podría interesar que estuvieran incorporadas al software. El mantenimiento perfectivo amplía el software más allá de sus requisitos funcionales originales. La salida de este proceso son las recomendaciones del mantenimiento que entran al ciclo de vida del software en el proceso de exploración de conceptos para mejorar la calidad del sistema software. En la siguiente tabla se identifican las actividades a realizar, y la documentación. Actividades a realizar • Operar el sistema • Proveer de asistencia técnica y consultas • Mantener el histórico de las peticiones de soporte

Documentación de salida • Histórico de las peticiones de soporte

Tabla 11: Proceso de Mantenimiento 2.4.4 Proceso de Retiro Se puede decir que es la jubilación de un sistema existente de su soporte activo o de su uso mediante el cese de su operación o soporte, o su reemplazo por un nuevo sistema o por su actualización. Si el sistema en uso se reemplaza por un nuevo sistema se requiere un tiempo de operación en paralelo. En este periodo se utiliza el sistema en retiro para los resultados oficiales, mientras se prepara el nuevo sistema para su operación formal. Es un período de formación para el usuario sobre el nuevo sistema y de validación del mismo. En la siguiente tabla se identifican las actividades a realizar, y la documentación. Actividades a realizar • Notificar al usuario • Conducir las operaciones en paralelo • Retirar el sistema

Tabla 12: Proceso de retiro

Documentación de salida • Plan de retiro


2.5

LECCIÓN 5: PROCESOS INTEGRALES DEL PROYECTO

Son procesos simultáneos y complementarios a los procesos orientados hacia el desarrollo. Incluyen actividades imprescindibles para que el sistema construido sea fiable (procesos de verificación y validación, gestión de la configuración) y sea utilizado al máximo de sus capacidades (procesos de formación, documentación). Los procesos integrales comprenden dos tipos de actividades: Aquellas que se realizan discretamente y se aplican dentro de un ciclo de vida del software y las que se realizan para completar otra actividad, estas solo se invocan y no se aplican dentro del ciclo de vida para cada instancia. 2.5.1 Proceso de verificación y validación Abarca la planificación y la realización de todas las tareas de verificación, incluyendo pruebas de verificación, revisiones y auditorias, y de todas las tareas de validación, incluyendo pruebas de validación, que se ejecutan durante el ciclo de vida del software para asegurar que se satisfacen todos los requisitos del software. Una actividad útil para la verificación y la validación del software es la prueba del software. Constituye el proceso de ejecución del software con determinados datos de entrada, para observar los resultados que produce y compararlos con los resultados teóricos que debería producir, para esos datos de entrada, con el objeto de detectar posibles fallas. Las pruebas del software solo podrán realizarse cuando en el proceso de desarrollo ya exista código ejecutable. La depuración es un proceso frecuentemente asociado a las pruebas que consiste en tratar de deducir donde están los defectos en el software que provocan que éste no funcione adecuadamente. Estudia los resultados de las pruebas y otras actividades de control para intentar buscar qué está mal en el software. En la siguiente tabla se identifican las actividades a realizar, la documentación y cuales técnicas se aplican. Actividades a realizar • Planificar la verificación y validación • Ejecutar las tareas de verificación y validación • Recoger y analizar los datos de las métricas • Planificar las pruebas • Desarrollar las especificaciones de las pruebas • Ejecutar las pruebas

Documentación de salida • Plan de verificación y validación • Informes de evaluación • Plan de pruebas • Especificación de las pruebas • Informe resumen de las pruebas • Software aprobado

Técnicas a utilizar • Técnicas de prueba de caja blanca (cobertura de sentencias, cobertura de decisión y de ramificación, cobertura de condición, cobertura de decisión/condición, cobertura de condición múltiple) • Técnicas de prueba de caja negra (Partición de equivalencias, análisis de valores límites, gráficos de causa/efecto, conjetura de error)

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 50 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ • •

Revisiones formales Auditorias

Tabla 13: Proceso de verificación y validación 2.5.2 Proceso de gestión de la configuración Este proceso involucra un conjunto de actividades desarrolladas para gestionar los cambios durante todo el ciclo de vida del software. Identifica la estructura de un sistema (qué rutinas, módulos, datos, archivos lo componen) en un momento dado a lo que se le denomina configuración del sistema. Su objetivo es el control de los cambios en el sistema, mantener su coherencia y su rastreabilidad o trazabilidad, y poder realizar auditorias de control sobre la evolución de las configuraciones. La gestión de la configuración realiza las siguientes funciones: Identificación de la configuración de un sistema o descripción documentada de las características reales del sistema en un determinado momento; control de la configuración, establece la configuración inicial o básica y controla los cambios en los elementos de la misma; informes del estado de la configuración; auditorias de la configuración, revisiones independientes de la configuración para comprobar que los elementos de la configuración cumplen los requisitos de configuración establecidos. En la siguiente tabla se identifican las actividades a realizar, y la documentación. Actividades a realizar • Planificar la gestión de la configuración • Realizar la identificación de la configuración • Realizar el control de configuración • Realizar la información del estado de la configuración

Documentación de salida • Plan de gestión de configuración del software • Orden de cambio de ingeniería • Cambio de estado • Informe de estado

Tabla 14: Proceso de gestión de la configuración 2.5.3 Proceso de desarrollo de documentación El proceso de desarrollo de documentación para el desarrollo y uso del software es el conjunto de actividades que planifican, diseñan, implementan, editan, producen, distribuyen y mantienen los documentos necesarios para los desarrolladores y los usuarios. En la siguiente tabla se identifican las actividades a realizar, y la documentación.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 51 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Actividades a realizar • Planificar la documentación • Implementar la documentación • Producir y distribuir la documentación

Documentación de salida • Plan de documentación

Tabla 15: Proceso de desarrollo de documentación 2.5.4 Proceso de formación Incluye la planificación, desarrollo, validación e implementación de los programas de formación de desarrolladores, personal de soporte técnico y clientes o usuarios y la elaboración de los materiales de formación adecuados. Para conseguir una utilización efectiva del sistema software, se debe proporcionar a los usuarios del sistema instrucciones, guía y ayuda para el entendimiento de las capacidades del sistema y de sus limitaciones. Por ello es imprescindible la formación de los usuarios en el nuevo sistema. El desarrollo de productos software de calidad depende en gran medida de los conocimientos de las personas y del personal especializado involucrados en el proyecto. Por ello, es esencial la formación de los desarrolladores y personal de soporte técnico. En la siguiente tabla se identifican las actividades a realizar, y la documentación. Actividades a realizar • Planificar el programa de formación • Desarrollar los materiales de formación • Validar el programa de formación • Implementar el programa de formación

Documentación de salida • Plan de formación

Tabla 16: Proceso de desarrollo de formación


CAPITULO 3

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE


INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el hecho por ejemplo de pasar de una programación de código línea a línea, a un método de programación gráfico orientado a objetos donde el desarrollo es mas rápido y atractivo para el cliente. Más sin embargo con estas ventajas que se tiene con las nuevas herramientas de desarrollo de software se olvida la calidad del producto que es entregado, no es solamente una calidad gráfica, o la calidad de velocidad en la respuesta, hay que tener en cuenta otras cualidades, para buscar una integralidad al afirmar que el software es de calidad. Los desarrolladores del software, opinan que el sus productos son los mejores del mercado, pero no se han preguntado que opina el cliente. El tener un documento que explique los requerimientos para evaluar el software ayuda al desarrollo, compra o auditoría de cualquier aplicación informática del mercado, teniendo en cuenta que hoy en día es muy importante para las empresas privadas o públicas la inversión en este tipo de producto, los cuales verifican la calidad a la hora de entrar a producción, donde se detectan las falencias, reportando allí pérdidas. Este capítulo presenta indicadores de calidad de un software; al momento de la entrega, basados en los estándares de calidad sugeridos la norma ISO/IEC 9126; de la ISO (Organización Internacional de Normalización) y la IEC (Comisión Electrotécnica Internacional).


3.1

LECCIÓN 1: DEFINICIÓN DE CALIDAD

Inicialmente la calidad hace referencia al proceso industrial donde W. E. Deming propuso la idea de calidad como conformidad a requisitos y confiabilidad en el funcionamiento. Posteriormente surgen otras definiciones de calidad como la de J. Juran que propone una definición breve: ‘Quality is fitness for use”; es decir, la calidad es la adecuación del producto al uso donde esta definición incluye las características del producto que permiten obtener la satisfacción del usuario y, además, supone la ausencia de deficiencias. Para P. Crossby el concepto de Juran se asume pero también destaca la prevención: “Cero defectos” o “Hacerlo bien a la primera”. En la bibliografía son frecuentes las definiciones de calidad pero en su gran mayoría todas ellas se acercan al concepto expresado por Juran. La definición oficial, y más completa, es la de la norma ISO 9000:2000 que define la calidad en general como: “Grado en el que un conjunto de características inherentes cumple con los requisitos”, donde los requisitos son las necesidades o expectativas establecidas, generalmente implícitas u obligatorias y las características se refieren a cualquier tipo de rasgo diferenciador. También se debe recordar que las necesidades pueden variar en el tiempo, por lo que hay que prever la revisión de la especificación. Esta definición permite comprender que la consecución de la calidad puede tener tres orígenes: 3.1.1 La calidad realizada: Que es la calidad obtenida por la persona que realiza el trabajo gracias a su habilidad en la ejecución de una tarea. Se potencia con la mejora de las habilidades personales y técnicas de los participantes en un proceso determinado. 3.1.2 La calidad programada: Que es la calidad que se ha encomendado conseguir a la persona reponsabIe de ejecutar el trabajo. Se potencia con la elaboración de una especificación que sirva de buena referencia a los participantes en un proceso. Esta aperece descrita en una especificación, en un documento de diseño o en un plano constructivo. 3.1.3 La calidad necesaria: La que el cliente exige con mayor o menor grado de concreción o, al menos, la que le gustaría recibir. Se potencia con una adecuada obtención de información de la idea de calidad de los clientes y de su percepción de la misma. La gestión de la calidad pretenderá entonces, conseguir que estos tres círculos coincidan entre sí.


3.2

LECCIÓN 2: SISTEMAS DE CALIDAD EN LA EMPRESA

La política de la calidad forma parte de la política general de la empresa, por eso es importante que la dirección o gerencia exprese dicha política de manera explícita al igual que lo hace para la política financiera, de personal, etc. Por lo tanto, la gestión de la calidad forma parte de las tareas de la dirección, y para tener éxito, se debe contar con el compromiso y la participación de todos. Incluye la planificación estratégica, la asignación de recursos, las actividades sistemáticas, y evaluaciones entre otras. Actualmente, de forma general, se suele apoyar en la creación de lo que se denomina sistema de calidad para la organización. Un sistema de gestión de calidad es un un sistema para establecer políticas y los objetivos con respecto a la calidad y para lograr dichos objetivos se debe aplicar a la dirección y control de una organización. Este sistema de calidad se adecúa a los objetivos fijados por la empresa en cuanto al tema. La dirección es la responsable de fijar las políticas de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad. Uno de los factores fundamentales del trabajo en este nivel consiste en fijar la estructura organizativa con líneas de jerarquía y de comunicación ligada al sistema de gestión de calidad. Para ser útil el sistema de calidad debe cumplir con las siguientes características: Ser eficaz y comprendido por todos, dar confianza en satisfacer las necesidades de los clientes y poner mayor énfasis en prevenir que en detectar y corregir. Un sistema de calidad consta de dos partes, una escrita y otra práctica. La parte escrita está en una serie de documentos en los cuales se describe el sistema, los procedimientos, entre otros, ajustándose a una norma habitualmente se usa la noma ISO 9001. Y la parte práctica que tiene dos vertientes principales, una que tiene en cuenta los aspectos físicos (locales, herramientas, computadores) y otra que toma los aspectos humanos como la formación del personal (tanto en técnicas de calidad corno en técnicas de reuniones, comunicación) y en creación y coordinación de equipos de trabajo. El manual de calidad es el documento principal para establecer e implantar un sistema de calidad, en el se documentan todos los elementos, los requisitos y los medios que adopte la empresa para su sistema de calidad se deben establecer por escrito, ordenadamente, en forma de políticas y procedimientos. El manual de calidad debe describir adecuadamente el sistema de gestión de la calidad para servir como referencia permanente al implantar o al aplicar el sistema. El manual de calidad incluye las políticas de calidad que se han adoptado, la definición del sistema de calidad, la presentación de la estructura de la organización y la referencia a los procedimientos aplicables. Según la norma ISO 9OO4 y la norma UNE 66-907-91, se puede sugerir la siguiente estructura de un manual de calidad:


3.2.1 Capítulos de introducción • Índice • Declaración de la dirección de la empresa • Política de calidad y objetivos generales de la empresa respecto a la calidad • Objeto y campo de aplicación del manual de calidad • Terminología • Gestión del manual de calidad (procedimiento para cambios, aprobación, etc.) • Presentación de la empresa 3.2.2 Disposiciones para conseguir la calidad En general en el orden del ciclo de vida. El manual de calidad se establece principalmente para uso interno de la empresa aunque puede facilitar las relaciones cliente-proveedor, además es un elemento clave en el proceso de certificación del sistema de calidad de la empresa. El manual de calidad se completa con procedimientos o instrucciones específicas para ciertas actividades o procesos que deben mencionarse explícitamente en dicho manual. Para cada empresa suelen existir procedimientos particulares, cuyo fundamento debe ser la buena práctica y la experiencia en el trabajo diario y los códigos, las normas y las especificaciones a los que deben ajustarse. Para las organizaciones de desarrollo de software, se suelen incluir los procedimientos (técnicas y metodologías) para realizar y documentar el análisis de los sistemas, para realizar y documentar el diseño de los sistemas o de sus bases de datos, entre otros. En general, indicarán la metodología a aplicar, algunos ejemplos típicos de procedimientos relacionados con el desarrollo pueden ser el procedimiento de especificación de requisitos del software, el procedimiento para las pruebas del software, el procedimiento de estilo de codificación, etc. Otros documentos importantes en el sistema de calidad son los que aportan evidencias sobre la aplicación de calidad, sobre todo el proceso de desarrollo, en ellos se evidencia, los registros de datos sobre calidad, almacenamientos de datos sobre las actividades relacionadas con la calidad o sobre la evaluación de los productos. Normalmente suelen incluir datos de pruebas, datos sobre las revisiones e inspecciones, datos de costes de actividades. Estos se deben conservar incluso después de acabar el proyecto para analizar las tendencias de la calidad obtenida y corregir las causas de defectos. Algunas de las características que debería tener la documentación en cualquier caso son las siguientes: Tener como objetivo facilitar los medios para el buen funcionamiento del sistema de calidad, También debe servir para dejar constancia del nivel de calidad alcanzado, ser legible, estar fechada, limpia, identificable y archivada, e incluir todo tipo de documentos como especificaciones, y procedimientos.


3.3

LECCIÓN 3: NORMATIVIDAD DE CALIDAD

La normativa de calidad surge inicialmente en empresas de algunos de los sectores de seguridad crítica como el militar, nuclear, y aeroespacial. La normativa nuclear ha inspirado muchas otras normas, sin embargo, La revolución normativa para todos los sectores se produjo con la llegada de la serie de normas ISO 9000, inicialmente con la norma de gestión y aseguramiento de la calidad ISO 9000, y posteriormente tres normas con recomendaciones para el aseguramiento externo de la calidad, la ISO 9001, 9002 y 9003 dependiendo de qué parte del ciclo de la calidad fuera el centro de actividad de la empresa y una norma ISO 9004 con recomendaciones para la gestión interna de la calidad. Sin embargo, la reciente revisión de la serie 9000 realizada en el año 2000, cambió la filosofía y la estructura de las normas 9000, ahora existe una única norma ISO 9001:2000 que abarca todos los aspectos necesarios de todas las actividades del ciclo de vida. Las organizaciones que antes empleaban las normas ISO 9002 y 9003, aplicarán la ISO 9001:2000 limitando su ámbito de aplicación. El cambio de filosofía experimentado se basa en incrementar la importancia de la mejora continua y el ciclo PDCA (Plan-Do-Check-Act), así como una mayor definición de los procesos y de la evaluación de la satisfacción de clientes y usuarios. La importancia de estas normas reside en que se emplean como base para que las empresas se certifiquen en procesos y que transmita a sus clientes la confianza en que trabaja con procedimientos que permiten asegurar la calidad en sus actividades.

Figura 7: Modelo de Gestión de calidad ISO 9001: 2000


En el caso del software que es un producto muy especial, fue necesario hacer una interpretación de la versión ISO 9001:1994 generando la guía ISO 9000-3:1997 que es la “Guía para aplicar ISO 9001 al desarrollo, suministro y mantenimiento de software”. Con la llegada de la norma ISO 9001:2000, la guía ISO 9000-3 es aplicable y útil aunque requiere una actualización. La guía contempla tres aspectos principales de disposiciones adaptadas a la terminología y características especiales del software como producto, el primero es el marco de trabajo de la empresa (sistema de calidad, responsabilidad de la dirección y la realización de acciones correctivas), el segundo que muestra las actividades del ciclo de vida (Revisión de contrato, especificación, planificación, planificación de la calidad, diseño, implementación, revisiones, pruebas, aceptación, replicación, entrega, instalación y mantenimiento), y el tercero donde están las actividades de apoyo (Gestión de configuración, control de documentos, métricas, convenciones y reglas, herramientas, formación, registros de calidad y compras). Desde el punto de vista práctico, la ISO 9001:2000 incluye las siguientes disposiciones: 3.3.1 Responsabilidad de la dirección Desde un ámbito general muestra el compromiso con la satisfacción del cliente, promoviendo una determinación eficaz de requisitos y de las necesidades del cliente, establece una política de calidad que debe llevar a una planificación de la calidad y de sus objetivos, a través de un sistema de gestión de calidad en el que deben existir revisiones formales de la gestión realizada. 3.3.2 Gestión de recursos Para determinar y proporcionar lo necesario para la gestión de calidad, especialmente en el ámbito de los recursos humanos donde debe realizarse la adecuada política de asignación a tareas, determinar, realizar y evaluar el impacto de las acciones de formación y cualificación, y de competencias profesionales. No se deben olvidar otros recursos como la información, las infraestructuras necesarias y el entorno de trabajo. 3.3.3 Gestión de los procesos Con disposiciones para las actividades de gestión, los procesos relacionados con el cliente, el diseño y el desarrollo de productos y servicios, la gestión de compras y proveedores, la producción y la operación de servicios, el control de las no-conformidades de las entregas respecto de los requisitos establecidos y los servicios post-entrega.


3.3.4 Medición, análisis y mejora Contempla la medición del rendimiento del sistema, medición de procesos, medición de productos y/o servicios y el control de la propia medición y de los medios de inspección y prueba. En cuanto a análisis de datos, se trata de obtener las conclusiones apropiadas para emprender acciones de mejora relacionadas con correción de errores, prevención de problemas para el futuro y el establecimiento de procesos de mejora continua. 3.4

LECCIÓN 4: INGENIERÍA DE SOFTWARE Y CALIDAD

Para hablar de la calidad en el software, se debe tener en cuenta que este es un producto con características particulares, por lo cual se hace necesario adaptar la terminología creada y aplicada en los sectores industriales. Algunas de estas características del software son las siguientes: El software se desarrolla, no se fabrica ya que todo el costo de producción se centra en el diseño de la primera copia. El software es un producto lógico, el verdadero producto del software es el diseño de una serie de instrucciones para el computador, su existencia en papel o en soporte magnético no es más que una representación en un código o lenguaje de las instrucciones. El software no se degrada con el uso, ya que la naturaleza lógica del software permite que permanezca inalterable por muy intensa que sea su utilización. Se puede degradar su representación magnética pero no su esencia. La complejidad del software, la ausencia de controles adecuados hace que el software sea entregado muchas veces y conscientemente con defectos, incluso públicamente declarados. En el sector informático, incluso, se llega a cobrar una cuota de mantenimiento para reparar los defectos que el propio productor del software ha entregado con el mismo. Un porcentaje muy grande de la producción de software se hace aún a medida. En vez de emplear componentes existentes y ensamblarlos, aunque las bibliotecas de funciones o componentes están ya cambiando en parte esta situación. El software es extraordinariamente flexible, ya que se puede cambiar con facilidad reutilizando trozos de un producto para construir otro. Sin embargo, la facilidad para cambiarlo es también un peligro que hay que controlar. El diccionario estándar de ingeniería del software IEEE Std.6l0, indica que software son “los programas de ordenador, los procedimientos y, posiblemente, la documentación asociada y los datos relativos a la operación del sistema informático”. No se limita al código solamente y se debe tener en cuenta el software en cualquier estado de evolución (diseños, especificaciones, datos de prueba, etc), si se quiere obtener calidad en el software. También conviene


recordar que la calidad del software se debe obtener a medida que se construye; no es un añadido que se pueda poner una vez desarrollado el software. 3.5

LECCIÓN 5: GESTIÓN DE LA CALIDAD DEL SOFTWARE

La definición del estándar IEEE Std.610-1991, indica que calidad del software es el grado con el que un sistema, componente o proceso cumple con los requisitos especificados y las necesaidades expectativas del cliente o usuario. Esta definición es la que más se ajusta al concepto de concordancia del software producido con los requisitos explícitamente establecidos, con los estándares de desarrollo expresamente fijados y con los requisitos implícitos, no establecidos formalmente, que desea el usuario. Los requisitos se reflejan en la especificación de requisitos de manera explícita, el documento constituye la culminación de la etapa de análisis dentro del proceso de desarrollo. Los requisitos pueden ser funcionales, cuando se determinan las funciones que debe realizar el software y no funcionales como el rendimiento, la seguridad, el tiempo de respuesta, la interfaz, etc. De igual forma, los estándares y las normas, determinan cómo se debe realizar el proceso de desarrollo de software. Además, existen requisitos implícitos, no expresamente declarados, pero que el usuario del software desea obtener. Para hacer el estudio de la calidad del software se debe conocer primero los principales términos empleados en esta área, algunos de ellos son: 3.5.1 Gestión de la calidad del software (Software Quality Management) Son las actividades coordinadas para dirigir y controlar una organización en lo relativo a la calidad. Esto se puede entender como el aspecto de la función general de la gestión que detemina y aplica la política de calidad (objetivos y directrices generales de calidad de una empresa). Normalmente la gestión de calidad se aplica a nivel de empresa, por lo que incluye planificación estratégica, asignación de recursos, etc. 3.5.2 Aseguramiento Assurance)

de

la

calidad

del

software

(Software

Quality

Es la parte de la gestión de la calidad orientada a proporcionar confianza en que se cumplirán los requisitos de la calidad. A nivel del software, podría presentarse como el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto satisfará los requisitos dados de calidad. También puede referirse, en el software al “conjunto de actividades para evaluar el proceso mediante el cual se desarrolla el producto”. El aseguramiento pretende dar confianza en que el producto tiene calidad.


3.5.3 Control de la calidad del software (Software Quality Control) Es la parte de la gestión de la calidad orientada al cumplimiento de los requisitos de la calidad. Suele incluir las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales, el de mantener bajo control un proceso y eliminar las causas de defectos en las diferentes fases del ciclo de vida. En general, son las actividades para evaluar la calidad de los productos desarrollados. También, en el software, puede ser el “proceso de verificar el propio trabajo o el de un compañero”. 3.5.4 Verificación y validación del software (Software Verication and Validation) Que es una actividad ligada al control de la calidad en el ámbito del software. La verificación hace refrencia a comprobar si los productos construidos en una fase del ciclo de vida satisfacen los requisitos establecidos en la fase anterior. Se suele decidir si el producto esta completo y es consistente. Aquí se realizan las actividades para comprobar si un producto software esta técnicamente bien construido y si funciona. Y la validación que se refiere a comprobar si el software construido satisface los requisitos del usuario. Por lo tanto, son las actividades de comprobación de que el producto software construido es el que se deseaba construir, es decir, si el producto funciona como el usuario quiere y realiza las funciones que se habían solicitado.


GLOSARIO DE TÉRMINOS Automatización: Es el uso de sistemas o elementos computarizados y electromecánicos para controlar maquinarias y/o procesos industriales sustituyendo a operadores humanos. Ciclo de Vida: El ciclo de vida de software es la descripción de las distintas formas de desarrollo de un proyecto informático. Ciclo de Vida Ágil: Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Componente Software: Son todos aquellos recursos desarrollados para un fin concreto y que puede formar solo o junto con otros, un entorno funcional requerido por cualquier proceso predefinido. Estándar: Base o modelo en el que todo el mundo se ha puesto de acuerdo. IEEE: Corresponde a las siglas de (Institute of Electrical and Electronics Engineers) en español Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. ISO: (Internacional Standards Organization) Organización Internacional de estándares fundada en 1946, con sede principal en Ginebra, ISO establece o fija estándares internacionales. Se ocupa de todos los campos, excepto la electricidad y la electrónica, que se rigen por la Internacional Electrotechnical Comisión (IEC), también en Ginebra. Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas para un conjunto de descripciones que de otra manera no podrían ser sistematizadas. Proceso: El proceso de ingeniería de software se define como un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad. Requerimientos: Características que se desea que posea un sistema o un software.


Calidad: La calidad es herramienta básica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie. Calidad de Software: Características propias del software que se desea controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico. ISO 9001: Es un conjunto de normas sobre la calidad y la gestión. Gestión de Calidad de Software: Es un conjunto de actividades de la función general de la Dirección que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinación y aplicación de las políticas de calidad de la empresa.


FUENTES DOCUMENTALES Bibliografía de referencia: Beck, K.. .Extreme Programming Explained. Embrace Change., Pearson Education, 1999. Traducido al español como: .Una explicación de la programación extrema. Aceptar el cambio., Addison Wesley, 2000. CETTICO, Centro Transferencia tecnológica en Informática y Comuicaciones., Enciclopedia de Informática y Computación, Ingeniería de software e Inteligencia artificial. Universidad Politécnica de Madrid 1999. De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997. Piatini, Mario y col. Analisis y Diseño de Aplicaciones Informáticas de Gestión, Una Perspectiva de Ingeniería de Software, Alfaomega 2004. Páginas 109 – 164. BRAUDE. Ingeniería de software, una perspectiva orientada a objetos. México. 2003. Alfaomega grupo editor. S.A. HUMPHREY, Watts S. Introducción al proceso de software personal. Pearson Addison wesley. 2001. NORRIS. Ingeniería de software explicada. Grupo Noriega editores de Colombia. PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos, técnicas y métodos para la gestión del cambio. Editorial Alfaomega-Rama. PRESSMAN, Roger S. Ingeniería del Software. Un enfoque práctico. Quinta edición. España. 2002. Editorial McGraw Hill. SOMMERVILLE, Ian. Ingeniería de software. 6ª. Edición. Pearson Addison Wesley. 2001 Direcciones Electronicas (webgrafía) http://www.pressman5.com http://www.wiley.com/college/braude http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf

http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html http://www.sistemas.unam.mx/software.html



Justificación


ESTÁNDARES, MÉTRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE En este capítulo se trata los temas que son el fundamento de la calidad del software y su evaluación, entre ellas están los modelos y estándares actuales de calidad, que detallan las características mediante las cuales se hace la evaluación, las métricas de calidad y las métricas técnicas de calidad del software que son los indicadores, las escalas de medición cualitativa o cuantitaiva y las pruebas del software que se ejecutan para verificación de la calidad del producto o proceso. Esta unidad es quiza una de las más importantes para la evaluación del software, ya que se identifica en ella los tipos de evaluación estática y dinámica mediante el uso de las métricas y las pruebas del software. Los estándares son los que permiten referencias cuales características se evaluará y que métricas y pruebas se asocian a ellas. - El estudiante conoce los estándares y modelos utilizados para la evaluación de la calidad del software - El estudiante reconoce las características internas, externas y de usabilidad dentro de los estándares - El estudiante asocia cada una de las características con las métricas y las pruebas a realizar en cada caso

Denominación de capítulos Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de capítulos Denominación de

- El estudiante define de acuerdo a las especificaciones del cliente, las características, subcaracterísticas, métricas y pruebas a utilizar CAPITULO 4: ESTANDARES Y MODELOS DE CALIDAD DEL SOFTWARE Lección 1. La Calidad del Software Lección 2. Calidad del Producto Software – Norma ISO/IEC 9126 Lección 3. Calidad del Producto software – Norma ISO/IEC 14598 Lección 4. Calidad del Producto Software – Norma ISO/IEC 25000 (SquaRE) Lección 5. Modelos de Mejora de Procesos de Software. CAPITULO 5: MÉTRICAS DE CALIDAD SOFTWARE Lección 1. Conceptos Básicos de Métricas

DEL


lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de capítulos Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones

Lección 2. Métricas del Software Lección 3. Métricas de Calidad del Software Lección 4. Métricas Técnicas del Software Lección 5. Estructura para las Métricas de Calidad del software CAPITULO 6: PRUEBAS DEL SOFTWARE Lección 1. La Prueba del software Lección 2. Técnicas de diseño de Casos de Prueba Lección 3. Estrategias de Aplicación de Pruebas del Software Lección 4. Pruebas de Software para Objetos Lección 5. Pruebas de Software Basado en Componentes


UNIDAD 2

ESTÁNDARES, MÉTRICAS DE CALIDAD Y PRUEBAS DEL SOFTWARE


CAPITULO 4

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE


INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años. En particular, la aplicación de la calidad al producto software toma cuerpo con la aparición de los primeros modelos de calidad de producto y se fortalece con la propuesta de normas internacionales que comienzan a ser utilizados como marco de referencia para el campo profesional y académico. En el año de 1987 la oficina internacional para la estandarización (ISO) y la Comisición Electrotécnica internacional (IEC), constituyeron un comité técnico conjunto con la finalidad de proponer normas internacionales en el campo de las tecnologías de la información y los equipos. En 1985 se inició el desarrollo la norma internacional ISO/IEC y fue publicada en 1991 como “ISO/IEC 9126:1991: Tecnología de la Información – Evaluación del Producto Software – Características de la Calidad y Guía para su Aplicación”. Utilizaron como base para la definición de las características, el concepto de calidad que posteriormente aparecería en la norma ISO 8402 y que está basada en las necesidades del usuario. Antes de la publicación de la norma ISO/IEC 9126, los trabajos de McCall, Boehm y otros fueron adoptados y mejorados. Esta norma constituyó el primer esfuerzo internacional para unificar y uniformizar los términos de calidad referido al producto software y proponer una estructura basada en características y subcaracterísticas de calidad. En 1994, se determina la revisión de la norma ISO/IEC 9126 debido a que se estaban desarrollando normas internacionales en el área de evaluación de la calidad de productos. Resultado de la revisión, se producen dos series de normas; ISO/IEC 9126 referida al modelo de calidad del producto software y la ISO/IEC 14598 referida a la evaluación de la calidad del producto. La publicación completa de ambas series, se iniciaron en julio de 1998 y concluyeron en abril de 2004, habiéndose elaborado 4 normas en las serie 9126 y 6 normas en la serie 14598. Una nueva propuesta de calidad de producto se plantea en 1999 y se aprueba en el 2000. La propuesta se denomina proyecto SquaRE (Software product Quality REquirements) con la idea de proponer un nuevo marco de referencia para el tema de calidad de producto software, pero esta vez orientándose a ver la calidad del producto como resultado de un proceso. La serie de normas internacionales tendrán la numeración 25000 y aún no esta completa. Cada una de estas normas está dividida en características y subcaracterísticas internas, externas y de usabilidad que hacen posible definir las métricas asociadas a cada una de estas y el tipo de pruebas que se deben llevar a cabo en la evaluación de software.


4.1

LECCIÓN 1: LA CALIDAD DEL SOFTWARE

El software es un componente presente en una gran cantidad de actividades y su correcta operación es a menudo crítica para el éxito del negocio y/o la seguridad de las personas. El desarrollo o selección de productos software de gran calidad es, por tanto, de suma importancia. Una especificación y evaluación detallada de la calidad del producto software es un factor clave para asegurar la calidad adecuada. Esto se puede lograr definiendo de manera apropiada las características de la calidad y teniendo en cuenta el propósito del uso del producto software. Es importante que cada caracteristica relevante de la calidad del producto software sea especificada y evaluada utilizando métricas validadas o de amplia aceptación. En la norma ISO/IEC 14598 se define al modelo de calidad como un conjunto de características y la relación entre las mismas, que conforman la base para especificar requerimientos de calidad y evaluar la calidad, en la siguiente figura se muestra un modelo de calidad de dos niveles para las características y subcaracterísticas y en el tercer nivel presenta las métricas; estas últimas se pueden obtener de la medición de los diversos atributos que tiene el producto y que influyen en cada subcaracterística.

Figura 8: Esquema general de un modelo de calidad del software Garvin presenta un enfoque interesante y muy influyente, con cinco visiones de la calidad: La visión trascendental que puede ser reconocida pero no definida, la visión del usuario como la adecuación al propósito del usuario, la visión del productor como conformidad con la especificación, la visión del producto basada en las características observables del producto, y la visión basada en el valor que el cliente esta dispuesto a pagar por ella. El modelo ISO/IEC 9126 presenta el concepto de calidad en uso, la calidad externa y la calidad interna que corresponden con la visión del usuario, del productor y del producto.


La siguiente figura representa el ciclo de vida de la calidad que muestra la influencia o dependencia entre los distintos enfoques de calidad interna, externa y en uso.

Figura 9: Ciclo de vida de la calidad La siguiente figura representa la calidad como parte del ciclo de vida de desarrollo de software. En este gráfico también se aprecia que las necesidades de calidad del usuario sobre el producto de software, contribuyen a especificar los requerimientos de calidad externa y estos a su vez los requerimientos de calidad interna. El cumplimiento de los requisitos de calidad interna se comprobarán en un proceso de verificación que permitirá medirlo, el cumpliemiento de requisitos de calidad externa se comprobarán en un proceso de validación que permitirá medirlo y finalmente la satisfacción de las necesidades de la calidad del producto se comprobarán en un proceso de evaluación que permitirá medir la calidad en uso.


Figura 10: Calidad en el ciclo de vida del software 4.2 LECCIÓN 2: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC 9126 La norma ISO/IEC 9126 presentan dos modelos de calidad, el primero referido a la calidad interna y externa y el segundo modelo referido a la calidad en uso, a continuación se describe cada uno de ellos. 4.2.1 Calidad interna y externa La norma ISO/IEC 9126 define la calidad interna como la la totalidad de las características del producto software desde una perspectiva interna. La calidad interna es medida y evaluada en base a los requerimientos de calidad interna La calidad externa se define como la totalidad de las características del producto software desde una perspectiva externa. Es la calidad del software cuando es ejecutado, la cual es típicamente medida y evaluada mientras se prueba en un ambiente simulado, con datos simulados y usando métricas externas. Durante las pruebas, muchas fallas serán descubiertas y eliminadas. Sin embargo algunas fallas todavía pueden permanecer después de las pruebas. Como es difícil corregir la arquitectura de software u otros aspectos fundamentales del diseño del software, el diseño fundamental permanece sin cambios a través de las pruebas. En la siguiente figura se representa el modelo de calidad interna o externa, se muestra un conjunto de seis características: funcionalidad, fiabilidad, usabilidad, eficiencia, facilidad de mantenimiento y portabilidad.


Figura 11: Modelo de calidad interna y externa del producto software En la siguiente tabla se muestra las seis características y las definiciones de cada una de ellas. Característica Funcionalidad Fiabilidad Usabilidad Eficiencia Facilidad mantenimiento Portabilidad

de

Definición Capacidad del producto software para proveer las funciones que satisfacen las necesidades explícitas e implícitas cuando el software se utiliza bajo condiciones específicas. Capacidad del producto software para mantener un nivel especificado de funcionamiento cuando se está utilizando bajo condiciones específicadas Capacidad del producto software de ser entendido, aprendido usado y atractivo al usuario, cuando es usado bajo las condiciones especificadas Capacidad del producto software para proveer un desempeño apropiado, de acuerdo a la cantidad de recursos utilizados y bajo las condiciones planteadas Capacidad del producto software para ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, en requerimientos y especificaciones funcionales Capacidad del producto software de ser trasladado de un entorno a otro

Tabla 17: Características de la calidad interna y externa ISO/IEC 9126. 4.2.2 Calidad en uso La norma ISO/IEC 9126 define la calidad en uso como la perspectiva del usuario de la calidad del producto software cuando éste es usado en un ambiente específico y un contexto de uso específico. Éste mide la extensión para la cual los


usuarios pueden conseguir sus metas en un ambiente particular, en vez de medir las propiedades del software en si mismo. La siguiente figura representa el modelo de la calidad en uso que muestra un conjunto de 4 características: efectividad, productividad, integridad, y satisfacción.

Figura 12: Modelo de calidad del producto software para la calidad en uso. La definición de cada una de las características de la calidad en uso se muestra en la siguiente tabla: Carcaterística Efectividad Productividad Integridad Satisfacción

Definición La capacidad del producto software para permitir a los usuarios lograr las metas especificadas con precisión y completitud en un contexto de uso específico La capacidad del producto software para permitir a los usuarios emplear cantidades apropiadas de recursos en relación a la efectividad lograda en un contexto de uso específico La capacidad del producto software para lograr niveles aceptables de riesgo de daño a las personas, negocio, software, propiedad o entorno en un contexto de uso específico La capacidad del producto software para satisfacer a los usuarios en un contexto de uso específico

Tabla 18: Características de la calidad en uso ISO/IEC 9126 Las métricas de calidad del producto se aplican a los diversos atributos del producto y permiten determinar posteriormente los niveles de calidad del producto. Las métricas que se pueden aplicar de acuerdo a los atributos están definidas en las normas ISO/IEC 9126 – 2 para el caso de la calidad externa, la ISO/IEC 9126 – 3 para el caso de la calidad interna y la ISO/IEC 9126 – 4 para el caso de la calidad en uso. En todos los casos, las normas señalan que las métricas presentadas no pretenden ser exhaustivas y completas, ni limita la posibilidad de usar otras métricas de acuerdo a las necesidades del usuario. Las métricas internas pueden ser aplicadas durante el diseño y la codificación del producto software no ejecutable y proporciona a todos los involucrados el beneficio de conocer la calidad del producto duracte su


construcción y tomar decisiones sobre esa base para conseguir el producto con la calidad esperada. Las métricas externas pueden ser aplicadas durante la prueba y operación del producto software ejecutable y proporciona a todos los involucrados el beneficio de conocer la calidad del producto software durante las pruebas u operación y saber si cumple con la calidad esperada. Las métricas de calidad en uso miden el nivel en que un producto software cumple con las necesidades específicas de los usuarios en un contexto de uso determinado por los escenarios en los que el usuario realiza sus tareas. 4.3 LECCIÓN 3: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC 14598 El estandar ISO/IEC 14598 es actualmente usado como base metodológica para la evaluación del producto software. Los productos de software son solo una parte de la historia, también es necesario considerar mediciones en el proceso empleado para diseñar, desarrollar, probar, y controlar el producto. En esto juega un papel importante la ISO/IEC 14598 que ofrece una visión general, explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126, define los términos técnicos utilizados, contiene requisitos generales para la especificación y evaluación de la calidad del software, y clarifica los conceptos generales. Además provee un marco de trabajo para evaluar la calidad de todos los tipos de productos software y establece requisitos para los métodos de medición y evaluación de los productos de software. Es importante señalar que, la serie de normas ISO/IEC 14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de productos de software e indica los requisitos para los métodos de medición y para el proceso de evaluación. La norma ISO/IEC 14598 consta de seis partes que describen los requisitos del proceso de evaluación en tres situaciones diferentes: Requisitos para desarrolladores (parte 3), Requisitos para compradores (parte 4), Requisitos para evaluadores (parte 5).


Figura 13: Norma ISO/IEC 14598 4.3.1 ISO/IEC 14598 – Parte 1: Visión General Básicamente provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126. Adicionalmente, hace la presentación del proceso de evaluación desglosado en los siguientes pasos: Establecer los requerimientos de evaluación, especificar la evaluación, planear la evaluación, Ejecutar la evaluación. 4.3.2 ISO/IEC 14598 – Parte 2: Planificación y Gestión Esta parte contiene los requerimientos y las guías para las funciones de soporte tales como el planeamiento y gestión para la evaluación del producto del software. Fundamentalmente, en esta parte, se planifican las mediciones y las actividades de evaluación, específicamente se incluye: Preparación de las políticas, definición de objetivos organizacionales y de mejora, identificación de la tecnología, asignación de responsabilidades, Identificación e implementación de técnicas de evaluación para software desarrollado y adquirido, entrenamiento en tecnología, recopilación de datos y herramientas, comparación y administración de mejoras dentro de la organización. 4.3.3 ISO/IEC 14598 – Parte 3. El Proceso para desarrolladores Esta parte provee los requerimientos y las recomendaciones para la evaluación del producto software cuando la evaluación es conducida en paralelo


con el desarrollo y llevada a cabo por el desarrollador. Se enfoca en el uso de indicadores que pueden predecir la calidad final del producto midiendo los productos intermedios que se desarrollan durante el ciclo de vida. Esta parte cubre el planeamiento y evaluación de mediciones internas y externas con el fin de asegurar de que la calidad del producto sea incorporada en la fase de desarrollo. Una vez identificadas las características fundamentales de calidad y el marco de trabajo, deben ser definidas las etapas siguientes: 4.3.3.1 Organización: Los aspectos organizacionales de desarrollo y de soporte deben formar parte de todo el sistema de calidad y del plan de mediciones. 4.3.3.2 Planeamiento del Proyecto y requerimientos de Calidad: El desarrollo y el ciclo de vida de soporte deben ser establecidos y documentados durante el plan de calidad o en otros documentos. Es de vital importancia verificar que el productor y las medidas de control requeridas sean técnicamente factibles, razonables y alcanzables. 4.3.3.3 Especificaciones: Esta es la fase, el desarrollador realiza un mapeo de los requerimientos internos y externos de calidad, con relación a las especificaciones. Los requerimientos de mediciones resultantes de esta fase deben ser un tipo de mapeo entre las especificaciones de requerimientos, requerimientos externos de calidad, requerimientos internos correspondientes de calidad y atributos especificados junto a sus escalas de medición y valores objetivos que contribuyan a la cuantificación de la calidad del software, todo esto puede enfocarse por proyecto o por producto. 4.3.3.4 Diseño y planeamiento: Los procedimientos requeridos para el análisis y recopilación de datos necesitan ser definidos. De esta manera, el plan incluirá: Cronogramas, asignación de responsabilidades, uso de herramientas, bases de datos y entrenamiento especializado requerido. La precisión de las mediciones y técnicas estadísticas deben ser especificadas. En esta fase también deberá consideerarse como los resultados de las mediciones impactarán en el desarrollo y los planes de contingencia y de mejora. 4.3.3.5 Montaje y pruebas: durante la etapa de montaje y pruebas, las mediciones actuales son recolectadas, se realizan análisis apropiados y se toman acciones necesarias. En cada fase del desarrollo debe procurarse lograr un montaje primeramente enfocado a las características internas y externas de calidad que definan la calidad global del producto y que puedan ser validades por los resultados de las pruebas y la experiencia del usuario. Y como etapa final del proyecto, deberá ser conducida una revisión general para determinar la efectividad global del ejercicio de recolección, para identificar costos versus costos, establecer la validez de las métricas usadas e identificar puntos en los cuales podrían obtenerse beneficios para proyectos futuros. El resultado de esta revisión podría retroalimentar directamente el lanzamiento de futuros productos.


4.3.4 ISO/IEC 14598 – Parte 4. El proceso para compradores Esta parte provee los requerimientos y las recomendaciones para que la evaluación del producto software sea conducida en función a los compradores que planean adquirir o re-usar un producto de software existente o pre-desarrollado. Los que adquieren el producto pueden comprar paquetes completos ya sea desarrollados según ciertas especificaciones o pre-desarrollados para un mercado más general. Los compradores también podrían ser desarrolladores que desean integrar productos estándar en sus propios diseños de software, o de desarrolladores buscando herramientas específicas de software. Al respecto, cuatro etapas son necesarias: Establecimiento de los requerimientos: El alcance de la evaluación necesita ser establecido. Los requerimientos para la calidad delsoftware definidos en la ISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectos como el costo y el de cumplimiento a regulaciones deberán ser también considerados. El tiempo de la evaluación necesita ser consistente con los objetivos; enfoques muy tempranos podrían no proporcionar una figura adecuada de la situación mientras que enfoques muy tardíos podrían ser muy limitados en su uso. 4.3.4.1 Especificación de la Evaluación: Durante la redacción de las especificaciones, debe considerarse: Los requerimientos de calidad a ser evaluados correlacionados con la calidad en uso y métricas externas con prioridades además de un umbral de aceptación definido, el alcance y lo que cubren los casos de prueba donde sean aplicables referencias a módulos de evaluación, los métodos de recolección de mediciones, información requerida y métodos de análisis. 4.3.4.2 Diseño de la Evaluación: El tipo de evaluación depende del tipo de software que está siendo evaluado. Software bajo desarrollo puede ser abordado en puntos discretos durante el desarrollo o cuando estécompleto. Un plan de evaluación necesita considerar: Necesidades de acceso a la documentación del producto, herramientas de desarrollo y personal, requerimientos en costos y conocimientos, cronograma de evaluación y arreglos de contingencia, y criterio para decisiones de evaluación, métodos y herramientas de reporte, procedimientos para la validación y estandarización sobre proyectos futuros. 4.3.4.3 Ejecución de la Evaluación: Aunque esta etapa podría ser simplemente un registro en un libro de seguimiento, podría tenerse la necesidad de incluir: Los resultados mismos y la trazabilidad del producto así como información de configuración, registros de análisis, resultados y decisiones, problemas, limitaciones en las mediciones y cualquier compromiso con relación a los objetivos originales, conclusiones sobre los resultados de la evaluación pero también sobre los métodos empleados.


4.3.5 ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores Esta parte provee los requerimientos y recomendaciones para la evaluación del producto software cuando la evaluación es conducida por evaluadores independientes. En esta parte tiene un rol importante los requerimientos de evaluación, las especificaciones de evaluación,el diseño de la evaluación, las actividades de evaluación y el reporte de evaluación.Estas etapas son resumidas a continuación: 4.3.5.1 Requerimientos de Evaluación: Los requerimientos deberían adicionalmente definir: La extensión del la cobertura (o el alcance), los objetivos de evaluación y métodos de reporte, las calificaciones e independencia requeridas de un evaluador. 4.3.5.2 Especificación de la Evaluación: Las especificaciones adicionalmente deberían cubrir: Definición del alcance y formato en las métricas empleadas identificando como deberán ser derivadas a partir de los requerimientos del producto, la identificación de mediciones no determinísticas para asegurar que ciertos niveles de frecuentabilidad y objetividad requeridos sean obtenidos, la identificación de métodos de correlación con relación a los resultados de las mediciones. Se tienen identificadas tres sub-actividades con relación a la especificación de la evaluación: El análisis de la descripción del producto, la especificación de las mediciones a ser realizadas, la verificación de la especificación resultante frente a los requerimientos de evaluación. 4.3.6 ISO/IEC 14598 - Parte 6: Documentación de los Módulos de Evaluación Esta parte provee las guías para la documentación del módulo de evaluación. Estos módulos representan la especificación del modelo de calidad y las correspondientes métricas internas y externas que serán aplicadas a una evaluación en particular. Incluye métodos y técnicas de evaluación más las mediciones actuales resultantes de su aplicación. En esta parte tambiénse considera la administración efectiva de complejidades inherentes a las cuestiones de medición. Las actividades de medición coordinadas son una característica para una evaluación efectiva y un plan necesita proveer un cronograma de evaluación que provea al mismo tiempo información óptima cuando la evaluación sea conducida durante el desarrollo. Los módulos de la evaluación son componentes claves de la ISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible de reporte.Dichos módulos proveen: Visibilidad de la información necesitada para cuadrar con requerimientos específicos de calidad, Documentación de las interfaces necesarias con herramientas de medición.


4.4 LECCIÓN 4: CALIDAD DEL PRODUCTO SOFTWARE – NORMA ISO/IEC 25000 (SquaRE) Desde el año 2000 se viene trabajando el proyecto SquaRE que pretende establecer un modelo para la especificación y evaluación de un producto software, lo que ha llevado a reordenar la actual distribución de normas internacionales ISO/IEC 9126 e ISO/IEC 14598 y considerando otras normas desarrolladas hasta la fecha. En la siguiente figura se puede apreciar la nueva arquitectura de la serie de normas 25000.

Figura 14: Arquitectura de la serie de normas ISO/IEC 25000 ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation) es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluación del software). Uno de los principales objetivos de la serie SQuaRE es la coordinación y harmonización del contenido de ISO 9126 y de ISO 15939:2002 (Measurement Information Model). ISO 15939 tiene un modelo de información que ayuda a determinar que se debe especificar durante la planificación, performance y evaluación de la medición. Para su aplicación, cuenta con los siguientes pasos: Recopilar los datos, Preparación de los datos y Análisis de los datos. La integración de ISO 9126 e ISO 15939 permiten plantear un proceso de 4 pasos: El primero, la identificación de los requerimientos relacionados a la calidad del producto, es decir, seleccionar la parte del modelo de calidad (ISO/IEC 9126-n) que resulta relevante para la evaluación de calidad, el segundo, la identificación del contexto de interpretación. Es decir, selección de los valores de referencia y determinación de los target especificados en un contexto determinado, tercero, uso de las medidas derivadas de la etapa de preparación de los datos, y el cuarto, comparación y análisis de los resultados obtenidos respecto de un conjunto de valores de referencia.


SQuaRE incluye un estándar de requerimientos de calidad. Está compuesto por 14 documentos agrupados en 5 tópicos: Administración de la Calidad – 2500n, Modelo de Calidad – 2501n, Medidas de Calidad – 2502n, Requerimientos de Calidad – 2503n y Evaluación de la Calidad – 2504n. Administración de la Calidad: Abarca la Guía para SquaRE y Planificación y Administración. Modelo de Calidad: Describe el modelo de calidad interno / externo y la calidad en uso y presenta características y subcaracterísticas. Medidas de Calidad: Medición de primitivas, Medidas para la calidad interna, Medidas para la calidad externa y Medidas para la calidad en uso. Requerimientos de Calidad: Permite habilitar la calidad del software a ser especificado en términos de requerimientos de calidad durante todo el ciclo de vida de un proyecto de software o adquisición, mantenimiento y operación. Evaluación de la Calidad: Evaluación de la Calidad, Proceso para desarrolladores, Proceso para compradores, Proceso para evaluadores y Documentación del módulo de evaluación. En la figura siguiente se puede apreciar el modelo de referencia SquaRE, de la cual hay una reestructuración de los contenidos, se alinea a otros documentos existentes, y se amplian aspectos que las normas anteriores sólo se señala a manera de información.

Figura 15: Modelo de referencia para la arquitectura Square


LECCIÓN 5: MODELOS DE MEJORA DE PROCESOS DE SOFTWARE La mejora de proceso software es un mecanismo de mejora continua de la calidad, el cual básicamente consiste en aplicar de forma consistente las prácticas que proporcionan buenos resultados y eliminar o cambiar aquellas prácticas que causan problemas. Para aplicar la mejora de proceso software, es necesario tener claro tres aspectos fundamentales: Selección del modelo de mejora del proceso a utilizar, Selección del modelo de proceso a utilizar como referencia, Selección del método a utilizar en la etapa de evaluación. A continuación se indican de forma breve cómo han ido surgiendo los diferentes modelos de mejora continua del proceso software, así como los diferentes métodos de evaluación en el mundo. 5.1

Estados Unidos

En noviembre de 1986, el Instituto de Ingeniería del Software (Software Engineering Institute, SEI) de Pittsburgh, ante la demanda por parte del Departamento de Defensa de los Estados Unidos (Department of Defense, DoD) de un modelo que pudiera valorar la capacidad de sus contratistas software, empezó a desarrollar un modelo sobre la madurez del proceso software. En septiembre de 1987, el SEI publicó el primer borrador del modelo de madurez del proceso software y un cuestionario asociado con respuestas del tipo “si” o “no” que no recogen diferentes niveles de cumplimiento sobre los aspectos tratados. Este modelo y el cuestionario culminaron en agosto de 1991 en la versión 1.0 del Modelo de Madurez de Capacidad para el Software (Capahility Maturity Model, CMM). Utilizando este modelo como base, el SEI comercializó dos métodos para determinar la madurez del proceso software de una empresa: Evaluación del Proceso Software y Valoración de la Capacidad Software. La versión 1.1 del CMM publicó en febrero de 1993 junto con la actualización del método SCE (v.2.0) para que estuviese alineado con la versión 1.1 del CMM. Muchas empresas han modificado el método SPA para alinearlo con la versión 1.1 del CMM; una de estas empresas ha sido el Instituto para la Mejora del Proceso Software que ha propuesto el método de Evaluación Enfocado en la Acción. En mayo de 1995, el SEI actualizó el SPA, denominándose método de Evaluación basada en el CMM para la Mejora Interna del Proceso v.1.0 (CMMBased Appraisal for Internal Process Improvemnent, CBA IPI). Se generaron nuevas versiones más consistentes del CBA IPI y de SCE en abril de 1996 donde se utilizan aproximaciones comunes para interpretar el CMM y para recoger y analizar los datos. Actualmente, se encuentra disponible el CMMI, que recoge aspectos tanto del CMM como de ISO/IEC 15504.


5.2

Unión Europea

En 1988, la Comisión de la Comunidad Europea comenzó a realizar un estudio sobre el comportamiento de su principal programa de Tecnologías de la Información, el Programa Estratégico Europeo para la Investigación en Tecnologías de la Información descubriéndose que la transferencia de tecnología en el área particular de la ingeniería del software no había tenido el éxito esperado a diferencia de lo acaecido en otras áreas como la fabricación. Así, entre octubre de 1990 y febrero de 1993, la CEC desarrolló un proyecto ESPRIT de investigación denominado BOOTSTRAP para dotar a Europa de un método de evaluación y mejora del proceso software. Este proyecto fue uno de los pioneros en Europa sobre mejora del proceso software (European System and Software Iniciative, ESSI). Se desarrolló tomando como base el CMM, la serie de estándares lSO 9000 y el modelo genérico de proceso, PSS 005, de la Agencia Espacial Europea. A partir de febrero de 1991, el método ha sido gestionado y desarrollado por un grupo de interés económico europeo, llamado Instituto Bootstrap, el cual publicó la versión 2.3 en septiembre de 1995 y la versión 3.0 en febrero de 1997 (con ISO/IEC 15504). 5.3

ISO/IEC

Durante 1990-91, el DTI del Reino Unido patrocinó un estudio de investigación, denominado ImprovelT, para analizar los métodos de evaluación y valorar la capacidad de ingeniería del software de los contratistas potenciales. Este estudio descubrió que existían numerosos métodos de evaluación que estaban en uso o bajo desarrollo. También identificó un apoyo muy extendido por parte de las empresas al desarrollo de un método común de dominio público y, preferiblemente, respaldado por un estándar internacional. Así, en junio de 1991, el grupo de Estándares Internacionales para la Ingeniería del Software aprobó un período de estudio con base de ImprovelT, para investigar la necesidad y las características de un estándar de evaluación del proceso software. El informe del estudio indicaba que existía un consenso internacional sobre la necesidad y los requisitos de un estándar de evaluación del proceso software. En junio de 1992 se estableció un nuevo grupo de trabajo para desarrollar este estándar internacional que, en enero de 1993, lanzó el proyecto denominado Mejora del Proceso Software y Determinación de la Capacidad para desarrollar un estándar internacional de evaluación y mejora del proceso software. El proyecto toma como base las mejores características de los siguientes métodos y/o modelos de evaluación: CMM, TRILLIUM, Software Technology Diagnostic (STD) y Bootstrap. El conjunto de los borradores de SPICE se publicaron como informes técnicos durante 1995; posteriormente le ha seguido un período de prueba que aún no ha finalizado. De hecho, se dice que actualmente se encuentra en fase de pruebas y sólo en el entorno de grandes empresas, sin existir todavía experimentación comercial con el método. Finalmente, en 1998 se convirtió en el estándar internacional ISO/IEC 15504 versión 3.3 de evaluación del proceso software.


Actualmente, las dos líneas, CMM e ISO 15504, han confluido en lo que se ha denominado CMMI (capability Maturity Model integration). CMMI contempla ambas visiones mediante su representación continua (perspectiva ISO) [CMMI, 2001a] y por etapas (perspectiva CMM) [CMMI, 2001b]. También se incluye un método de evaluación denominado SCAMPI [SCAMPI, 2001]. Los principales modelos de mejora del proceso software son: 5.4

Modelo IDEAL

Desarrollado por el SEI (Software Engineering Institute) Constituido por bucle continuo de 5 etapas (Initiation, Diagnosing, Estahlishing, Acting and Leveraging). La etapa inicial es el comienzo del programa de mejora. Una vez que se tiene el patrocinio y los recursos adecuados, se evalúa el estado actual de la práctica de software (diagnóstico). Posteriormente, se establecen la estrategia de implementación y los planes de acción para la mejora (establecimiento). Por último, se ejecutan los planes y las mejoras recomendadas (actuación) y se difunden (analizando las lecciones aprendidas y los resultados de la mejora, al mismo tiempo que se revisa la aproximación realizada) para el siguiente ciclo de mejora. 5.5

ISO/IEC TR 1550 Parte 7

Guía para utilización en la mejora del proceso [ISO, l998]. La mejora del proceso software se considera, igualmente, como un proceso continuo, donde una empresa se mueve continuamente alrededor de un ciclo de mejora. 5.6 Modelo de mejora del proceso software desarrollado por ISPI (Institute for Software Process Improvement) A continuación, se describen brevemente cada una de las etapas del modelo de mejora: Compromiso a la mejora del proceso software por parte de la Alta Dirección para que se involucre en el proyecto de mejora, Evaluación del proceso software para determinar cuál es el estado actual del proceso software de la compañía, es decir sus puntos fuertes y débiles, con objeto de determinar los procesos que se van a mejorar, Infraestructura y planes para la mejora del proceso software para crear la estructura necesaria de mejora del proceso, Implantación de la mejora del proceso software para realizar las actividades definidas previamente en el plan. Los dos modelos de proceso utilizados habitualmente en la etapa de evaluación son el Modelo de Madurez de la Capacidad (CMM) y la parte 2 del estándar ISO 15504. Como se ha indicado anteriormente, el modelo de procesos se utiliza en la etapa de evaluación con objeto de conocer cómo está el propio proceso software de la empresa con respecto a dicho modelo.


La etapa de evaluación se puede llevar a cabo desde dos puntos de vista diferentes: Enfoque de evaluación del proceso que es un enfoque colaborativo y su objeto es determinar las fortalezas y debilidades del proceso software de la compañía, y el enfoque de valoración de la capacidad software que se trata más bien de un enfoque auditor y su objeto es identificar qué subcontratistas cualificados podrán llevar a cabo el desarrollo software a contratar. Actualmente, con el nuevo CMMI se utiliza el método SCAMPI como método de evaluación para la mejora del proceso.


CAPITULO 5

MÉTRICAS DE CALIDAD DEL SOFTWARE


INTRODUCCIÓN Los términos de métricas, medición, y medida en muchos de los casos han sido relacionados con los instrumentos utilizados mediante un método específico al acto mecánico de tomar una medición mediante escalas cualitativas o cuantitativas que determinan los valores de esa medición. En general es así, pero los tres conceptos son diferentes, y serán tratados en este capítulo. Pero lo que no se puede admitir es que sea un acto mecánico ya que el proceso de medición involucra muchas actividades, inicia con la selección y definición de la característica que se quiere medir, posteriormente se definirá que métricas es posible usar para la medición, luego se definirá la escala de tipo cuantitativo o cualitativo y el método, y por último se procede a hacer al análisis de cómo se hara la medición. En este capítulo se tratará estos temas tan importantes para el proceso y procedimiento de la evaluación de software, que se convertirán en la clave para realizarla, ya que, de ella depende el éxito o fracaso de la evaluación.


5.1

LECCIÓN 1: CONCEPTOS BÁSICOS DE MÉTRICAS

La palabra métrica, es muy común asociarla con las palabras medición y medida, aunque estas tres son distintas. La medición es el proceso por el cual los números o símbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas. La medida proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto. Métrica se define como una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado o también una medida cuantitativa del grado en que el sistema, componente o proceso posee un atributo dado. Un Indicador es la métrica o una combinación de métricas que proporcionan una visión profunda del proceso del software, del proyecto software o del producto en sí. Un indicador proporciona una visión profunda que permite ajustar el producto, el proyecto o el proceso. El objetivo principal de los indicadores de proceso es evaluar las condiciones de funcionamiento de un proceso y poder tener una visión de la eficacia de un proceso existente. Durante un tiempo considerable se recopilan las métricas de todos los proyectos y se proporcionan indicadores para obtener mejoras en el software. Los métodos de medición o cálculo son unas secuencias lógicas de operaciones y potenciales heurísticas, expresadas de forma genérica, que permite la realización de una descripción de actividad. El tipo de método de medición va a depender de la naturaleza de las operaciones utilizadas para cuantificar el atributo. Pueden distinguirse dos tipos: Subjetivo, cuando la cuantificación supone un juicio realizado por un ser humano, y Objetivo, cuando la cuantificación está basada en métodos numéricos. Una escala es un conjunto de valores con propiedades definidas. Las escalas pueden ser escalas numéricas (Continua o Discreta) o escala Categórica. Los tipos de escala pueden ser: Nominal, Ordinal, Intervalo, entre otras. En este sentido la métrica es la correspondencia de un dominio real o empírico a un mundo formal, matemático. La medida incluye al valor numérico o nominal asignado al atributo de un ente por medio de dicha correspondencia. Las métricas peden ser de tipo directo cuando no dependen de ninguna métrica de otro atributo e indirecta cuando se deriva de una o más métricas de otros atributos. Algunos ejemplos de Métricas Directas son: Longitud del Texto del Cuerpo de una Página (medido por cantidad de palabras), Cantidad de Enlaces Rotos Internos (medidos por la presencia de errores del tipo 404), Cantidad de Imágenes con Texto Alternativo (medido por la presencia de la etiqueta ALT o con texto no nulo, en cada una de las imágenes vinculadas a las páginas de un sitio Web). Algunos ejemplos de Métricas Indirectas son: Porcentaje de Enlaces Rotos de un Sitio, Porcentaje de Presencia de la propiedad ALT.


Ahora se estudirá brevemente el amplio campo de las métricas del software, ya que es la técnica que junto a revisiones, pruebas y gestión de configuración constituye el conjunto principal de medios operativos para el aseguramiento de la calidad en el proyecto. En general, para la evaluación de la calidad es más habitual centrarse en medidas del producto que en medidas de procesos, aunque estas últimas pueden ser útiles para medir ciertos aspectos como la fiabilidad, se mide el tiempo medio entre fallos de software a lo largo de algún período de prueba, etc. Para mejorar cualquier proceso se debe medir atributos del proceso, definir y desarrollar un juego de métricas para esos atributos, y utilizar las métricas para encontrar indicadores para la estrategia de mejora.

Figura 16: Métricas del Proceso y Mejoras en el Proceso de Software La eficacia de un proceso de software se mide a través de un juego de métricas según los resultados que provienen del proceso. Dentro de estos resultados se debe incluir: Medida de los errores detectados antes de la entrega del software, defectos detectados, productos de trabajo entregados, esfuerzo humano y tiempo consumido y ajuste con la planificación. También se debe incluir métricas para medir las características de tareas específicas de la ingeniería del software, como la medida del tiempo y del esfuerzo para llevar a cabo actividades de protección, actividades genéricas de ingeniería de software. Para una organización es importante estar a gusto con la recopilación y la utilización de métricas de proceso, de éstas se deriva la identificación de


indicadores llevando a un enfoque más riguroso denominado Mejora estadística del proceso de software (MEPS). Este enfoque utiliza el análisis de fallas del software para recopilar información de errores y defectos. Para realizar un análisis de fallas se debe seguir los siguientes pasos: Categorizar por origen de todos los errores y defectos, Registrar el costo de corregir cada error o el del defecto, Contar el número de errores y de defectos de cada categoría, calcular el costo global de errores y defectos de cada categoría, para posteriormente, desarrollar planes para eliminar los errores y defectos más costosos. Para determinar las principales causas que pueden ocasionar defectos en el software y con base en ello extraer los indicadores que permitan a una organización de software modificar su proceso para reducir la frecuencia de errores y defectos se utiliza el diagrama de espina. En el diagrama de espina, la línea central, representa el factor de calidad o el problema en consideración. Las líneas diagonales conectadas a la línea central indican una causa potencial del problema de calidad.

Figura 17: Análisis de Problemas y causas de calidad del software Por ejemplo, en la siguiente tabla se muestra las causas y su origen de fallas en un proyecto de software: Origen de errores o defectos Especificación de requisitos Diseño Código

Causa Lógica Manejo de datos estándares Especificaciones Interfaz de software Interfaz de Hardware Comprobación de errores Interfaz de usuario

Tabla 19: Origen de errores o defectos y causas en un proyecto software

% 20 10.9 6.9 25.5 6.0 7.7 10.9 11.7


Utilizando el diagrama de espina para la identificación de las causas específicas para este problema, sería:

Figura 18: Identificación de causas de errores o defectos en un software Las métricas del Proyecto se utilizan para minimizar la planificación de desarrollo, ya que realizan ajustes y minimizan los retrazos. Además se utilizan para evaluar la calidad de los productos. A medida que mejora la calidad se minimizan los defectos. Las métricas del proyecto de software sugiere que los proyectos deben medir: Las entradas, la dimensión de los recursos que se requieren para realizar el trabajo, las salidas, medidas de las entradas o productos creados durante el proceso de ingeniería de software, y resultados, medidas que indican la efectividad de las entregas. 5.2

LECCIÓN 2: MÉTRICAS DEL SOFTWARE

Las métricas del software se pueden categorizar en: 5.2.1 Medidas Directas: Dentro de estas se pueden incluir: el costo y el esfuerzo aplicado, Las líneas de código producidas (LCD), La velocidad reejecución, El tamaño de la memoria y los defectos informados durante un periodo de tiempo establecido. 5.2.2 Métricas Indirectas: Dentro de estas están la funcionalidad, La calidad, La complejidad, La eficiencia, la Fiabilidad, La facilidad de uso y La facilidad de mantenimiento. 5.2.3 Métricas orientadas al tamaño: Provienen de la normalización de las medidas de calidad y/o productividad considerando el tamaño del software que se haya producido, los datos registrados se muestran en la siguiente tabla:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 92 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Proyecto IRIS

LCD

Esfuerzo

18.200

24

Costo $ 200000

Páginas de documentación 945

Errores 134

Defectos

Personas

86

4

Tabla 20: Tabla de registro de datos de métricas orientadas al tamaño Teniendo en cuenta los datos de la tabla anterior, se puede derivar otras métricas para comparar varios proyectos. Por ejemplo: Errores por KLDC (miles de líneas de código), Defectos por KLDC, Páginas de documentación por KLDC, Errores por persona/mes, LDC por persona/mes, Costo ($) por página de documentación 5.3.4 Métricas orientadas a la función: Las métricas del software orientadas a la función permiten la medida de la funcionalidad de la aplicación. Esta métrica fue propuesta busca identificar los factores críticos que determinan el tamaño del software y por consiguiente, estimar el esfuerzo y el costo para desarrollarlo. De aquí nace la técnica de análisis de puntos de función, que mide una aplicación con base en las funciones que éste realiza por solicitud del usuario final. Los puntos de función se obtienen utilizando una función empírica basado en medidas cuantitativas del dominio de información del software y valoraciones subjetivas de la complejidad del software. Los puntos de función se calculan utilizando la siguiente tabla: Parámetros de medición Número de entradas de usuario Número de salidas de usuario Número de peticiones de usuario Número de archivos Número de interfaces externas

Cuenta X

Factor de ponderación Simple Medio Complejo 3 4 6

=

X

4

5

7

=

X

3

4

6

=

X

7

10

15

=

X

5

7

10

= Costo_total

Tabla 21: Tabla de cálculo de puntos de función Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición apropiada en la tabla. Los valores del ámbito de información están definidos de la siguiente forma:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 93 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Caracteríatica Número de entradas de usuario

Definición Se cuenta cada entrada de usuario que proporcione al software diferentes datos orientados a la aplicación Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto las salidas se refieren a informes, pantallas, mensajes de error

Número de salidas de usuario

Número de peticiones de usuario

Una petición esta definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Se cuenta cada petición por separado Se cuenta cada archivo maestro lógico Se cuentan todas las interfaces legibles por la máquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir información a otro sistema.

Número de archivos Número de interfaces externas

Tabla 22: Características y definición de puntos de función (a) Cuando han sido recogidos los datos anteriores, se asocia el valor de complejidad a cada cuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinación dela complejidad es algo subjetivo. PF = Cuenta_total * [0.65 + 0.01* sumatoria (fi)] PF Cuenta_total fi

Punto de función Es la suma de todas las entradas obtenidas Donde i=1 hasta 14. son los valores de ajuste de la complejidad basados en las respuestas a las cuestiones señaladas de la siguiente tabla: Evaluar cada factor de 0 a 5 0 No influencia Fi : 1 2 3 4 5 6 7 8

1 Incidental

2 Moderado

3 Medio

4 Significativo

5 Esencial

¿Requiere el sistema copias de seguridad y de recuperación fiable? ¿Se requiere comunicación de datos? ¿Existen funciones de procesamiento distribuido? ¿Es crítico el rendimiento? ¿Se jecutará el sistema en un entorno operativo existente y fuertemente utilizado? ¿Requiere el sistema entrada de datos interactivo? ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? ¿Se actualizan los archivos maestros de forma interactiva?

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 94 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ 9 10 11 12 13 14

¿Son complejas las entradas, las salidas, los archivos o las peticiones? ¿Es complejo el procesamiento interno? ¿Se ha diseñado el código para ser reutilizable? ¿Están incluidas en el diseño la conversión y la instalación? ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?

Tabla 23: Características y definición de puntos de función (b) Una vez calculados los puntos de función se usan como medida de la productividad, calidad y otros productos del software. Productividad= PF/persona-mes Calidad= Errores/ PF Costo= Pesos/PF Documentación= Páginas_documentadas/ PF 5.3

LECCION 3: MÉTRICAS DE CALIDAD DEL SOFTWARE

El objetivo de la Ingeniería de Software es desarrollar y producir software de alta calidad y para lograrlo es fundamental aplicar métodos y herramientas efectivos dentro del contexto de un proceso de desarrollo de software. Dentro de las medidas de calidad del software están: 5.3.1 Corrección: Es el grado en el que el software cumple su función, la medida más común es: Defectos por KDLC (miles de líneas de código) 5.3.2 Facilidad de mantenimiento: es la facilidad con la que se puede corregir un programa si se encuentra un error. Se utiliza medidas indirectas como: Tiempo medio de cambio (TCM), que es el tiempo que tarda en: Analizar una petición, Diseñar una modificación, Implementar un cambio o Probar y realizar un cambio. 5.3.3 Integridad: mide la capacidad del software para resistir ataques. Se define como, Integridad= Sumatoria [(1-amenaza)*(1-seguridad)], para ello se debe tener en cuenta los siguientes atributos: Amenaza que es la probabilidad de que un ataque ocurra en un tiempo determinado, y la seguridad que es la probabilidad de que se pueda repeler el ataque de un tipo determinado. 5.3.4 Facilidad de Uso: Mide la amigabilidad del software con el usuario final. Se mide en función de: Habilidad intelectual o física para aprender el sistema, El tiempo requerido para hacer uso eficiente del sistema, Aumento de la productividad y la Valoración subjetiva de la disposición de los usuarios hacia el sistema.


5.3.5 Eficacia de la eliminación de defectos: La eficacia de la eliminación de defectos (EED), es una métrica que permite medir la habilidad de filtrar las actividades de la garantía de calidad y de control, ya que es aplicable a todas las actividades del marco de trabajo del proceso. Se definen de la siguiente forma: EED= E/ (E+ D), Donde E es el número de errores encontrados antes de la entrega del software y D es el número de defectos encontrados después de la entrega. El valor óptimo de EED es 1, que significa que no se han encontrado defectos en el software. 5.4

LECCIÓN 4: MÉTRICAS TÉCNICAS DEL SOFTWARE

Las métricas técnicas para el software proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas. También proporcionan al ingeniero del software descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastróficos. 5.4.1 Factores de calidad de McCall McCall y Cavano definieron un juego de factores de calidad como los primeros pasos hacia el desarrollo de métricas de a calidad del software. Estos factores evalúan el software desde tres puntos de vista distintos: Operación del producto, Revisión del producto y Transición del producto. A continuación se muestran los factores de calidad de McCall, las características asociadas y la definición de cada una de ellas: 1. Operaciones del producto - Características operativas Corrección: ¿Hace lo que se El grado en que una aplicación satisface sus especificaciones le pide? y consigue los objetivos encomendados por el cliente. Fiabilidad: ¿Lo hace de El grado que se puede esperar de una aplicación lleve a cabo forma fiable todo el tiempo? las operaciones especificadas y con a precisión requerida. Eficiencia: ¿Qué recursos La cantidad de recursos hardware y software que necesita hardware y software una aplicación para realizar las operaciones con los tiempos necesito? de respuesta adecuados. Integridad: ¿Puedo controlar El grado con que puede controlarse el acceso al software o a su uso? los datos a personal no autorizado. Facilidad de uso: ¿Es fácil y El esfuerzo requerido para aprender el manejo de una cómodo de aplicación, trabajar con ella, introducir datos y conseguir manejar? resultados 2. Revisión del producto - Capacidad para soportar cambios Facilidad de mantenimiento: El esfuerzo requerido para localizar y reparar errores. ¿Puedo localizar los fallos? Fiexibilidad: ¿Puedo añadir El esfuerzo requerido para modificar una aplicación en nuevas opciones? funcionamiento. Facilidad de prueba: ¿Puedo El esfuerzo requerido para probar una aplicación de forma que probar todas las opciones? cumpla con lo especificado en los requisitos. 3. Transición del producto - Adaptabilidad a nuevos entornos Portabilidad: ¿Podré usarlo El esfuerzo requerido para transferir a aplicación a otro en otra máquina? hardware o sistema operativo. Reusabilidad: ¿Podré utilizar Grado en que partes de una aplicación pueden utilizarse en alguna parte del software en otras aplicaciones

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 96 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ otra aplicación? Interoperabilidad: ¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?

El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos

Tabla 24: Factores de calidad de McCall 5.4.2 Métricas para el esquema de puntuación Las métricas pueden ir en forma de lista de comprobación para evaluar y puntuar atributos específicos del software. La puntución va en una escala del O (bajo) al 10 (alto). Se emplean las siguientes métricas en el esquema de puntuación: Facilidad de auditoría Exactitud Estandarización de comunicaciones Complexión Concisión Consistencia Estandarización de datos Tolerancia al error Eficiencia de ejecución Capacidad de expansión Generalidad Independencia del software Instrumentación Modularidad Operatividad Seguridad Autodocumentación Simplicidad Independencia del sistema software Trazabilidad Formación

La facilidad con la que se puede comprobar el cumplimiento de los estándares. La exactitud de los cálculos y del control. El grado de empleo de estándares de interfaces, protocolos y anchos de banda. El grado con que se ha logrado la implementación total de una función. Lo compacto que es el programa en términos de líneas de código. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software El empleo de estructuras y tipos de datos estándares a lo largo del programa. El daño causado cuando un programa encuentra un error. El rendimiento del funcionamiento de un programa. El grado con que se pueden ampliar el diseño arquitectónico, de datos o procedimental. La amplitud de aplicación potencial de los componentes del programa. El grado con que se desacopla el software del hardware donde opera. El grado con que el programa vigila su propio funcionamiento e identifica los errores que ocurren. La independencia funcional de componentes de programa. La facilidad de operación de programa La disponibilidad de mecanismos que controlan o protegen los programas y tos datos. El grado en que el código fuente proporcionan documentación significativa El grado de facilidad con que se puede entender un programa. El grado de independencia de programa respecto a las características del lenguaje de programación no estándar, características del sistema operativo y otras restricciones. La capacidad de seguir una representación del diseño o un componente real del programa hasta los requisitos El grado en que ayuda el software a manejar el sistema o los nuevos usuarios.

Tabla 25: Métricas para el esquema de puntuación


5.4.3 Métricas del modelo de Calidad FURPS El modelo de MCCall ha servido de base para modelos de calidad posteriores, y este es el caso del modelo FURPS, producto del desarrollo de Hewlett-Packard. En este modelo se desarrollan un conjunto de factores de calidad de software, bajo el acrónimo de FURPS. F Functionality - funcionalidad R Usability – usabilidad – facilidad de uso R Realiability – confiabilidad P Performance – desempeño S supportability-capacidad de soporte La siguiente tabla, presenta la clasificación de los atributos de calidad que se incluyen en el modelo, junto con las características asociadas a cada uno de ellos: Factor de Calidad Funcionalidad Facilidad de uso

Confiabilidad

Rendimiento

Capacidad de Soporte

Atributos • Características y capacidades del programa • Generalidad de las funciones . Seguridad del sistema • Factores humanos • Factores estéticos • Consistencia de la interfaz • Documentación • Frecuencia y severidad de las fallas • Exactitud de las salidas • Tiempo medio de fallos • Capacidad de recuperación ante fallas • Capacidad de predicción • Velocidad del procesamiento • Tiempo de respuesta • Consumo de recursos • Rendimiento efectivo total • Eficacia • Extensibilidad • Adaptabilidad • Capacidad de pruebas • Capacidad de confl9uración • Compatibilidad • Requisitos de instalación

Tabla 26: Métricas del modelo de Calidad FURPS El modelo FURPS incluye, además de los factores de calidad y los atributos, restricciones de diseño y requerimientos de implementación, físicos y de interfaz. Las restricciones de diseño especifican o restringen el diseño del sistema. Los requerimientos de implementación especifican o restringen la codíficacion o construcción de un sistema. Por su parte, los requerimientos de interfaz especifican el comportamiento de los elementos externos con los que el sistema


debe interactuar. Por último, los requerimientos físicos especifican ciertas propiedades que el sistema debe poseer, en términos de materiales, forma, peso, tamaño. 5.4.4 Factores de calidad ISO 9126 El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software. Este estándar es una simplificación del Modelo de McCalI, e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software. El estándar provee una descomposición de las características en subcaracterísticas, que se muestran en la siguiente tabla: Característica Funcionalidad

Confiabilidad Usabilidad Eficiencia Mantenibilidad

Portabilidad

Subcaracterística • Adecuación • Exactitud • Interoperabilidad • Seguridad • Madurez • Tolerancia a fallas • Recuperabilad • Entendibilidad • Capacidad de aprendizaje • Operabilidad • Comportamiento en tiempo • Comportamiento de recursos • Analizabilidad • Modificabilidad • Estabilidad • Capacidad de pruebas • Adaptabilidad • Instalabilidad •.Reemplazabilidad

Tabla 27: Características y Subcaracterísticas modelo ISO/IEC 9126 Las métricas ISO / IEC 9126 no son necesariamente usados para mediciones directas, pero proveen una valiosa base para medidas indirectas, y una excelente lista para determinar la calidad de un sistema. 5.5 LECCIÓN 5: ESTRUCTURA PARA LAS MÉTRICAS TÉCNICAS DEL SOFTWARE Es importante establecer una estructura fundamental y un conjunto de principios básicos para la medición de métricas técnicas para el software. Los principios básicos de la medición, sugeridos por Roche, pueden caracterizarse mediante cinco actividades:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 99 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Actividad Formulación Colección Análisis Interpretación Realimentación

Definición Obtención de medidas y métricas del software apropiadas para la representación de software Mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Cálculo de las métricas y aplicación de herramientas matemáticas. Evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. Recomendaciones obtenidas de a interpretación de métricas técnicas transmiitidas al equipo software.

Tabla 28: Actividades y definición de Métricas Técnicas de Software Los principios que se pueden asociar con la formulación de las métricas técnicas son los siguientes: Los objetivos de la medición que deben establecerse antes de empezar la recolección de datos, Todas las técnicas sobre métricas deben definirse sin ambigüedades, Las métricas deberían obtenerse basándose en una teoría válida para el dominio de aplicación, Hay que hacer las métricas a medida para acomodar mejor los productos y procesos específicos. Roche sugiere los siguientes principios para la recolección y análisis de datos: Siempre que sea posible, la recogida de datos y el análisis debe automatizarse, Se deben aplicar técnicas estadísticas válidas para establecer las relaciones entre os atributos internos del producto y las características externas de la calidad, Se deben establecer directrices de interpretación y recomendaciones para todas las métricas. La métrica obtenida y las medidas que conducen a ello deben tener las siguientes características: Simples y fáciles de calcular, Empírica e intuitivamente persuasivas, Consistentes y objetivas, Consistentes en el empleo de unidades y tamaños, Independiente del lenguaje de programación, Un mecanismo eficaz para la realimentación de calidad. 5.5.1 Métricas del Modelo de Análisis En esta fase, las métricas técnicas proporcionan una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el “tamaño” del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados. Dentro de las métricas del modelo de análisis tenemos: 5.5.1.1 Métricas basadas en la Función: La métrica del punto de función se utiliza como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de a métrica de punto de función: Número de entradas


del usuario, Número de salidas del usuario, Número de consultas del usuario, Número de archivos, Número de interfaces externas. 5.5.1.2 Métrica Bang Puede aplicarse para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo del análisis. Para calcular la métrica bang, el desarrollador de software evalúa primero un conjunto de primitivas. Las primitivas se determinan evaluando el modelo de análisis y desarrollando cuentas para los siguientes elementos de la tabla: Primitivas funcionales (Pfu)

Transformaciones que aparecen en el nivel inferior de un diagrama de flujo de datos. Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos no compuestos y aparecen en el diccionario de datos. Objetos (OB) Objetos de datos Relaciones (RE) Las conexiones entre objetos de datos. Estados (ES) El número de estados observables por el usuario en el diagrama de transición de estados. Transiciones (TR El número de transacciones de estado en el diagrama de transición de estado. Además, se determinan medidas adicionales para: Primitivas modificadas de Funciones que caen fuera del limite del sistema y que deben función manual (PMFu) modificarse para acomodarse al nuevo sistema. Elementos de datos de Aquellos elementos de datos que se introducen en el sistema. entrada (EDE) Elementos de datos de Aquellos elementos de datos que se sacan en el Sistema. salida (EDS) Elementos de datos Aquellos elementos de datos que son retenidos (almacenados) retenidos (EDR) por el sistema. Muestras (tokens) de datos Las muestras de datos que existen en el limite de la i-ésima (TCi) primitiva funcional (evaluada para cada primitiva). Conexiones de relación Las relaciones que conectan el i-ésimo objeto en el modelo de (Rei) datos con otros objetos.

Tabla 29: Métrica Bang 5.5.2 Métricas del Modelo de Diseño Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la eficiencia de los módulos. Estas métricas son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema. Card y Glass definen las siguientes tres medidas de complejidad: La complejidad estructural, S(i), de un módulo i se define de a siguiente manera: S(i)=f2out(i) Donde fout(i) es la expansión del módulo i. La expansión indica el número de módulos que son invocados directamente por el módulo i.


La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos C(i)= S(i) + D(i). La complejidad de datos, D(i), proporciona una indicación de la complejidad en la interfaz interna de un módulo y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el número de variables de entrada y salida que entran y salen del módulo i. Fenton sugiere varias métricas de morfología simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas. Las métricas a aplicar son: • Tamaño= n + a. Donde n es el número de nodos (módulos) y a es el número de arcos (líneas de control). Para la arquitectura mostrada se tiene tamaño= 17+18=35. • Profundidad= camino más largo desde el nodo raíz a un nodo hoja. Para el ejemplo Profundidad= 4 • Amplitud=número máximo de nados de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6 • Relación arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicación sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06 5.5.3 Métricas del Codigo Fuente Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño. Estas medidas son: n1: número de operadores diferentes que aparecen en el programa. N2: número de operandos diferentes que aparecen en el programa. N1: número total de veces que aparece el operador. N2: número total de veces que aparecen el operando. Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras características tales como el esfuerzo de desarrollo, tiempo de desarrollo e incluso el número esperado de fallos en el software. Halstead propone las siguientes métricas: • Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2 • Volumen de programa se define como: V = N n1 log2 (n1 + n2).


Tomando en cuenta que V variará con el lenguaje de programación y representa el volumen de información (en bits) necesarios para especificar un programa. 5.5.4 Métricas para Pruebas Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de as pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba. El esfuerzo de las pruebas también se puede estimar utilizando métricas obtenidas de las medidas de Halstead. Usando la definición del volumen de un programa, y, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como: NP = 1/[(n1/2) x (N2/n2)) (Ec. 1) e = V/NP (Ec. 2) El porcentaje del esfuerzo global de pruebas a asignar a un módulo k se puede estimar utilizando la siguiente relación: Porcentaje de esfuerzo de pruebas (k) = e(k)/ Se(i) (Ec. 3) Donde e(k) se calcula para el módulo k utilizando las ecuaciones (Ec. 1) y (Ec. 2) la suma en el denominador de la ecuación (Ec. 3) es la suma del esfuerzo de la ciencia del software a o largo de todos los módulos del sistema. A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas: Medida de amplitud de las pruebas. Profundidad de las pruebas

Perfiles de fallos

Proporciona una indicación de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. e puede calcular una estimación razonablemente exacta del número de caminos básicos sumando a complejidad ciclomática de todos los módulos del programa. e emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístco de errores.

Tabla 30: medidas de Compleción de pruebas 5.5.5 Métricas del Mantenimiento Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente. El estándar IEEE 982.1-1988


sugiere el índice de madurez del software (IM ) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IM se determina a siguiente información: MT= Número de módulos en la versión Actual Fc = Número de módulos en la versión actual que se han cambiado Fa= Número de módulos en a versión actual que se han añadido Fe= Número de módulos en la versión actual que se han eliminado El índice de madurez del software se calcula de la siguiente manera; IM = [MT - (Fc + Fa + Fe)]I/MT A medida que el IM se aproxima a 1 el producto se empieza a estabilizar. El IM puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software.


CAPITULO 6

PRUEBAS DEL SOFTWARE


INTRODUCCIÓN Una de las características típicas del desarrollo de software basado en el ciclo de vida es la realización de controles periódicos, norrnalmente coincidiendo con la terminación de cada una de las etapas, del producto o los documentos. Estos controles pretenden una evaluación de la calidad de los productos generados para poder detectar posibles defectos cuanto antes. in embargo, todo sistema o aplicación, independientemente de estas revisiones, debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminación del código del software, se denominan habitualmente pruebas. Cuando se desarrolla software, dentro del ciclo de vida se ha establecido formalmente que la prueba es una actividad fundamental dentro de cada una de las etapas del proceso de desarrollo de software. A partir de la prueba se puede determinar la calidad de los productos implementados. Desde hace mucho tiempo, la prueba ha sido un tema muy importante en la ingeniería de software, a partir de cual se han generado un gran número de trabajos. En este capítulo se presenta una revisión técnica sobre la prueba de software, abordándose fundamentalmente los enfoques de prueba propuestos para probar software construido bajo un enfoque funcional, orientado a objetos y basado en componentes. Las pruebas constituyen un método más para poder verificar y validar el software cuando ya está en forma de código ejecutable. La verificación es el proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos satisfacen las condiciones impuestas al comienzo de dicha fase, y la validación hace referencia al proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. Así, validar una aplicación implica comprobar si satisface los requisitos marcados por el usuario.


6.1

LECCIÓN 1: LA PRUEBA DEL SOFTWARE

Indiscutiblemente la prueba es una actividad fundamental en los procesos de desarrollo de software. La prueba de software permite al desarrollador determinar si el producto generado satisface las especificaciones que han sido establecidas en el diseño. Así mismo, una prueba de software permite detectar la presencia de errores que pudieran generar salidas o comportamientos inapropiados durante su ejecución. De acuerdo a la IEEE, el concepto de prueba se define como una actividad en la cual un sistema o componente es ejecutado bajo condiciones específicas, se observan o almacenan los resultados y se realiza una evaluación de algún aspecto del sistema o componente. Para Myers, probar es el proceso de ejecutar un programa con el fin de encontrar errores. Cuando se habla de condiciones específicas, se puede suponer la presencia de una especie de ambiente de operación de la prueba, para el cual deben existir determinados valores para las entradas y las salidas, así como también ciertas condiciones que delimitan a dicho ambiente de operación, formalmente esto es conocido como Caso de Prueba. El objetivo de las pruebas es la detección de errores o fallas y defectos en el software. Se trata de una actividad a posteriori, para la detección de problemas en el software, y la posterior rectificación. La mayoría de los estudios revelan que los mejores programadores incluyen una cierta media de defectos por cada 1.000 líneas de código. Los defectos no son siempre el resultado de la negligencia, sino que en su aparición influyen múltiples factores como la mala comunicación entre los miembros del equipo que da lugar a malentendidos en los requisitos pedidos. Por todo ello, el descubrimiento de un defecto significa un éxito para la mejora de la calidad del software. Las recomendaciones de G. J. Myers MYERS para las pruebas son las siguientes: 1. Cada caso de prueba debe definir el resultado de salida esperado. Este resultado esperado es el que se compara con el realmente obtenido de la ejecución en la prueba. Las discrepancias entre ambos se consideran síntomas de un posible defecto en el software. 2. El programador debe evitar probar sus propios programas porque desea demostrar que funcionan sin problemas. Lo ideal sería que probara el software el peor enemigo de quien lo ha construido, ya que así se aseguraría una búsqueda implacable de cualquier error cometido. 3. Se debe inspeccionar a conciencia el resultado de cada prueba para descubrir posibles síntomas de defectos. Lamentablemente es frecuente pasar por alto síntomas bastante claros. Esto invalida todo el esfuerzo realizado en la planificación, diseño y ejecución de pruebas.


4. Al generar casos de prueba, se deben incluir datos de entrada válidos y esperados, asi como, datos no validos e inesperados. 5. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace lo que debe, y Probar si el software hace lo que no debe, es decir, si provoca efectos secundarios adversos. 6. Se deben evitar los casos no documentados ni diseñados con cuidado ya que suele ser necesario probar una y otra vez el software hasta que queda libre de defectos. No documentar o guardar los casos significa repetir constantemente el diseño de casos de prueba. 7. No deben hacerse planes de prueba suponiendo que no hay defectos en los programas y dedicando pocos recursos a las pruebas. Hay que asumir que siempre hay defectos y hay que detectarlos. Las estadísticas confirman cerca del 40% del esfuerzo de desarrollo se consume en pruebas y depuración. 8. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto. 9. Las pruebas son una tarea más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria. No existen técnicas rutinarias para el diseño de pruebas y hay que recurrir al ingenio para alcanzar un buen nivel de detección de defectos con los recursos disponibles. La filosofía más adecuada para las pruebas consiste en planificarlas y diseñarlas de forma sistemática para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y esfuerzo. Un buen caso de prueba es aquel que tiene una gran probabilidad de encontrar un defecto no descubierto aún, ya que el éxito de una prueba consiste en detectar un defecto no encontrado antes. La prueba de software se realiza con el propósito de encontrar algo que difiera a las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados. En la siguiente tabla se muestran los objetivos, los principios, las características y los atributos principales que deben tener las pruebas: Objetivos pruebas

de

las

Principios Pruebas

de

las

La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si se descubre un error. Hacer un seguimiento de las pruebas hasta los requisitos del cliente Plantear y diseñar las pruebas antes de generar ningún código El 80% de todos los errores se centran en solo en el 20% de los


Características de un software fácil de probar

Atributos de buena prueba

una

módulos Empezar las pruebas en módulos individuales y avanzar hasta probar el sistema entero. No son posibles las pruebas exhaustivas Deben realizarse por un equipo independiente al equipo de desarrollo Operatividad Objetividad Controlabilidad Capacidad de descomposición Simplicidad Estabilidad Facilidad de comprensión Más alta probabilidad de encontrar un error. No debe ser redundante No debería ser ni demasiado sencilla ni demasiado compleja

Tabla 31: Objetivos, Principios, y Características de los Atributos de la Prueba 6.2

LECCIÓN 2: TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

El objetivo de las técnicas de diseño de casos de prueba es el de conseguir una confianza aceptable en que se detectarán los defectos existentes sin consumir una cantidad excesiva de recursos. Toda la disciplina de pruebas debe moverse en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. La idea fundamental para el diseño de casos de prueba consiste en la ellección de algunas posibilidades de funcionamiento del software que por sus características, se consideren representativas del resto. Así si no se detectan defectos en el software al ejecutar dichos casos, se puede tener un cierto nivel de confianza en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una elección puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. 6.2.1 Pruebas de caja blanca Las pruebas de caja blanca enfocan su atención a los detalles procedimentales del software, por ello la implementación de estas pruebas depende fuertemente de la disponibilidad de código fuente. Este tipo de pruebas, permiten generar casos para ejercitar y validar los caminos de cada módulo, las condiciones lógicas, los bucles y sus límites, así como también para las estructuras de datos. Las pruebas inician con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas. Este método analiza la estructura lógica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las


proposiciones case, las cláusulas de cada proposición if y la condición de terminación de cada ciclo.

Figura 19: Prueba de Caja Blanca En un programa complejo este método es impráctico, pero en un módulo pequeño constituye un excelente medio de prueba y depuración. En una prueba que se vale del método de la caja blanca, se tornan patentes las ventajas de un diseño de programa modular. Un buen criterio de prueba para proyectos extensos consiste en aplicar los métodos a cada módulo pequeño conforme se escriba; luego se usan esos datos en las secciones más amplias del programa una vez terminadas. Las pruebas de caja blanca también son conocidas como pruebas de caja de cristal o pruebas estructurales. Algunas de las pruebas más significativas dentro de este enfoque son mostradas en la siguiente tabla: Prueba Prueba de caminos

Prueba de condiciones Prueba de ciclos Prueba de definición de datos

Definición En este tipo de prueba se realiza un análisis sobre una representación gráfica de un programa denominada grafo de control. En este grafo, los nodos representan bloques de instrucciones de un programa y los flujos de ejecución para dichas instrucciones se representan por medio de aristas. A partir de este grafo, se puede identificar un conjunto básico de caminos de ejecución, sobre el cual se pueden realizar pruebas con el propósito de ejercitar el flujo de ejecución de los caminos en una unidad. Basándose en un grafo de control, pueden generarse casos de prueba para elementos individuales de expresiones lógicas. De esta forma se pretende probar cada condición con todas sus posibles alternativas. A partir del grafo de control, pueden generarse casos de prueba para las iteraciones definidas en los programas con el propósito de verificar si se realizan de forma correcta. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definición de los datos utilizados en el software. Para ello se realiza un análisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecución.

Tabla 32: Pruebas de Caja Blanca


6.2.2 Pruebas de caja negra Estas son conocidas como pruebas funcionales o pruebas de comportamiento, concentran la atención en generar casos de prueba que permitan ejercitar los requisitos funcionales de un programa. A diferencia de las pruebas de caja blanca, que se basan en la lógica interna del software, este tipo de pruebas se concentran en su funcionalidad, por lo que mucho del trabajo se realiza interactuando con la interfaz del software. Los casos de prueba generados en este enfoque, se diseñan a partir de valores entrada y salida. De esta forma, se puede determinar la validez de una salida para un conjunto de entradas proporcionadas. Los datos de prueba se escogerán atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. Los criterios mínimos que guiarán al escoger los datos de prueba: Valores Fáciles: El programa se depurará con datos de fácil comprobabilidad. Valores típicos realistas: Se ensayará un programa con datos seleccionados para que representen como se aplicará. Los Datos deben ser sencillos, de modo que los resultados sean verificables en forma manual. Valores extremos o Valores ilegales: Cuando en un programa entra basura, su salida habrá de ser un mensaje de error adecuado. Es preferible que el programa ofrezca indicación de errores en la entrada y que realice cálculos que sigan siendo factibles luego de desechar la entrada equivocada.

Figura 20: Prueba de Caja Negra Con la aplicación de pruebas de caja negra se permite detectar errores como funciones incorrectas o ausentes, errores en estructuras de datos, errores de rendimiento, errores de interfaz, así como errores de inicialización y terminación. Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y dicen algo sobre la presencia o


ausencia de errores. Algunas de las pruebas más conocidas en este contexto se muestran en la siguiente tabla: Prueba Partición equivalente

Análisis de los valores límite

Pruebas según la experiencia (error guessing) Tablas de decisión

Definición La idea de esta técnica, es en dividir los valores válidos y no válidos para entradas y salidas en un número reducido de particiones de forma que, el comportamiento del software sea el mismo para cualquier valor contenido en una partición particular. El propósito principal de una partición es reducir la cantidad de casos de prueba generados en el proceso. La generación de casos de prueba en esta técnica, se enfoca en los valores limites, esto bajo la consideración de que existe una tendencia a fallar precisamente cuando el software trabaja con valores extremos de la variable de entrada. Generalmente los valores establecidos para generar los casos de prueba son el mínimo, valores un poco arriba del mínimo, valor máximo y valores un poco arriba del máximo. Este tipo de prueba la generación de casos se realiza a partir de la intuición y la experiencia. La idea básica es redactar una lista de las posibles fallas o de las posibles situaciones en las cuales suele ocurrir algún problema y así desarrollar casos de prueba basados en la información contenida en estas listas. Este tipo de prueba permite describir el comportamiento de un programa a partir de un conjunto de acciones que este realiza cuando se opera bajo determinadas condiciones. En este enfoque, las condiciones pueden ser interpretadas como entradas de un programa y las acciones como las salidas producidas. Para ello se pueden utilizar conectores lógicos y (and), o (or) y no (not). Al involucrar aspectos de lógica, se dice que este tipo de prueba se hace más rigurosa, que permite además transformar una especificación en lenguaje natural en una especificación más formal.

Tabla 33: Pruebas de Caja Negra A continuación se presentan las distintas técnicas de diseño de casos de caja negra: 6.2.2.1 Particiones o clases de equivalencia: Utiliza las cualidades que definen un buen caso de prueba de la siguiente manera: Cada caso debe cubrir el máximo número de entradas, Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia donde la prueba de un valor representativo de una clase permite suponer que el resultado obtenido será el mismo que el obtenido probando cualquier otro valor de la clase. El método de diseño de casos consiste en la identificación de clases de equivalencia y la creación de los casos de prueba corespondientes. Para identificar las posibles clases de equivalencia de un programa a partir de su especificación deben seguirse los siguientes pasos: primero, la identificación de Ia condiciones de entradas al programa, Segundo, a partir de ellas, se identifican clases de equivalencia que pueden ser de datos válidos o de datos no válidos o erróneos.


La identificación de las clases se realiza basándose en el principio de igualdad de tratamiento, donde todos los valores de la clase deben ser tratados de la misma manera por el programa. Existen algunas reglas que ayudan a identificar clases: • Si se especifica un rango de valores para los datos de entrada (por ejemplo, “el número estará comprendido entre 1 y 49”), se creará una clase válida (1>= número <= 49) y dos clases no válidas (número < 1 y número > 49). • Si se especifica un número de valores (por ejemplo. “se pueden registrar de uno a tres propietarios de un piso’’), se creará una clase válida (1<= propietarios >=3) y dos no válidas (propietarios< 1 y propietarios>3). • Una situación del tipo booleana (por ejemplo, “el primer carácter debe ser una letra”), se identifican una clase válida (es una letra) y una no válida (no es una letra). • Si se específica un conjunto de valores admitidos (por ejemplo, “pueden registrarse tres tipos de inmuebles: Casas, apartamentos y locales comerciales) y se sabe que eI programa trata de forma diferente cada uno de ellos, se identifica una clase válida por cada valor (en este caso son tres: Casas, apartamentos y locales comerciales) y una no válida (cualquier otro caso: por ejemplo, lote o finca). • En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, debe dividirse en clases menores. La aplicación de estas reglas para la derivación de clases de equivalencia permite desarrolla los casos de prueba para cada elemento de datos del dominio de entrada. El último paso del método es el uso de las clases de equivalencia para identificar los casos de prueba correspondientes. Este proceso consta de las siguientes fases: Fase 1, la asignación de un número único a cada clase de equivalencia. Fase 2, hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas, no incorporadas, como sea posible. Fase 3, hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para una única clase no válida sin cubrir. 6.2.2.2 Análisis de Valores Límite (AVL): Mediante la experiencia, se ha podido constatar que los casos de prueba que exploran las condiciones límite de un programa producen un mejor resultado pura la detección de defectos, es decir, es más probable que los defectos del software se acumulen en estas condiciones. Se puede definir las condiciones límite como las situaciones que se hallan directamente arriba, abajo y en los márgenes de las clases de equivalencia.


El análisis de valores límite es un técnica de diseño de casos que complementa a la de particiones de equivalencia. Aunque parezca que el AVL es simple de usar, su aplicación tiene múltiples matices que requieren un gran cuidado a la hora de diseñar las pruebas. Las reglas para identificar clases son las siguientes: • Si una condición de entrada especifica un rango de valores (“-1.0 <= valor <= 1.0”) se deben generar casos para los extremos del rango (-1.0 y +1.0) y casos no válidos para situaciones justo más allá de los extremos (-1.001 y +1.001, en el caso que se admitan tres decimales). • Si la condición de entrada especifica un número de valores (“el archivo de entrada tendrá de 1 a 255 registros”), hay que escribir casos para Ios números máximo, mínimo, uno más del máximo y uno menos del mínimo de valores (0, 1,255 y 256 registros). • Usar la regla 1 para la condición de salida (“el descuento máximo aplicable en compra al contado será el 50%, el mínimo será el 6%”). Se escribirán casos para intentar obtener descuentos de 5.99%, 6%, 50% y 50.01%. • Usar la regla 2 para cada condición de salida (‘‘el programa puede mostrar de 1 a 4 listados). Se escrihen casos para intentar generar 0, 1, 4 y 5 listados. • Si la entrada o la salida de un programa es un conjunto ordenado, los casos deben concentrarse en el primero y en el último elemento. Es recomendable utilizar el ingenio para considerar todos los aspectos y matices, a veces sutiles, para la aplicación del AVL. 6.2.3 Conjetura de errores Esta técnica consiste en enumerar una lista de errores posibles que pueden cometer los desarrolladores o de situaciones propensas a ciertos errores. Después se generan casos de prueba en base a dicha lista que suelen corresponder con defectos que aparecen comúnmente y no con aspectos funcionales. No existen directrices eficaces que puedan ayudar a generar este tipo de casos, lo único que se puede hacer es presentar algunos ejemplos que reflejan esta técnica. Algunos valores a tener en cuenta para los casos especiales son los siguientes: • El valor 0 es una situación propensa a error tanto en la salida como en la entrada. • En situaciones en las que se introduce un número variable de valores, conviene centrarse en el caso de no introducir ningún valor y el de un solo valor. También puede ser interesante el de todos los valores iguales.


• es recomendable suponer que el programador haya podido malinterpretar algo en la especificación. • También interesa imaginar lo que el usuario puede introducir como entrada a un programa. Se dice que se debe prever toda clase de acciones de un usuario como si fuera a sabotear el programa. 6.2.4 Pruebas Aleatorias En las pruebas aleatorias se simula la entrada habitual del programa creando datos para introducir en él que sigan la secuencia y la frecuencia con las que podrían aparecer en la práctica diaria, de forma contínua, sin descanso. Esto implica usar herramientas denominadas generadores de pruebas a las que se alimenta con una descripción de datos y secuencias de entradas posibles así como una estimación de probabilidad de ocurrir cada una de ellas en el uso real. Si el proceso de generación de pruebas se ha realizado correctamente, se crearán todas las posibles entradas del programa en todas las combinaciones posibles, aunque no sea necesario hacer esto para una prueba adecuada. También se puede conseguir, indicando la distribución estadística que siguen, que la frecuencia de entrada para orientar correctamente nuestras pruebas hacia aquello que es más probable que suceda en la práctica real. 6.3 LECCIÓN 3: ESTRATEGIAS DE APLICACIÓN DE PRUEBAS DEL SOFTWARE Una estrategia de prueba integra las técnicas de diseño de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construcción del software. Una estrategia de prueba de software proporciona una guía para los desarrolladores del software, para la organización de control de calidad y para el cliente. Por tanto una estrategia de software debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de pruebas y la agrupación y evaluación de los datos resultantes. 6.3.1 Prueba de unidad La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software. Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de un módulo. La complejidad relativa de las pruebas y errores descubiertos se encuentra limitada por los lineamientos establecidos por la prueba de software. Se prueba la Interfaz del módulo para asegurar que la información fluye en forma adecuada hacia y desde la unidad del programa que está siendo probada. Se analizan las estructuras de datos para asegurar que los datos mantienen su integridad temporal durante todos los pasos de ejecución del algoritmo. Se prueba las condiciones límite para asegurar que el módulo funciona correctamente dentro


de los límites establecidos por el procesamiento, se activan los caminos básicos de la estructura de control con el fin de asegurar de que las sentencias del módulo se ejecutan por lo menos una sola vez, y finalmente, se prueban todos los caminos de manejo de errores. Myers, propone una lista de comprobaciones para la prueba de interfaces que se muestra en el siguiente cuadro: lista de comprobaciones para la prueba de interfaces de un módulo

Cuando un módulo tenga operaciones básicas de Entrada/Salida externa, se deben llevar a cabo pruebas adicionales

¿Es igual el número de parámetros de entrada al número de argumentos? ¿Coinciden las características (atributos) de los parámetros con los argumentos? ¿Coinciden el sistema de unidades de los parámetros con el de los argumentos? ¿Son correctos el número, atributos y el orden de los argumentos de las funciones incorporadas? ¿Existen referencias o parámetros que no estén asociados con el punto de entrada actual? ¿Entran sólo argumentos alterados? ¿Son consistentes las definiciones de variables globales entre módulos? ¿Se pasan las restricciones como argumentos? ¿Son correctos los atributos de los archivos? ¿Son correctas las sentencias de apertura? ¿Coinciden las especificaciones de formato con las sentencias de Entrada/Salida? ¿Coincide el tamaño del buffer con el tamaño del registro? ¿Se abren los archivos antes de usarlos? ¿Se tienen en cuenta las condiciones de fin de archivo? ¿Se manejan errores de Entrada/Salida? ¿Hay algún error textual en la información de salida?

Tabla 34: Lista de comprobaciones para la prueba de interfaces Se deben diseñar casos de prueba para descubrir errores tales como: Tipificación impropia o inconsistente, Inicialización o valores implícitos erróneos, Nombres de variables incorrectos, Tipos de datos inconsistentes, Desbordamiento o errores en el direccionamiento de memoria. Además se deben diseñar casos de prueba para detectar errores causados por cálculos incorrectos o flujos de control inapropiados. Entre los errores más comunes en los cálculos están: Procedencia aritmética incorrecta mal aplicada, Operaciones de modo mixto, Inicializaciones incorrectas, Falta de precisión, Representación incorrecta de una expresión. Los casos de prueba deben descubrir errores como: Comparaciones entre tipos de datos distintos, Operadores lógicos o de procedencia incorrecta, Terminación de ciclos inapropiada o inexistente, Falta de salida cuando se encuentra una iteración mal aplicada, Variables internas a un ciclo modificadas en forma inadecuada.


Entre los errores que se deben comprobar están los siguientes: La condición de error hace que intervenga el sistema antes que el mecanismo de errores, Descripción ilegible del error, El error señalado no corresponde con el error encontrado, La descripción del error no proporciona suficiente información para ayudar en la localización de la causa del error. La prueba de los límites es la última etapa de la prueba de unidad y quizá la más importante. El software falla en sus condiciones límite, o sea, que frecuentemente aparece un error cuando se procesa el elemento n-ésimo de un arreglo n-dimensional, cuando se hace la i-ésima repetición de un ciclo de x pasos o cuando se llega a los valores máximo ó mínimo permitidos. Los casos de prueba que ejerciten las estructuras de datos por debajo o encima de los mínimos y máximos permitidos son apropiados para descubrir estos errores. La estrategia de aplicación y la planificación de las pruebas pretenden integrar el diseño de los casos de prueba en una serie de pasos bien coordinados a través de la creación de distintos niveles de prueba, con diferentes objetivos. Además, permite la coordinación del personal de desarrollo, y del cliente, gracias a la definición de los papeles que deben desempeñar cada uno y la forma de llevarlos a cabo. En general, la estrategia de pruebas es la siguiente: Las pruebas comienzan a nivel de módulo, una vez terminadas, progresan hacia la integración del sistema completo y su instalación, y culminan cuando el cliente acepta el producto y se pasa a su explotación inmediata. Esta serie típica de etapas se describe con mayor detalle a continuación: • Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de desarrollo en su entorno. • Con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto. • El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto los requisitos funcionales como los de rendimientos, seguridad, etc. • EI software ya validado se integra con el resto del sistema para probar su funcionamiento conjunto. • Por último, el producto final se pasa a la prueba de aceptación para que el usuario compruebe en su propio entorno de explotación si lo acepta como está o no. 6.3.2 Pruebas de integración Las pruebas de integración están totalmente ligadas a la forma prevista de integrar los distintos componentes del software hasta contar con el producto global


que debe entregarse. Así, las pruebas de integración implican una progresión ordenada de pruebas que parte desde los componentes y que culmina en el sistema completo. Su objetivo fundamental es la prueba de las interfaces entre componentes o módulos. La prueba de Integración es una técnica sistemática para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con lo que dicta el diseño. Una vez que los módulos funcionen por separado y hayan pasado la prueba de unidad es necesario realizar las pruebas para ver cómo funcionan juntos todos los módulos. Normalmente aquí es donde pueden surgir los problemas en la unión de los módulos. Los datos se pueden perder en una interfaz, un módulo puede tener un efecto adverso sobre otro módulo; las subfunciones, cuando se combinan, pueden no producir el objetivo principal deseado, las estructuras de datos globales pueden presentar problemas. Existen 2 tipos de integración, la primera es no incremental en donde se intenta elaborar software en módulos grandes, en otros casos un sólo módulo, pero en ellos es más difícil aislar los errores y cuando alguno de ellos es corregido produce otros errores. El segundo tipo de integración es incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir, es más probable que se puedan probar completamente las interfaces y aplicar un enfoque de prueba sistemático. 6.3.2.1 Integración incremental ascendente: El proceso empieza combinando primero los módulos de más bajo nivel en grupos que realizan alguna subfunción específica, donde se busca reducir el número de pasos de integración. Luego se describe para cada grupo un módulo impulsor o conductor, que es un módulo que permite simular la llamada a los módulos, introducir los datos de prueba a través de los parámetros de llamada y recoger los resultados a través de los de salida. Posteriormente, se prueba cada grupo empleando su impulsor y por último se eliminan los módulos impulsores de cada grupo y se sustituyen por los módulos del nivel superior de la jerarquía. 6.3.2.2 Integración Incremental Descendente: La integración incremental descendente comienza con el módulo de control principal y va incorporando módulos subordinados progresivamente. No existe un procedimiento general para determinar cuál de los módulos subordinados posibles es mejor incorporar primero, es decir, no se puede dar una regla general que permita determinar la secuencia óptima de incorporación de módulos. Hay que estudiar en cada caso cuál es el mejor orden de incorporación para minimizar el esfuerzo o para lograr una mejor organización. La siguiente figura muestra la integración incremental descendente


Figura 21: Integración Incremental Descendente Las etapas fundamentales de la integración descendente son las siguientes: • El módulo raíz es el primero. e escriben módulos ficticios para simular la presencia de los subordinados ausentes que serán llamados por el módulo raíz. • Una vez probado el módulo raíz se sustituye uno de los subordinados ficticios por el módulo correspondiente según el orden elegido. e incorporan ficticios para recoger las llamadas del último incorporado. • e ejecutan las correspondientes pruebas cada vez que se incorpora un módulo nuevo. • Al terminar cada prueba, se sustituye un ficticio por su correspondiente real. 6.3.2.3 Integración no incremental: En este tipo de integración cada módulo requiere de los siguientes elementos para ser probado: • Un módulo impulsor, que transmite o impulsa los datos de prueba al módulo y muestra los resultados de dichos casos de prueba. • Uno o más módulos ficticios que simulan la función de cada módulo subordinado llamado por el módulo que se va a probar. Después de probar cada módulo por separado, se ensamblan todos ellos de una sola vez para formar el programa completo y probarlo en conjunto. La


integración no incremental es el único caso en el que las pruebas de unidad y las de integración están totalmente separadas. 6.3.3 Prueba del sistema La prueba del sistema es el proceso de prueba de un sistema integrado de hardware y software para comprobar si cumple los requisitos especificados, es decir: Cumplimiento de todos los requisitos funcionales, considerando el producto software fin al al completo, en un entorno de sistema, El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador, Adecuación de la documentación de usuario, Ejecución y rendimiento en condiciones límite y de sobrecarga. Los casos para la prueba del sistema tienen tres fuentes principales para su diseño: Casos basados en los requisitos gracias a técnicas de caja negra aplicadas a las especificaciones, Casos necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de volumen de datos, de límites de procesamiento, etc.), Casos basados en el diseño de alto nivel aplicando técnicas de caja blanca aplicadas a los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo de datos). 6.3.4 Prueba de aceptación El objetivo de esta prueba es comprobar si el producto está listo para ser implantado para el uso operativo en el entorno del usuario. Si la prueba del sistema determinó la capacidad real del sistema y permitió a la organización de desarrollo tener confianza en que estaba listo para su funcionamiento, la prueba de aceptación es la prueba planificacda y organizada formalmente para determinar si se cumplen los requisitos de aceptación marcados por el cliente. Las caracteristicas principales de esta prueba son las siguientes: Participación del usuario, se enfoca hacia la prueba de los requisitos de usuario especificados, es la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotación. Las recomendaciones generales que pueden darse para la prueba de aceptación son las siguientes: Debe contarse con criterios de aceptación previamente aprobados por el usuario, No hay que olvidar validar también la documentación y los procedimentos de uso, Las pruebas se deben realizar en el entorno en el que se utilizará el sistema. Si se trata de un sistema contratado, la prueba se realiza bajo control de la organización de desarrollo en el entorno real de trabajo ayudando al usuario (prueba alfa). En el caso de productos de interés general, se entregan versiones (versiones beta) a usuarios de confianza, sin control directo, que informarán de la opinión que les merece la aplicación.


6.3.5 Prueba de validación y verificación Al conjunto de actividades que aseguran que el software implementa correctamente una función específica se denomina Verificación. La Validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos y necesidades del cliente. La definición de Verificación y Validación envuelve lo que se conoce como calidad del software, en donde los métodos de análisis, de diseño y de implementación actúan para mejorar la calidad al proporcionar técnicas continuas y resultados predecibles. Las revisiones técnicas formales de inspección ayudan a asegurar la calidad la calidad de los productos, a lo largo del proceso la medición y el control se aplican sobre cada elemento de una configuración del software. La prueba constituye un elemento importante para evaluar la calidad y de descubrir los errores. Cabe mencionar que la prueba no se debe contemplar como una red de seguridad. La aplicación adecuada de los métodos y de las herramientas, las revisiones técnicas formales efectivas y una sólida gestión y medida, conducen a la calidad, que se confirma durante la prueba. Es importante mencionar que la validación y verificación abarcan un amplio rango de la calidad del software que incluyen revisiones técnicas formales, auditorías de configuración y calidad, supervisión de rendimiento, simulación, estudio de viabilidad, revisión de la documentación, revisión de la base de datos, análisis de algoritmos, pruebas de desarrollo, prueba de calificación y prueba de instalación. La prueba de validación se logra cuando las expectativas razonables del cliente se cumplen, en donde incluyen la especificación de requisitos, documentos en donde se describen los atributos del software visibles para el usuario, esta información forma la base del enfoque a la prueba de validación. El procedimiento de prueba estará diseñado para asegurar que se satisfacen los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta y que se alcanzan otros requisitos tales como portabilidad, compatibilidad, recuperación de errores, facilidad de mantenimiento, entre otros. 6.3.6 Prueba del sistema La prueba del sistema tiene la finalidad de verificar que se hayan integrado correctamente cada uno de los elementos del sistema. Comprende las siguientes pruebas: 6.3.6.1 Prueba de Recuperación: La prueba de recuperación es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea


automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación. 6.3.6.2 Prueba de Seguridad: La prueba de seguridad intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado de la prueba desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema, negando así el servicio a otras personas además de producir errores a propósito en el sistema; o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema. 6.3.6.3 Prueba de Resistencia: La prueba de resistencia está diseñada para enfrentar a los programas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se puede tomar en consideración lo siguiente: Diseñar pruebas especiales que generen 10 o más interrupciones por segundo, Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada, Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco, Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en disco. 6.3.7 Depuración La depuración aparece como resultado de una prueba efectiva, es decir, cuando en un caso de prueba se encuentra un error, la depuración es el proceso que resulta en la eliminación de un error. Se debe tomar en cuenta que la depuración no es una técnica de prueba, aunque siempre se da como consecuencia de la prueba. En la siguiente figura se muestra que el proceso de depuración comienza en los casos de prueba, se evalúan los resultados y resulta una falta de correspondencia entre los esperados y los reales, el proceso de depuración intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error.


Figura 22: Depuración de errores La depuración tiene como objetivo principal encontrar y corregir la causa de un error en el software, existen 3 enfoques que se pueden proponer en la depuración: La categoría de depuración "eliminación de causas" se manifiesta mediante inducción o deducción. Los datos relacionados con la ocurrencia del error se organizan para llegar a las posibles causas; se desarrolla una lista de las causas y se llevan a cabo las pruebas para eliminar cada una. La categoría de depuración por "fuerza bruta" es la categoría probablemente la más común y la menos eficiente en el momento de aislar la causa del error del software en donde se confía que en algún lugar de la gran cantidad de información producida nos puede llevar finalmente al éxito, lo más frecuente es que se desperdicie tiempo y esfuerzo. La vuelta atrás es el enfoque más normal para la depuración, que se puede usar con gran éxito en programas pequeños. Partiendo de donde se detecta el error hacia atrás en el código fuente hasta llegar a la posición del error. 6.4

LECCIÓN 4: PRUEBA DE SOFTWARE PARA OBJETOS

El software construido a partir del modelo orientado a objetos también requiere ser sometido a pruebas con el propósito de garantizar su calidad. En términos generales, se puede decir que los dos enfoques más representativos en materia de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a objetos en cierta medida. Sin embargo, existen algunas características


del software orientado a objetos que generan problemas adicionales no cubiertos por las técnicas tradicionales de prueba. La unidad básica para la prueba de software orientado a objetos es la clase. A pesar de ello, cuando se prueba al software orientado a objetos, no es posible realizar una prueba para una clase por sí misma, sino que hay que realizarla para una instancia de ésta, es decir para un objeto. Una característica importante del enfoque orientado a objetos es la encapsulación. Un objeto encapsula su estado y sus funciones asociadas. La abstracción, concepto que define la capacidad de solo destacar las características esenciales de un objeto de tal forma que se puede separar su comportamiento esencial de su implementación, va estrechamente ligada con la encapsulación. El ocultar todos los detalles del objeto que no contribuyen a sus características esenciales, por ejemplo su estructura y la implementación de sus métodos, hace que parte de un objeto sea inaccesible para el mundo. Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlas se requiere monitorear el estado de un objeto. Esto es difícil de realizar con características como la encapsulación y la abstracción, pues la dificultad de visualizar el estado interno del objeto impide consultar información que podría requerirse para el desarrollo de la prueba. La herencia es otra de las características que han venido a facilitar en gran medida el desarrollo de sistemas orientados a objetos. Puede pensarse que esto apoya la prevención de fallas al construir software. Desgraciadamente, se ha comprobado que mediante esta práctica, se tienen muchas posibilidades de cometer errores, porque generalmente los elementos heredados son sometidos a algún tipo de refinamiento o redefinición y en algunos casos eliminación de componentes. Todas estas situaciones hacen pensar que realizar una prueba a los métodos heredados debe ser una regla más que una excepción. La herencia en cierta medida trae como consecuencia reuso, lo que genera una interrogante con respecto a la formulación de las pruebas: las subclases de una clase que ya ha sido probada, deben de ser probadas nuevamente. Si la respuesta es sí, se habla de diferentes niveles de herencia lo que incrementa el número de pruebas a realizar. Otro aspecto que determina la dificultad de las pruebas que se realizan al software orientado a objetos es el polimorfismo. Cada vez que se realiza una instancia diferente de un objeto como producto del polimorfismo en los métodos, se requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un método es una tarea difícil, la complejidad y el tiempo requerido crece considerablemente cuando se tienen que definir todos los posibles errores y obstáculos que pueden presentarse.


En los sistemas orientados a objetos, el flujo de control se lleva a cabo mediante el paso de mensajes entre objetos. Cuando un mensaje es enviado de un objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecute alguna operación para examinar o alterar su estado. El paso de mensajes es un punto fundamental al realizar la prueba. 6.4.1 Métodos de prueba de software orientado a objetos. Muchas de las generalidades de los métodos de prueba tradicionales han sido adaptadas considerando las características del modelo orientado a objetos, con el propósito de que puedan ser aplicables en este nuevo contexto. Actualmente, existen muy pocas investigaciones sobre el estudio de prueba de software orientado a objetos; ya que el área de prueba de software es bastante compleja y dentro de este marco de objetos existe una carencia de métodos robustos para garantizar la realización de las pruebas de forma eficaz. En este panorama se presenta el estado actual en cuanto a prueba de software orientado a objetos en términos del nivel de prueba. 6.4.1.1 Pruebas de unidad En el software orientado a objetos la menor unidad a considerar para realizar una prueba es la clase. La prueba de clases en el ámbito de software Orientado a Objetos es equivalente a la prueba de unidad realizada al software tradicional. Esta prueba está fundamentalmente dirigida a las operaciones encapsuladas por la clase, así como al estado y comportamiento del objeto que se implementa en ella. El énfasis de la prueba de unidad es verificar que esta pequeña unidad trabaje correctamente en forma aislada, antes de proceder a integrarla en el sistema. Los métodos contenidos en una clase pueden ser muchos y una operación en particular de ese conjunto, a consecuencia de la herencia, puede existir como parte de varias clases diferentes. Por lo tanto el significado de prueba de unidad cambia en muchos sentidos y es importante diseñarla bajo ciertas consideraciones. Se han propuesto estrategias para llevar a cabo las pruebas de unidad considerando aspectos como el orden en que los métodos son sometidos a la prueba, el orden en que una jerarquía de clases puede ser probada, ejercitar el flujo de datos o bien el análisis del estado del objeto. Los aspectos que deben considerarse para construir casos de prueba para una clase deben verificar que esta proporcione los servicios que promete, que responda correctamente a las condiciones esperadas y, más aún, ante las inesperadas. Aspectos adicionales pueden el verificar si la clase contiene y permite disponer de todas las funciones asociadas a ella o que cada método de la clase ejecute su responsabilidad especificada. Algunas de las técnicas más populares para realizar pruebas de unidad se muestran en la siguiente tabla:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 125 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Prueba Pruebas estructurales

Prueba de valores limite

Prueba basada en estados

Prueba incremental

Definición Si se tiene la disponibilidad de código fuente, pueden realizarse pruebas estructurales a las unidades sometidas a la prueba. Las acciones de esta actividad pueden diseñarse con el propósito de ejercitar todas las rutas del código, las condiciones establecidas o bien las ciclos definidos en el programa. Mediante esta técnica se prueba la unidad bajo situaciones inusuales o extremas, con el propósito verificar cómo son manejadas por el software. Para ello, los casos de prueba suministrados son diseñados considerando valores frontera, es decir los valores mínimo y máximo que la unidad puede aceptar, así como también aquellos valores cercanos a las fronteras identificadas. Para esta técnica, se generarán casos de prueba para un contexto en donde una clase se modela como una máquina de estados con secuencias de transiciones, con esto se pretende analizar el estado de los objetos de acuerdo a su comportamiento. Una vez que se ha establecido un modelo de estados con base en los atributos del objeto, se consideran en la prueba los métodos necesarios para poder observar los cambios de estado. La aplicación de esta técnica permite observar alguna de las siguientes situaciones: se produce un cambio a un estado correcto, se produce cambio a un estado incorrecto, no hay cambio de estado, se produce un estado indefinido correcto o bién, se produce un estado indefinido incorrecto. La prueba incremental dirige su atención a las subclases generadas como consecuencia de la herencia, siendo la clase padre una clase previamente probada. Aunque existen situaciones en las que éste tipo de pruebas se descarta, se pueden identificar algunas en las que no estarían de más: cuando se han agregado o modificado propiedades y/o métodos, cuando existen propiedades y métodos que se han heredado y no se han alterado, pero que realizan algún tipo de interacción con elementos nuevos o modificados.

Tabla 35: Pruebas de Unidad de Software Orientado a Objetos 6.4.1.2 Pruebas de integración. Cuando se aplican pruebas de integración al software orientado a objetos, se pretende demostrar que las unidades que ya han sido sometidas a un proceso de prueba y funcionan correctamente, lo hacen de igual forma cuando interactúan y se integran con otras unidades del sistema. Prácticamente, el trabajo de esta prueba se concentra en la interacción de métodos en diferentes unidades. Existe una coincidencia en los dos enfoques para realizar este tipo de pruebas: el basado en hilos y el basado en uso. En el primero, pretende que todas las clases respondan a sencillas entradas externas, provenientes de otra unidad. De esta forma, se realizan casos de prueba para cada clase en la unidad, con lo cual un hilo de este conjunto se ejercita.En el enfoque basado en uso, se realizan pruebas para clases las cuales usan servicios de otras clases. En la siguiente tabla se presentan algunos métodos para realizar pruebas de integración:


Prueba Método de Caminos Mensajes El método de Overbek

El método de Kung

de

Definición Este método se concentra principalmente en probar aquellos caminos que se generan por un evento de entrada y terminan con un evento de salida En este método se prueban las clases por pares, donde una hace el papel de cliente y otra el de servidor, estableciéndose para estas dos conjuntos de pruebas. El primer conjunto, son pruebas orientadas a verificar si los mensajes de entrada y de salida generados son correctos; es decir si se usa correctamente cualquier clase servidora y si todas las secuencias de operaciones son correctas. En el segundo conjunto se verifica además de lo anterior, si la clase cliente siempre satisface las precondiciones de la clase servidora, así como también si satisface las salidas esperadas por la clase servidora. Este método emplea una estrategia de ingeniería en reversa sobre el código de las unidades con el propósito de generar un diagrama de relaciones entre objetos. A partir de este diagrama se propone un orden para las pruebas que minimiza el uso de cabos. El diagrama se convierte en un grafo acíclico, que puede contener varios clusters de objetos y los ordenan topológicamente. Su método involucra las etapas de pruebas de unidad y de integración y puede usarse también para pruebas de regresión.

Tabla 36: Pruebas de Integración de Software Orientado a Objetos 6.4.1.3 Pruebas de sistema. Las pruebas de unidad se concentran en verificar si las funcionalidades descritas en las especificaciones o en los requisitos iniciales corresponden a las que se presentan en el producto final. En esta área, al igual que la de pruebas de integración, se han generado pocos trabajos, por lo que se emplean muchos de los métodos tradicionales. Prueba Prueba de función

Pruebas de aceptación

Prueba bajo stress

Definición La prueba de función comúnmente es llevada a cabo por el grupo de personas que desarrollaron el producto. Este enfoque se orienta a confirmar que la aplicación alcanza los requerimientos y la funcionalidad especificadas por el usuario En este tipo de pruebas, versiones que aún no han sido liberadas en el mercado, son ofrecidas a ciertos grupos de usuarios con el propósito de que las utilicen. El propósito de ésto es que los usuarios reporten defectos que pudieran presentarse. Para realizar esta prueba, el sistema somete a condiciones extremas de trabajo, como pueden ser un alto volumen de transacciones o un gran número de usuarios. Aplicando este enfoque, se puede verificar si el sistema se comporta como se espera aún ante este tipo de escenarios.

Tabla 37: Pruebas de Sistema de Software Orientado a Objetos


6.5

LECCIÓN 5: PRUEBA DE SOFTWARE BASADO EN COMPONENTES.

La construcción de software a partir de componentes es una práctica relativamente nueva, por lo que no es extraño que sea escasa la existencia de trabajos generados al respecto. Puesto que el desarrollo basado en componentes presenta algunas similitudes con el enfoque orientado a objetos, para un componente pueden ser aplicables algunas de sus consideraciones, incluso en materia de prueba. Aspectos como la herencia, encapsulación, polimorfismo, liga dinámica o mecanismos de comunicación, son comunes entre ambos modelos. Es evidente que para hacer las pruebas de componentes más robustas, será necesario considerar las características propias del enfoque de componentes. En la mayoría de los casos, los criterios de prueba de caja negra son los más aplicados a los componentes, puesto que la disponibilidad del código fuente es nula en la mayoría de las veces. Debido a que un componente es una unidad concreta, con una función bien definida, no basta realizar pruebas para su evaluación; de igual forma se requieren procesos de prueba para su selección y para su integración. Durante la etapa de construcción de un componente, el desarrollador puede aplicar las técnicas de prueba de unidad y de integración tradicionales del modelo Orientado a Objetos, sin embargo en lo que respecta a la selección y evaluación, considerar el punto vista del usuario es un aspecto vital para la realización de la prueba. Finalmente en el marco de pruebas de integración, consideraciones como la arquitectura de la aplicación, el software intermediario y los modelos de los componentes, deben agregarse a los criterios de evaluación. Con el propósito de organizar algunas de las estrategias de prueba de componentes más comunes, en las siguientes secciones se presenta una descripción de las mismas en los términos que se presentaron para el enfoque orientado a objetos, de nivel unidad y nivel de integración. 6.5.1 Pruebas de unidad. Aunque la realización de pruebas de unidad es una actividad que en algún momento es llevada a cabo por el desarrollador, existe un marco de trabajo adicional a considerar: el de la persona que se interesa en el componente con el fin de integrarlo en sus sistemas. Actualmente son pocos los trabajos en materia de pruebas de unidad para componentes, dos sobresalientes en este ramo son el proyecto Trusted Components y el Proyecto Kimera, aunque este último no esta dirigido totalmente a componentes, sino a la seguridad de las máquinas virtuales de Java cada vez que se carga una clase. Trusted Components, es un proyecto de investigación paras asistir a la industria de construcción de software mediante librerías probadas de


componentes. Las pruebas que se aplican a los componentes se construyen bajo la combinación de varios enfoques como diseño por contrato, como pruebas matemáticas, métricas, validación exhaustiva en proyectos prácticos y manejo de cambios rigurosos. 6.5.2 Pruebas de integración. Si las pruebas de nivel de unidad para componentes muestran severas carencias, en nivel de integración, al igual que en otros enfoques de desarrollo, las carencias son aún más notables. Sin embargo, existen coincidencias en cuanto a las problemáticas comunes al integrar componentes: 6.5.2.1 El volumen y la lentitud: Cuando se utilizan componentes dentro de un sistema, no siempre se utilizan todas sus capacidades, lo que hace que cierta parte del código no sea necesario. Este problema se agrava cuando se tienen sistemas grandes, afectándose así su rendimiento. 6.5.2.2 Los mecanismos de comunicación utilizados: Se han presentado algunas contrariedades e inconsistencias al utilizar dentro de un mismo sistema varios mecanismos de comunicación como eventos, mensajes o bien el paso de parámetros.


GLOSARIO DE TÉRMINOS Arquitectura de software: Es un diseño global de una aplicación que incluye su descomposición en partes. Calidad: La calidad es herramienta básica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie. Calidad de Software: Características propias del software que se desea controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico. Calidad externa: La magnitud de satisfacción de un producto con relación a necesidades establecidas cuando es usado bajo condiciones específicas. Calidad interna: El total de atributos de un producto que determina su capacidad para satisfacer necesidades establecidas cuando es usado bajo condiciones específicas. Componente Software: Son todos aquellos recursos desarrollados para un fin concreto y que puede formar solo o junto con otros, un entorno funcional requerido por cualquier proceso predefinido. Documentación de pruebas del software: Documento que especifica todos los aspectos del proceso de pruebas para una aplicación. Estándar: Base o modelo en el que todo el mundo se ha puesto de acuerdo. Gestión de Calidad de Software: Es un conjunto de actividades de la función general de la Dirección que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinación y aplicación de las políticas de calidad de la empresa. ISO: (Internacional Standards Organization) Organización Internacional de estándares fundada en 1946, con sede principal en Ginebra, ISO establece o fija estándares internacionales. Se ocupa de todos los campos, excepto la electricidad y la electrónica, que se rigen por la Internacional Electrotechnical Comisión (IEC), también en Ginebra. ISO 9001: Es un conjunto de normas sobre la calidad y la gestión. ISO/IEC 9126: Es un estándar internacional para la evaluación del software. Está supervisado por el proyecto SQuaRE, ISO 25000:2005, el cuál sigue los mismos


conceptos. El estándar está dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, métricas externas, métricas internas y calidad en las métricas de uso. ISO/IEC 14598: Norma para la evaluación del producto software. Esta norma comprende las siguientes seis partes que especifican el proceso a seguir para evaluar software: ISO/IEC 14598-1 Visión general; ISO/IEC 14598-2 Planificación y Gestión; SO/IEC 14598-3 Procedimiento para desarrolladores; ISO/IEC 14598-4 Procedimiento para compradores; ISO/IEC 14598-5, Procedimiento para evaluadores; ISO/IEC 14598-6 Documentación de los módulos de evaluación. ISO/IEC 25000: Especificación de requerimientos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad del software. Métrica: Una escala de medición y un método usado para la medición. Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas para un conjunto de descripciones que de otra manera no podrían ser sistematizadas. Proceso: El proceso de ingeniería de software se define como un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad. Prueba: Actividad durante la cual los desarrolladores encuentran diferencias entre el sistema y sus modelos ejecutando el sistema (o partes de él) con conjuntos de datos de entrada de prueba. Prueba de Caja Blanca: Prueba que se enfoca en la estructura interna de un componente. Prueba de Caja Negra: Prueba que se enfoca en el comportamiento de entrada/salida de un componente sin considerar su implementación. Pruebas del sistema: Proceso de probar una aplicación completa (no sus partes).


FUENTES DOCUMENTALES Bibliografía de referencia: BRAUDE. Ingeniería de software, una perspectiva orientada a objetos. México. 2003. Alfaomega grupo editor. S.A. Cavano, J.P., McCall, J.A., A Framework for the Measurement of Software Quality, Proc. of the ACM Software Quality Assurance Workshop, pp. 133-139, Nov. 1978. De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997. G. Heineman and W. Council (Eds.). Component-Based Software Engineering – Putting the Pieces Together, Addison-Wesley, 2001. HUMPHREY, Watts S. Introducción al proceso de software personal. Pearson Addison wesley. 2001. ISO/IEC 14598-1:1999. Information technology software product evaluation - part 1: General overview. International Standard ISO/IEC 14598-1, ISO, April 1999. ISO/IEC 9126-1:2001. Software engineering product quality part 1: Quality model. International Standard ISO/IEC 9126-1, International Standard Organization, June 2001. James M. Bieman and Linda M. Ott. Measuring functional cohesion. Technical Report CS-93-109, Fort Collins, CO, USA, 24 June 1993. James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software quality, volume III: Preliminary handbook on software quality for an acquisition manager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731, 1977. MEYER, Bertrand. Construcción de software orientado a objetos. Segunda edición. Madrid. 1999. Prentice Hall. Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2a ed., IEEE Computer Society Press, 1981. Murine, G.E. , Integrating software quality metrics with software QA, Quality Progress vol.21, no.11; pp. 38-43; Nov. 1988. Norman E. Fenton and Shari Lawrence Pfleeger. Software Metrics: A Rigorous & Practical Approach. Brooks/Cole, 2 edition, January 1998. Piatini, Mario y col. Analisis y Diseño de Aplicaciones Informáticas de Gestión, Una Perspectiva de Ingeniería de Software, Alfaomega 2004. Páginas 109 – 164.


PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos, técnicas y métodos para la gestión del cambio. Editorial Alfaomega-Rama. PRESSMAN, Roger S. Ingeniería del Software. Un enfoque práctico. Quinta edición. España. 2002. Editorial McGraw Hill. SOMMERVILLE, Ian. Ingeniería de software. 6ª. Edición. Pearson Addison Wesley. 2001 T.J. McCabe. A software complexity measure. IEEE Transactions on Software Engineering, 2(4):308–320, 1976. Direcciones Electronicas (webgrafía) http://www.pressman5.com http://www.wiley.com/college/braude http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html http://www.sistemas.unam.mx/software.html http://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html http://www.bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm Oscar M. Fernández Carrasco1, Delba García León2 y Alfa Beltrán Benavides3 http://www.lcc.uma.es/~av/misConfs/Calidad%20de%20Componentes%20CR %20Junio%202004.ppt#345,2,Agenda http://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdf http://www.pcm.gob.pe/portal_ongei/banconormas1.asp http://www.iso.org http://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL %209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.html



EVALUACIÓN DE SOFTWARE La evaluación de software en la actualidad es uno de los elementos que debe ser tenido en cuenta en el proceso de construcción de un producto software, como también, en el producto terminado. La evaluación del producto software es la garantía que debe brindar el fabricante de que su producto cumple con las normas de calidad internacionales para estos productos tan especiales. Además la evaluación de productos software contribuye al mejoramiento de los procesos en la empresa, ya que, permite la verificación y validaciós de todas y cada una de las características del producto no importando si se trate de una aplicación pequeña o compleja.

Justificación


Denominación de capítulos Denominación de

En este capítulo se tratará de identificar la metodología técnica para la evaluación de software, las metodologias de evaluación de la arquitectura y algunas de las aplicaciones de la evaluación de software. Actualmente cada uno de los productos de software que salen comercialmente al mercado deben garantizar al menos el cumplimiento de normas estándares de calidad que permitan a los usuarios determinar el grado de eficiencia, eficacia y confiabilidad de estos productos. Y una de las funciones encomendadas a los ingenieros es la de evaluar los productos software y determinar cual de ellos es el más apropiado para la organización o para uno de los procesos dentro de ella. Por lo tanto es importante que los futuros profesionales adquieran el conocimiento y las habilidades para cumplir cabalmente con sus funciones dentro de la organización. - El estudiante conoce y aplica la norma de calidad ISO/IEC 9126 para la evaluación de software - El estudiante esta en capacidad de relacionar los conceptos de evaluación, características, metricas, pruebas y llevarlos a la práctica - El estudiante conoce las diferentes metodoligias para la evaluación del proceso y producto software - El estudiante adquire nuevos conocimientos y puede transferirlos aplicandolos a su entorno laboral llevándolos a la práctica CAPÍTULO 7. METODOLOGÍA TÉCNICA PARA LA EVALUACIÓN DE SOFTWARE Lección 1. Modelos Tradicionales para la Evaluación de la


lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de capítulos Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de capítulos Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones Denominación de lecciones

Calidad del software Lección 2. Norma de Evaluación ISO/IEC 9126 Lección 3. Proceso de Evaluación de Software Lección 4. Métricas Externas Basados en ISO/IEC 9126 Lección 5. Métricas Internas Basados en ISO/IEC 9126 CAPÍTULO 8: METODOLOGÍAS DE EVALUACIÓN PARA ARQUITECTURA DEL SOFTWARE Lección 1. Evaluación de la Arquitectura del software Lección 2. Técnicas de Evaluación de la arquitectura del software Lección 3. Métodos de Evaluación de la arquitectura de software Lección 4. Métodos de Evaluación de Arquitectura de un Atributo Específico Lección 5. Método de evaluación de la Arquitectura de Software MECABIT CAPÍTULO 9: APLICACIONES DE LA EVALUACIÓN DE SOFTWARE Lección 1. Metodología para la Evaluación de la Calidad en Modelos UML Lección 2. Implementación de la Metodología con SPEM y EPFC Lección 3. Evaluación de Software Educativo Multimedia Lección 4. Modelos de Evaluación de Software Educativo Multimedia Lección 5. Plantillas de Evaluación de Software Multimedia


UNIDAD 3

EVALUACIÓN DE SOFTWARE


CAPITULO 7

MÉTODOLOGÍA TÉCNICA DE EVALUACIÓN DE SOFTWARE


INTRODUCCIÓN La metodología para evaluación técnica de software considera una serie de pasos que deben ser tenidos en cuenta cuando se trata de realizar este proceso tan complejo, por eso es necesario que se conozcan y se haga el seguimientos de ellos para realizar una buena evaluación del producto. Dentro de los estándares de calidad más utilizados esta el estándar definido por la ISO/IEC 9126 el cual toma en consideración la evaluación de las características internas, externas y de calidad en uso. A su vez cada una de las características se divide en subcaracterísticas que se pueden definir y a las cuales se les puede establecer unas métricas, pruebas y escalas de medición que permitan establecer una valoración para el producto en la caracerística que haya sido elegida. En este capítulo se tratará el tema de algunas de las metodologias existentes para la evaluación de software, dentro de ella se ha elegido la norma ISO/IEC y de ella se hará el seguiemiento hasta llegar a definir las métricas que son la base para realizar el proceso de evaluación de software.


7.1 LECCIÓN 1: MODELOS TRADICIONALES DE EVALUACIÓN DE LA CALIDAD DEL SOFTWARE Cuando se trata de evaluar la calidad de un producto software hay que tener en cuenta que la calidad es un concepto muy complejo y que, además, depende mucho del punto de vista que se adopte. La evaluación se basa en la descomposición del concepto genérico de calidad en propiedades más sencillas de medir y evaluar. Este tipo de descomposición recibe el nombre de modelo de calidad. Los modelos de calidad más conocidos y utilizados han sido los de Boehm y McCall. El modelo de McCall se basa en descomponer el concepto de calidad en tres usos o capacidades importantes para un producto software desde el punto de vista del usuario: La capacidad de operación, la capacidad para ser modificado y la capacidad de transición o de adaptación a otros entornos. Cada capacidad o uso se descompone en una serie de factores que determinan la calidad en cada una de las capacidades antes mencionadas. Por lo tanto, existen una serie de factores que se puede evaluar más fácilmente que las capacidades para tener una visión apropiada de la calidad. Estos factores son conceptos de alto nivel de abstracción, a continuación se ofrecen las definiciones de estos factores: Facilidad de uso: Grado de esfuerzo necesario para aprender a utilizar el software, preparar la entrada de datos e interpretar la salida del mismo. Integridad: Grado en que se puede controlar el acceso del personal al software o a los datos que utiliza. Eficiencia: Necesidades de recursos hardware y software requeridos por el software evaluado para realizar sus funciones. Fiabilidad: Grado o probabilidad de que el software no falle al realizar sus funciones. Corrección: Grado en que el software cumple sus especificaciones. Flexibilidad: Facilidad o grado de esfuerzo necesario para modificar el software en funcionamiento. Facilidad de Prueba: Esfuerzo necesario (o facilidad) para probar el software de modo que se tenga un cierto grado de confianza en que realiza adecuadamente sus funciones. Facilidad de Manteniemiento: Facilidad o grado de esfuerzo para mantener operativo el software mediante la corrección o depuración de los problemas que puedan aparecer durante su funcionamiento.


Transportabilidad: Facilidad o grado de esfuerzo necesario para transportar o migrar el software de un entorno de operación a otro. Capacidad de reutilización: Capacidad o grado de esfuerzo para que el software o alguna de sus partes puedan ser utilizadas en otros desarrollos de software. Capacidad de Interoperación: Capacidad o grado de esfuerzo necesario para que el software o un sistema puedan operar conjuntamente con otros sistemas o aplicaciones de software. Cada factor deteminante de la calidad se descompone, a su vez, en una serie de criterios o propiedades que determinan su calidad, Los factores se suponen conceptos de alto nivel que, como la propiedad genérica de la calidad, son demasiado abstractos para ser significativos o poder ser medidos o evaluados directamente. Por lo tanto, existen una serie de criterios de calidad de más bajo nivel osea más detallados. Estas propiedades elementales o criterios son propiedades internas del software, que no dependen en su apreciación de quién esté observándolas y que los desarrolladores de software consideran que influyen en la calidad, algunos de estos son: Facilidad de Operación: Propiedades del software que determinan la facilidad de las operaciones y de los procedimientos relativos a la explotación del software. Facilidad de Comunicación: Propiedades del software que proporciona1 eficacia y facilidad en las comunicaciones. Facilidad de Formación o Aprendizaje: Propiedades del software que proporcionan al usuario información de operaciones reales o que facilitan la familiarización inicial con el producto. Control de Accesos: Propiedades del software que proporcionan facilidades para el control de accesos al software y a los datos que maneja. Facilidad de Auditoria: Propiedades del software que proporcionan facilidades para realizar auditoria del software, de los datos empleados o de los resultados obtenidos. Efieciencia de ejecución: Propiedades del software que proporcionan un consumo mínimo de recursos de procesamiento al realizar sus operaciones. Eficiencia de Almacenamiento: Propiedades del software que proporcionan unas necesidades mínimas de memoria para su operación. Exactitud o Precisión: Propiedades del software que proporcionan el grado de precisión requerido para los resultados que hay que obtener.


Consistencia: Propiedades del soflware que proporcionan técnicas documentación uniforme y coherente a las distintas etapas del software.

y

Tolerancis a Fallos: Propiedades que proporcionan la continuidad del funcionamiento bajo condiciones no habituales. Modularidad: Propiedades del software que proporcionan una estructura de módulos adecuadamente independientes. Simplicidad: Propiedades del software que proporcionan la implantación de funcioncs de la manera más comprensible posible. Compleción: Propiedades del software que proporcionan la implantación total de todas las funciones requeridas. Rastreabilidad o facilidad de Traza: Propiedades del software que proporcionan una taza o pista reconocible desde los requisitos hasta su implantación en relación a un desarrollo específico y a un determinado entorno de operaciones. Autodescripción: Propiedades del software que proporcionan explicaciones sobre el desarrollo de cada función. Capacidad de Expansión: Propiedades del software que proporcionan facilidades para añadir nuevas capacidades funcionales o datos al sistema. Generalidad: Propiedades del software que proporcionan amplitud a las funciones realizadas. Instrumentación: Propiedades de] software que proporcionan la posibilidad de observar el comportamiento del software durante su ejecución. Independencia entre Sistema y Software: Propiedades del software que determinan su dependencia de su entorno lógico de trabajo. Independencia del Hardware: Propiedades del software que determinan su dependencia de su entorno físico de trabajo (CPU, dispositivos, etc.). Normalización o Compatibilidad de Comunicaciones: Propiedades del software que favorecen una fácil intercomunicación del sistema con otros. Normalización o Compatibilidad de Datos: Propiedades del software que determinan la posibilidad de utilización común de datos con otros sistemas. Este tipo de modelos de evaluación de la calidad han gozado de una gran aceptación en el mundo del software. Esto ha motivado que se hayan intentado establecer como estándares por parte de diversos organismos. Así, la norma IEEE 1061 propone un modelo de medición muy parecido al de McCall denominado


modelo factor/criterio/métrica, y la norma ISO 9126 establece un modelo propio de calidad cuya base es similar al de McCaIl. En los años ochenta, cambió el enfoque de los modelos de evaluación de la calidad, ya que se impulsó la creación de modelos particulares para cada empresa o para cada proyecto en vez de utilizar un mismo modelo para todos los casos, se implantó así, de forma efectiva, el concepto de calidad relativa. En el caso de Gilb, se propone la creación de una especificación de requisitos de calidad para cada proyecto, que deben escribir conjuntamente el usuario y el analista. Se trata fundamentalmente de determinar una lista de las características que definen la calidad de la aplicación. Dichas características pueden ser totalmente originales, aunque lo más normal es que se inspiren o se tomen directamente de alguno de los modelos tradicionales. Las distintas características se pueden medir mediante varias subcaracterísticas o métricas detalladas. Para cada una de éstas se deben especificar los siguientes conceptos: • Nombre y definición de la característica. • Escala o unidades de medición. • Recogida de datos o prueba. • El peor valor aceptable. • El valor previsto. • El valor óptimo. • El valor del sistema actual. • Comentarios. En algunos casos, este enfoque de Gilb se ha asociado indirectamente a la filosofía QFD (Quality Function Deplovrnent: Despliegue de la función de la calidad) que se aplica en el ámbito de la gestión de la calidad industrial, aunque existen trabajos específicos de aplicación de QFD al software. Por otra parte, el enfoque de GiIb ha inspirado trabajos posteriores como el del proyecto COQUAMO (Constructive Quality Model: Modelo Constructivo de la Calidad) que propone una herramienta automatizada que ayuda a determinar (mediante plantillas) el modelo de calidad más apropiado para un proyecto. Otro enfoque relativista de medición de la calidad del software es el representado por el paradigma GQM (Goal-Question-Metric: Objetivo-PreguntaMétrica) propuesto por Basili y Rombach. Aunque se trata de un enfoque general de la medición, se trata de un método muy apropiado para evaluar la calidad del software en cada proyecto. La idea consiste en que toda actividad de medición debe estar precedida por la identificación de un objetivo a lograr, que lleva a plantearse una serie de interrogantes sobre aspectos más puntuales de la calidad, esto llevará, a su vez, a disponer de una serie de métricas que nos permitan responderlas. Aunque inicialmente puede parecer poco práctico el uso del modelo GQM, la reflexión que implica su construcción es valiosa ya que permite aclarar el concepto de calidad que se persigue en el proyecto.


Por último, se debe decir que existe un enfoque más primitivo de medir la calidad que se basa en considerarla equivalente a la ausencia de “defectos”, entendidos éstos como fallos, defectos o errores conocidos. La ventaja de esta manera de medir es que los datos sobre defectos se pueden obtener fácilmente sólo con mantener un sistema de registro de la información generada en el proyecto a partir de los datos aportados por las técnicas de detección de defectos. Los informes de las revisiones donde se indican los defectos encontrados, los resultados de las pruebas del software, las peticiones de cambios que debe gestionar la gestión de la configuración, etc. Es muy habitual obtener medidas que relacionan el número de “defectos” con el tamaño del software. Así, por ejemplo, una propuesta típica de recolección de datos incluye: • N° de problemas informados. • N° de problemas evaluados. • N° de problemas reales. • N° de problemas abiertos, pendientes de resolución. • N° de problemas cerrados. • Tiempo que permanece un problema abierto. • Tiempo que permanece un problema hasta ser evaluado. • Distribución de problemas por fase del desarrollo, por prioridad, por categoría (grave, leve, estético), etc. Este enfoque de medición está inspirado en el control estadístico de procesos aplicado en la industria convencional de fabricación. Uno de los casos más conocidos de aplicación de este enfoque es el del programa de medición aplicado por Grady en Hewlett-Packard. El problema principal de este enfoque es que la existencia de un defecto no siempre acarrea un problema de calidad en el software y, por lo tanto, resulta menos riguroso que otros modelos. Sin embargo, cuenta con la ventaja de que, en una empresa mínimarnente organizada, la recogida de datos resulta barata y relativamente sencilla. 7.2

LECCIÓN 2: NORMA DE EVALUACIÓN ISO/IEC 9126

Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación de la calidad de software, llamado “Information technology-Software product evaluation-Quality characteristics and guidelines for their use”; o también conocido como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características generales: Fucionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y Portabilidad. La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de software. Los modelos de calidad para el software se describen así:


Calidad interna y externa: Especifica 6 características para calidad interna y externa, las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informático, y son el resultado de atributos internos de software. Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las 6 características de la calidad interna y externa del software. Especifica 4 características para la calidad en uso. Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación mas completo, se puede pensar que la usabilidad del modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es la forma como los profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario final. Si se unen los dos modelos, se puede definir que los seis indicadores del primer modelo tienen sus atributos y el modelo de calidad en uso sus 4 indicadores pasarían hacer sus atributos, mirándolo gráficamente quedaría asi:

Figura 23: Norma de Evaluación ISO/IEC 9126 Se establecen categorías para las cualidades de la calidad externa e interna y calidad en uso del software, teniendo en cuenta estos 7 indicadores (funcionalidad, confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad en uso), que se subdividen a su vez en en varios indicadores; estas se pueden medir por métrica interna o externa.


Figura 24: Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126 Las definiciones se dan para cada característica y subcaracterística de calidad del software que influye en la calidad. Para cada característica y subcaracterística, la capacidad del software es determinada por un conjunto de atributos internos que pueden ser medidos. Las características y sub características se pueden medir externamente por la capacidad del sistema que contiene el software. 7.2.1 Funcionalidad Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas. A continuación se muestra la característica de Funcionalidad y las subcaracterísticas que cubre:


Figura 25: Característica de Funcionalidad La funcionalidad se divide en 5 criterios: Adecuación: La capacidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario. Exactitud: La capacidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada. Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos. Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados Conformidad de la funcionalidad: La capacidad del software de de cumplir los estándares referentes a la funcionalidad. 7.2.2 Confiabilidad La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento adecuado cuando es utilizando en condiciones especificas. En este caso al confiabilidad se amplia a sostener un nivel especificado de funcionamiento y no una función requerida.


Figura 26: Característica de Confiabilidad La confiabilidad se divide en 4 criterios: Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra errores. Ejemplo, la forma como el software advierte al usuario cuando realiza operaciones en la unidad de diskett vacia, o cuando no encuentra espacio suficiente el disco duro donde esta almacenando los datos. Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de funcionamiento en caso de errores. Recuperabilidad: La capacidad que tiene el software para restablecer su funcionamiento adecuado y recuperar los datos afectados en el caso de una falla. Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad. 7.2.3 Usabilidad La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como usabilidad. La usabilidad esta determinada por los usuarios finales y los usuarios indirectos del software, dirigidos a todos los ambientes, a la preparación del uso y el resultado obtenido.


Figura 27: Característica de Usabilidad La usabilidad se divide en 5 criterios: Entendimiento: La capacidad que tiene el software para permitir al usuario entender si es adecuado, y de una manera fácil como ser utilizado para las tareas y las condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la documentación y de las ayudas que el software entrega. Aprendizaje: La forma como el software permite al usuario aprender su uso. También es importante considerar la documentación. Operabilidad: La manera como el software permite al usuario operarlo y controlarlo. Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño gráfico. Conformidad de uso: La capacidad del software de cumplir los estándares o normas relacionadas a su usabilidad. 7.2.4 Eficiencia La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al número recursos utilizados según las condiciones planteadas. Se debe tener en cuenta otros aspectos como la configuración de hardware, el sistema operativo, entre otros.


Figura 28: Característica de Eficiencia La usabilidad se divide en 3 criterios: Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su función en condiciones especificas. Ejemplo, ejecutar el procedimiento mas complejo del software y esperar su tiempo de respuesta, realizar la misma función pero con mas cantidad de registros. Utilización de recursos: La capacidad del software para utilizar cantidades y tipos adecuados de recursos cuando este funciona bajo requerimientos o condiciones establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos. Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los estándares o convenciones relacionados a la eficiencia. 7.2.5 Capacidad de mantenimiento La capacidad de mantenimiento es la cualidad que tiene el software para ser modificado. Incluyendo correcciones o mejoras del software, a cambios en el entorno, y especificaciones de requerimientos funcionales.


Figura 29: Característica de Mantenimiento El mantenimiento se divide en 5 criterios: Capacidad de ser analizado: La forma como el software permite diagnósticos de deficiencias o causas de fallas, o la identificación de partes modificadas. Cambiabilidad: La capacidad del software para que la implementación de una modificación se pueda realizar, incluye también codificación, diseño y documentación de cambios. Estabilidad: La forma como el software evita efectos inesperados para modificaciones del mismo. Facilidad de prueba: La forma como el software permite realizar pruebas a las modificaciones sin poner el riesgo los datos. Conformidad de facilidad de mantenimiento: La capacidad que tiene el software para cumplir con los estándares de facilidad de mantenimiento. 7.2.6 Portabilidad La capacidad que tiene el software para ser trasladado de un entorno a otro.


Figura 30: Característica de Portabilidad La usabilidad se divide en 5 criterios: Adaptabilidad: Es como el software se adapta a diferentes entornos especificados (hardware o sistemas operativos) sin que implique reacciones negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.). Facilidad de instalación: La facilidad del software para ser instalado en un entorno especifico o por el usuario final. Coexistencia: La capacidad que tiene el software para coexistir con otro o varios software, la forma de compartir recursos comunes con otro software o dispositivo. Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad de una nueva versión es importante para el usuario, la propiedad de poder migrar los datos a otro software de diferente proveedor. Conformidad de portabilidad: La capacidad que tiene el software para cumplir con los estándares relacionados a la portabilidad. 7.2.7 Calidad en uso Calidad en uso es la calidad del software que el usuario final refleja, la forma como el usuario final logra realizar los procesos con satisfacción, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisión de todas las opciones que el usuario trabaja diariamente y los procesos que realiza esporádicamente relacionados con el mismo software.


Figura 31: Característica de Calidad en Uso La usabilidad se divide en 4 criterios: Eficacia: La capacidad del software para permitir a los usuarios finales realizar los procesos con exactitud e integridad. Productividad: La forma como el software permite a los usuarios emplear cantidades apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de uso. Para una empresa es muy importante que el software no afecte al productividad del empleado Seguridad: Se refiere al que el Software no tenga niveles de riesgo para cuasar daño a las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento. Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el software, e incluye las actitudes hacia el uso del mismo. A continuación se describe un cuadro donde podemos resumir las características y cada uno de sus atributos, este cuadro le ayudara a visualizar elporceso de evaluacion. 7.3

LECCIÓN 3: PROCESO DE EVALUACIÓN DE SOFTWARE

El proceso de evaluación de software se inicia con una visión cualitativa y deriva en una evaluación cuantitativa, siendo todo el proceso documentado y cumpliendo los siguientes pasos:


7.3.1 Estado del Software Que se refiere al conocimiento del el estado del software, estableciendo si se trata de un desarrollo sin terminar o un producto terminado para la entrega al cliente. 7.3.2 Identificar el tipo de software Donde se debe especificar el tipo de software a evaluar, si es un sistema operativo, software de seguridad, software de ofimática, lenguaje de programación, base de datos, aplicativo a la medida, entre otros. 7.3.3 Perfiles de Evaluadores Teniendo como marco conceptual al estándar ISO/IEC9126, se consideran tres perfiles de usuario, a un alto nivel de abstracción para desarrollo de software, usuarios finales, desarrolladores, y gerentes. El estándar afirma que la relativa importancia de las características de calidad varía dependiendo del punto de vista considerado y de la crítica de los componentes del software a evaluar. La visión del usuario final, concierne al interés de los mismos en usar el software, como así también su performance, su eficiencia, su facilidad de uso, entre otros aspectos. Los usuarios finales no están interesados en características internas o de desarrollo del software. La visión de calidad del desarrollador debe considerar no sólo los requerimientos del software para la visión del usuario sino también la calidad para los desarrollos intermedios resultantes de las actividades de la fase de desarrollo. Se debe tener en cuenta que los desarrolladores están preocupados en características de calidad del software como mantenibilidad y portabilidad. La visión de calidad del gerente es una visión integradora, que incorporar requerimientos de negocio a las características individuales. Ejemplo, un gerente esta interesado en el equilibrio entre la mejora del software y los costos y tiempos establecidos. 7.3.4 Especificar los Objetivos Se debe conocer los objetivos tanto generales como específicos del software. 7.3.5 Aplicar el modelo de calidad Donde se debe elaborar un instrumento o formato donde aplique el modelo de calidad externo e interno y calidad de uso. Si existe un comité o conjunto de personas encargadas de la evaluación, el instrumento debe ser aprobado por los participantes.


7.3.6 Criterios de la evaluación Donde se tiene en cuenta los criterios de evaluación que parten de los 7 indicadores principales los cuales fueron especificacdos en la lección anterior. Los criterios para evaluar el software se dividen en dos grandes bloques: uno dedicado a criterios que son aplicables a cualquier tipo de software, y otro conjunto compuesto por criterios adaptables al grupo de software evaluados. En este caso se definen los criterios de la evaluación según el tipo de software, para el cual debe conformar un equipo evaluador, este ejercicio ayuda a definir que opciones se deben evaluar con más detalle y valor. tipos de software

ejemplos

financieros

contabilidad, bancarios, carteras, pagos, costos, nominas, etc

administrativos

recursos humanos, administración de documentos, hospitalarios, etc

educativos

materias académicas, enciclopedias, tutores, manuales producción, radio terapia, control de maquinas, etc

a la medida

orden del criterio de evaluación 1. Seguridad 2. Tiempo de respuesta 3. Exactitud de la información 4. Recuperabilidad 1. Tiempo de respuesta 2. Seguridad 3. Exactitud de la información 4. Recuperabilidad 1. Facilidad de comprensión 2. calidad grafica 3. portabilidad Los criterios o indicadores están sujetos a la actividad específica del software

evaluadores personal de sistemas, contador o financiero, auxiliar, digitador personal de sistemas, administrativo, auxiliar, digitador personal de sistemas, docente, alumno personal de sistemas, personal que conozcael proceso manual o automático, cliente

Tabla 38: Tabla de criterios a tener en cuenta al evaluar un software 7.3.7 Seleccionar métricas: Que se obtienen de los indicadores especificados en el modelo. Los niveles o escalas son especificadas de acuerdo a lo que se quiera medir, se debe tener en cuenta ciertos criterios para la asignación de puntajes, por ejemplo a cada métrica seleccionada se le asigna un puntaje máximo de referencia, se debe tener en cuenta que la suma de los puntajes máximos de todas las métricas debe ser igual o aproximado a 100 puntos, que el personal que participa en la evaluación debe establecer niveles de calificación cualitativa con base a los puntajes (por ejemplo: de 0 a 1 Inaceptable, de 2 a 3 mínimo aceptable, más de 3 Aceptable o satisfactorio), otro ejemplo de calificación cualitativa puede ser (Deficiente, Insuficiente, Aceptable, Sobresaliente, Excelente), en la métricas se permite usar números enteros o hasta con un decimal de aproximación, se debe definir por cada métrica, un puntaje mínimo de aprobación, y al final de de la evaluación, dependiendo del puntaje si es mayor o menor a lo propuesto, considerar si el software cumple o no cumple con los objetivos propuestos.


7.3.8 Establecer criterios: La persona que participa en el proceso de evaluación debe tener criterios con respecto al indicador que se esta analizando, Es importante tener en cuenta que el criterio debe ajustar al tipo de software que se va a evaluar. 7.3.9 Tomar medidas: Para la medición, las métricas seleccionadas se aplican al software. Los resultados son valores expresados en las escalas de las métricas, definidos previamente. 7.3.10 Resultados: Los resultados del proceso de evaluación genera un cuadro de resultados por cada uno de losprincipales indicadores y el total final de resultado. 7.3.11 Documentación: El proceso de evaluación se documenta, indicando la fecha, empresa, los cargos, nombres y apellidos, dependencia de las personas que participan en el proceso de evaluación, especificando las etapas en las que participaron. 7.3.12 Seguimiento: Donde si el resultado de la evaluación tiene observaciones o indicadores de calidad bajos, y el personal que lo evalúa permite realizar la corrección, se programa otra evaluación donde se verifique que el proceso mejora, el tiempo que se estime debe influir en los criterios de la aproxima evaluación. A partir de cada una de las características, y subcaracterísticas de la norma ISO/IEC 9126, se ha incluído las preguntas generales para cada una de ellas, la siguiente tabla muestra las características, la pregunta planteada para ella, las subcaracterísticas y los cuestionamientos para cada una de ellas: CARACTERISTICA FUNCIONALIDAD

PREGUNTA ¿Las funciones y Propiedades satisfacen las necesidades Explícitas e implícitas; esto es, el qué?

SUBCARATERISTICA ADECUACIÓN

EXACTITUD INTEROPERABILIDAD CONFORMIDAD

CONFIABILIDAD

¿Puede mantener el nivel de rendimiento, bajo ciertas condiciones

MADUREZ TOLERANCIA ERRORES

A

PREGUNTA ¿Tiene el conjunto de funciones apropiadas para las tareas especificadas? ¿Hace lo que fue acordado en forma esperada y correcta? ¿Interactúa con otros sistemas especificados? ¿Está de acuerdo con las leyes o normas y estándares, u otras prescripciones? ¿Con qué frecuencia presenta fallas por defectos o errores? ¿Si suceden fallas, como se comporta en cuanto a la performancia

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 155 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ y por cierto tiempo?

especificada? RECUPERABILIDAD

USABILIDAD

¿El software, es fácil de usar y de aprender?

ENTENDIMIENTO

APRENDIZAJE OPERABILIDAD ATRACCIÓN EFICIENCIA

CAPACIDAD DE MANTENIMIENTO

¿Es rápido y minimalista en cuanto a uso de recursos, bajo ciertas condiciones? ¿Es fácil de modificar y testear?

COMPORTAMIENTO DE TIEMPOS UTILIZACION DE RECURSOS CAPACIDAD DE SER ANALIZADO CAMBIALIDAD ESTABILIDAD FACILIDAD PRUEBA

PORTABILIDAD

¿Es fácil de transferir de un ambiente a otro?

DE

ADAPTABILIDAD FACILIDAD INSTALACION

DE

REMPLAZABILIDAD COEXISTENCIA CALIDAD EN USO

¿Muestra usuario aceptación seguridad software?

el final y del

EFICACIA PRODUCTIVIDAD

SEGURIDAD

¿Es capaz de recuperar datos en caso de fallas? ¿Es fácil de entender y reconocer la estructura y la lógica y su aplicabilidad? ¿Es fácil de aprender a usar? ¿Es fácil de operar y controlar? ¿Es atractivo el diseño del software? ¿Cuál es el tiempo de respuesta y performancia en la ejecución de la función? ¿Cuántos recursos usa y durante cuánto tiempo? ¿Es fácil diagnosticar una falla o identificar partes a modificar? ¿Es fácil de modificar y adaptar? ¿Hay riesgos o efectos inesperados cuando se realizan cambios? ¿Son fáciles de validar las modificaciones? ¿Es fácil de adaptar a otros entornos con lo provisto? ¿Es fácil de instalar en el ambiente especificado? ¿Es fácil de usarlo en lugar de otro software para ese ambiente? ¿Comparte sin dificulta recursos con otro software o dispositivo? ¿La eficaz el software cuando el usuario final realiza los procesos? ¿Muestra el usuario final rendimiento en sus tareas cotidianas del proceso específico? ¿El software tiene niveles de Riesgo que causan daño al usuario final?


Tabla 39: Características y Subcaraterísticas ISO/IEC 9126 7.4 LECCIÓN 4: MÉTRICAS EXTERNAS BASADOS EN ISO/IEC 9126 Además de los cuestionarios generales, se presenta cada característica, la sub característica, y las métricas a evaluar, estas métricas pueden ser la base para elaborar cuestionarios teniendo en cuenta la norma ISO/IEC 9126, para poder realizar el análisis de las métricas externas de acuerdo a las caractrísticas propias del software a evaluar y a las características y subcaracteríaticas seleccionadas para la evaluación, en la siguiente tabla se muestra las métricas externas para evaluación de software. característica Funcionalidad

sub característica Idoneidad

de

nombre métrica Adecuación funcional Integridad funcional de aplicación Cobertura de aplicación funcional Estabilidad de la especificación funcional (volatilidad) Precisión a la expectativa Precisión de cómputo Precisión Intercambiabilidad de datos (formato de base de datos)) Intercambiabilidad de datos (intento del usuario de éxito basado en el intercambio) Acceso auditabilidad Acceso controlabilidad Datos de prevención de la corrupción Cumplimiento funcional

de

Interfaz estándar de cumplimiento latente estimada de densidad de fallos Falta de densidad en contra de casos de prueba Falta de resolución Error de la densidad Error de la eliminación Tiempo medio entre fallos Prueba de cobertura (cobertura de las operaciones especificadas escenario de prueba) Prueba de madurez Evitar desglose Evitar la falta Evitar el funcionamiento incorrecto Disponibilidad Tiempo medio de inactividad Tiempo medio de recuperación Reinicio Restaurabilidad Restaurar la eficacia Confiabilidad de cumplimiento

Precisión Interoperabilidad

Seguridad Funcionalidad Cumplimiento Confiabilidad

Madurez

Tolerancia a Fallos Recuperación

Fiabilidad Cumplimiento

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 157 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Usabilidad

Comprensibilidad

de

Integridad de la Descripción Integridad de acceso Integridad de acceso en uso Demostración de la eficacia Funciones evidentes Función comprensibilidad Comprender la entrada y salida Facilidad de función de aprendizaje Facilidad de aprendizaje para realizar una tarea en uso Eficacia de la documentación del usuario y / o sistema de ayuda Eficacia de la documentación del usuario y / o ayudar a los sistemas en uso Ayuda de accesibilidad Ayuda de frecuencia Coherencia operacional en el uso Corrección de errores Corrección de errores en el uso Disponibilidad predeterminada del valor de uso Mensaje comprensibilidad en uso No necesita explicación en mensajes de error Recuperación de error operativo en uso Tiempo entre las operaciones de un error humano en uso Capacidad de deshacer (corrección de error del usuario) Personalización Operación de reducción de procedimiento Accesibilidad física Atractivo de interacción Personalización de interfaz de aspecto Usabilidad de cumplimiento

de

Tiempo de respuesta

Aprendizaje

Operabilidad

Atractivo

Eficiencia

Cumplimiento Usabilidad Tiempo Comportamiento

Utilización de Recursos

Tiempo de respuesta (tiempo medio de respuesta) Rendimiento Rendimiento (cantidad promedio de rendimiento) Rendimiento (peor ratio de rendimiento de caso) Tiempo de respuesta Tiempo de vuelta (media para el tiempo de entrega) Tiempo de vuelta (peor caso cociente del tiempo de entrega) Tiempo de espera Dispositivos Entrada/ Salida de utilización Entrada / Salida límites de carga Entrada/Salida errores relacionados Entrada/Salida radio de cumplimiento


Mantenimiento

Cumplimiento Eficiencia Analizabilidad

de

Tiempo de espera de E / S de la utilización de los dispositivos Máxima utilización de la memoria Media de ocurrencia de errores de memoria Relación entre el error de memoria / hora Máxima utilización de la transmisión Medios de comunicación la utilización del dispositivo de equilibrio Media de ocurrencia de errores de transmisión Media de error de transmisión por tiempo Utilización de la capacidad de transmisión Eficiencia de Cumplimiento

de

Pistas de capacidad de auditoria Apoyar la función de diagnóstico Falta capacidad de análisis Falta de eficiencia de análisis Estado de capacidad de supervisión Cambiar la eficiencia del ciclo Cambiar la implementación mientras transcurre el tiempo Modificación de la complejidad Parametrizado modificable Cambio del software de capacidad de control Cambio de porcentaje de éxito Modificación de la localización del impacto(Error emergentes después del cambio) Disponibilidad de una función de prueba Vuelva a probar la eficiencia Prueba de reinicio Cumplimiento de mantenimiento

Modificación

Estabilidad

Comprobabilidad

Portabilidad

Cumplimiento Mantenimiento Adaptabilidad

Instalación Co-existencia Sustituir Cumplimiento Portabilidad

Tabla 40: Métricas Externas ISO/IEC 9126

Capacidad de adaptación de las estructuras de datos Hardware adaptabilidad ambiental Organización de adaptación al medio ambiente Trasladar la facilidad de uso Sistema de adaptación de software del medio ambiente Facilidad de instalación Facilidad de instalación, Reintentar Disponible co-existencia Uso continuo de los datos Función de la inclusión Apoyo a los usuarios la coherencia funcional Cumplimiento de portabilidad


7.5

LECCIÓN 5: MÉTRICAS INTERNAS BASADOS EN ISO/IEC 9126

Ahora se presenta las características, la sub características, y las métricas internas para evaluar software, esta tabla ha sido elaborada teniendo en cuenta la norma ISO/IEC 9126. Para el análisis de las métricas internas, también pueden ser complementados de acuerdo a las caractrísticas propias del software a evaluar. característica Funcionalidad

sub característica IDONEIDAD

PRECISIÓN INTEROPERABILIDAD

SEGURIDAD

FUNCIONALIDAD DE CUMPLIMIENTO Confiabilidad

MADUREZ

TOLERANCIA A FALLOS RECUPERACIÓN

Usabilidad

FIABILIDAD DE CUMPLIMIENTO COMPRENSIBILIDAD

APRENDIZAJE OPERABILIDAD

nombre métrica Adecuación funcional Integridad funcional de aplicación Cobertura de aplicación funcional Estabilidad de la especificación funcional (volatilidad) Precisión de cómputo Precisión Intercambiabilidad de datos (formato de base de datos) Coherencia de interfaz (protocolo) Acceso auditabilidad Acceso controlabilidad Datos de prevención de la corrupción Cifrado de datos Cumplimiento funcional Entre sistemas estándar de cumplimiento Detección de fallas Eliminación de fallos Prueba de adecuación Evitar fallas Evitar el funcionamiento incorrecto Restauración Restauración efectiva Confiabilidad de cumplimiento Integridad de la Descripción Demostración de la capacidad Funciones evidentes Función de la comprensibilidad Integridad de la documentación del usuario y / o sistema de ayuda Entrada, asegurar su validez Usuario, cancela la operación Usuario, deshacer la operación Personalización


ATRACTIVO

Eficiencia

CUMPLIMIENTO DE USABILIDAD TIEMPO DE COMPORTAMIENTO

UTILIZACIÓN DE RECURSOS

Mantenimiento

CUMPLIMIENTO DE EFICIENCIA ANALIZABILIDAD MODIFICACIÓN ESTABILIDAD COMPROBABILIDAD

Portabilidad

CUMPLIMIENTO DE MANTENIMIENTO ADAPTABILIDAD

INSTALACIÓN

CO-EXISTENCIA SUSTITUIR

Accesibilidad física Estado de operación capacidad de vigilancia Consistencia operacional Claridad en los mensajes Interfaz claridad en los elementos Recuperación de errores operacional Atractivo de interacción Aparición de personalización Usabilidad de cumplimiento Tiempo de respuesta Rendimiento de tiempo Tiempo por turno Utilización de Entradas y Salidas Utilización de mensaje de Entrada y Salida Utilización de memoria Utilización de memoria de mensajes densos Transmisión de Utilización Eficiencia de Cumplimiento Actividad de grabación Preparación de la función de diagnóstico Cambio de Registros Impacto del cambio Modificación de la localización del impacto Integridad de los incorporados en las pruebas de función Autonomía de la capacidad de prueba Prueba de observabilidad de progreso Cumplimiento de mantenimiento Capacidad de adaptación de las estructuras de datos Hardware adaptabilidad ambiental Organización de adaptación al medio ambiente Trasladar la facilidad de uso Sistema de adaptación de software del medio ambiente Facilidad de instalación, vuelva a intentar Esfuerzo de instalación Flexibilidad de instalación Disponible co-existencia Uso continuo de los datos Función de la inclusión

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 161 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ CUMPLIMIENTO PORTABILIDAD

Tabla 41: Métricas Internas ISO/IEC 9126

Cumplimiento de portabilidad


CAPITULO 8

METODOLOGIAS DE EVALUACIÓN DE LA ARQUITECTURA DEL SOFTWARE


INTRODUCCIÓN La Arquitectura de Software es una práctica joven tiene sus orígenes en la década de 1960, pero solo hasta los años 90, Dewayne Perry y Alexander Wolf, la exponen en el sentido que hoy se conoce. A partir de ese momento la Arquitectura de Software comenzó a tener auge vertiginoso tanto en la academia como en la industria, desarrollándose los de estilos arquitectónicos, los ADL (Leguajes de Descripción Arquitectónica), que aunque poco difundidos, han dado al traste con la creación de diferentes tipos de arquitecturas como las basadas en componentes. La Arquitectura de Software se convierte en un factor importante en cuanto a lograr en ella una alta calidad la importancia radica en que la arquitectura es el corazón de todo sistema informático y determina cuáles serán los niveles de calidad asociados al sistema. No sirve de nada un sistema que no cumple con los atributos de calidad que se especificaron en los requerimientos no funcionales de los clientes. Por lo que diseñar una correcta arquitectura va a determinar el éxito o fracaso de un sistema de software, en la medida que esta cumpla o no con sus objetivos. Debido a esto, para reducir los riesgos, y como buena práctica de ingeniería, es recomendable realizar evaluaciones a la arquitectura del software. En este capítulo se explica el procedimiento para realizar la evaluación de una arquitectura, destacando algunos métodos de evaluación existentes, al final se hará el estudio de una propuesta denominada MECABIC o Método de Evaluación de la Calidad de Arquitecturas Basadas en la Integración de Componentes, cuyo objetivo principal es evaluar y analizar la calidad de este tipo de Arquitectura de Software. Aquí se hará la revisión de los diferentes métodos de la evaluación de arquitecturas de software, para analizar e identificar potencialidades de los diferentes métodos o procedimientos y hacer el estudio de las características comparativas de cada una de ellas. Se realizará un estudio del estado del arte de la evaluación de arquitecturas de software. Para introducirse en el tema se tratan aspectos como los principales problemas que causa la arquitectura en un proyecto, también se define que es la evaluación de arquitecturas, sus características, objetivos que persigue. Se hace además un análisis de cuándo y por qué una determinada arquitectura debe ser evaluada y los beneficios que reporta.


8.1

LECCIÓN 1: EVALUACIÓN DE LA ARQUITECTURA DE SOFTWARE

La evaluación de software es como un estudio de factibilidad que pretende detectar posibles riesgos, y buscar recomendaciones para contenerlos, teniendo en cuenta que la evaluación se realiza antes de la implementación de la solución. El objetivo de evaluar una arquitectura es saber si puede habilitar los requerimientos, atributos de calidad y restricciones para asegurar que el sistema construido cumple con las necesidades de las personas que están relacionadas con el sistema. La evaluación de una arquitectura de software es una tarea donde se pretende medir propiedades del sistema en base a especificaciones abstractas, como por ejemplo los diseños arquitectónicos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos de tipo cualitativo, cuantitativo, o máximos y mínimos teóricos. La medición cualitativa se aplica para la comparación entre arquitecturas candidatas y tiene relación con la intención de saber la opción que se adapta mejor a cierto atributo de calidad. La medición cuantitativa busca la obtención de valores que permitan tomar decisiones en cuanto a los atributos de calidad de una arquitectura de software, el esquema general es la comparación con márgenes establecidos, como lo son los requerimientos de desempeño, para establecer el grado de cumplimiento de una arquitectura candidata, o tomar decisiones sobre ella. La medición de máximo y mínimo teórico contempla los valores teóricos para efectos de la comparación de la medición con los atributos de calidad especificados, el conocimiento de los valores máximos o mínimos permite el establecimiento claro del grado de cumplimiento de los atributos de calidad. El propósito de realizar evaluaciones a la arquitectura, es para identificar y analizar riesgos potenciales en su estructura y sus propiedades, que afecten al software resultante, verificar que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar el grado de stisfacción de los atributos de calidad. Un atributo de calidad es una característica de calidad que afecta a un elemento, donde el término “característica” se refiere a aspectos no funcionales y el termino “elemento” a componente. La evaluación de la arquitectura puede realizarse en cualquier momento, pero se propone dos etapas distintas para realizarlas: La evaluación temprana que puede realizarse sin necesidad de que la arquitectura esté completamente especificada para efectuar la evaluación, abarca las fases tempranas de diseño y del desarrollo, y la evaluación tarde que se hace cuando la arquitectura ya esta establecida y la implementación se ha completado. Generalmente las evaluaciones a la arquitectura se hacen por miembros del equipo de desarrollo, arquitecto, diseñador, entre otros. Otro actor interesado por


los resultados de una evaluación es el cliente, ya que dependiendo de los resultados puede tomar decisiones de continuar o no con el proyecto. Las ténicas de evaluación de arquitecturas se clasifican en técnicas cualitativas y técnicas cuantitativas. Las técnicas cualitativas basadas en preguntas sobre la arquitectura (cuestionarios: abiertas y tempranas, checklist: específico del dominio de la aplicación, y escenarios: específicas del sistema, para arquitectura avanzada), y las cuantitativas que utiliza métricas como acoplamiento, cohesividad en los módulos, profundidad en herencias, modificabilidad. Generalmente las técnicas de evaluación cualitativas son utilizadas cuando la arquitectura está en construcción, mientras que las técnicas de evaluación cuantitativas se usan cuando la arquitectura ya ha sido implantada.

Figura 32: Clasificación de las Técnicas de Evaluación. Las evaluaciones pueden ser planeadas o no planeadas: Las planeadas que son aquellas que han sido planificadas por el ciclo de vida de desarrollo, siendo parte de las actividades del proyecto, y las no planeadas que se presentan cuando la arquitectura contiene varios defectos que han sido detectados en las etapas tardías del desarrollo. La arquitectura puede ser evaluada teniendo en cuenta la clasificación de los atributos de calidad, donde se hace la clasificación en dos categorías: Observables vía ejecución que son aquellos atributos que se determinan del comportamiento del sistema en tiempo de ejecución. La descripción de algunos de estos atributos se presenta en la siguiente tabla: Atributo de calidad Disponibilidad Confidencialidad

Descripción Es la medida de disponibilidad del sistema para el uso. Es la ausencia de acceso no autorizado a la información.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 166 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Funcionalidad Desempeño Confiabilidad Seguridad externa Seguridad interna

Habilidad del sistema para realizar el trabajo para el cual fue concebido. Es el grado en el cual un sistema o componente cumple con sus funciones designadas, dentro de ciertas restricciones dadas, como velocidad, exactitud o uso de memoria Es la medida de la habilidad de un sistema a mantenerse operativo a lo largo del tiempo Ausencia de consecuencias catastróficas en el ambiente. Es la medida de ausencia de errores que generan pérdidas de información Es la medida de la habilidad del sistema para resistir a intentos de uso no autorizados y negación del servicio, mientras se sirve a usuarios legítimos

Tabla 42: Descripción de atributos de calidad observables vía ejecución No observables vía ejecución: aquellos atributos que se establecen durante el desarrollo del sistema. La descripción de algunos de estos atributos se presenta en la siguiente tabla. Atributo de calidad Configurabilidad Integrabilidad Integridad Interoperabilidad Modificabilidad Mantenibilidad Portabilidad Reusabilidad Escalabilidad Capacidad de

Descripción Posibilidad que se otorga a un usuario experto a realizar ciertos cambios al sistema Es la medida en que trabajan correctamente componentes del sistema que fueron desarrollados separadamente al ser integrados. Es la ausencia de alteraciones inapropiadas de la información Es la medida de la habilidad de que un grupo de partes del sistema trabajen con otro sistema Es la habilidad de realizar cambios futuros al sistema Es la capacidad de someter a un sistema a reparaciones y evolución Es la habilidad del sistema para ser ejecutado en diferentes ambientes de computación. Estos ambientes pueden ser hardware, software o una combinación de los dos Es la capacidad de diseñar un sistema de forma tal que su estructura o parte de sus componentes puedan ser reutilizados en futuras aplicaciones Es el grado con el que se pueden ampliar el diseño arquitectónico, de datos o procedimental Es la medida de la facilidad con la que el software, al ser sometido a una serie de pruebas, puede demostrar sus fallas

Prueba

Tabla 43: Descripción de atributos de calidad no observables vía ejecución 8.2 LECCIÓN 2: TÉCNICAS DE EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE Las técnicas utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos del ingeniero de software para crear especificaciones y predicciones. Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico, sino al principio del diseño detallado del sistema.


Las técnicas existentes en la actualidad para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las arquitecturas de software. Debido al costo de realizar este tipo de evaluación, en muchos casos los arquitectos de software evalúan cualitativamente, para decidir entre las alternativas de diseño. Se han propuesto diferentes técnicas de evaluación de arquitecturas de software, algunas son: Evaluación basada en escenarios, Evaluación basada en simulación, Evaluación basada en modelos matemáticos y Evaluación basada en experiencia. 8.2.1 Evaluación basada en escenarios Un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Por ejemplo, un usuario hará la descripción en términos de la ejecución de una tarea; un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema; un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño. Un escenario consta de tres partes: El estímulo, que es la parte del escenario que explica o escribe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema, incluye la ejecución de tareas, cambios en el sistema, ejecución de pruebas, configuración, etc. El contexto, que describe qué sucede en el sistema al momento del estímulo. Y la respuesta que describe a través de la arquitectura, cómo debería responder el sistema ante el estímulo. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado. Los escenarios permiten concretar y entender atributos de calidad. Kazman y Carriere coinciden en la importancia del uso de los escenarios, no sólo para efectos de la evaluación de arquitecturas de software. Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de evaluación relevantes, a saber: el Utility Tree propuesto por Kazman, y los Profiles propuestos por Bosch. 8.2.1.1 Utility Tree: Un Utility Tree es un esquema en forma de árbol que presenta los atributos de calidad de un sistema de software, refinados hasta el establecimiento de escenarios que especifican con suficiente detalle el nivel de prioridad de cada uno. La intención del uso del Utility Tree es la identificación de los atributos de calidad más importantes para un proyecto particular. No existe un conjunto preestablecido de atributos, sino que son definidos por los involucrados en el desarrollo del sistema al momento de la construcción del árbol. El Utility Tree contiene como nodo raíz la utilidad general del sistema. Los atributos de calidad asociados al mismo conforman el segundo nivel del árbol, los cuales se refinan hasta la obtención de un escenario lo suficientemente concreto para ser analizado y otorgarle prioridad a cada atributo considerado. Cada atributo


de calidad perteneciente al árbol contiene una serie de escenarios relacionados, y una escala de importancia y dificultad asociada, que será útil para efectos de la evaluación de la arquitectura. 8.2.1.2 Perfiles (Profiles): Un perfil o profile es un conjunto de escenarios, generalmente con alguna importancia relativa asociada a cada uno de ellos. El uso de perfiles permite hacer especificaciones más precisas del requerimiento para un atributo de calidad. Los perfiles tienen asociados dos formas de especificación: Los perfiles completos que definen los escenarios importantes como parte del perfil. Esto permite al ingeniero de software realizar un análisis de la arquitectura para el atributo de calidad estudiado de una manera completa, puesto que incluye todos los posibles casos. Su uso se reduce a sistemas relativamente pequeños y sólo es posible predecir conjuntos de escenarios completos para algunos atributos de calidad. Los perfiles seleccionados que se asemejan a la selección de muestras sobre una población en los experimentos estadísticos. Se toma un conjunto de escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La aleatoriedad no es totalmente cierta por limitaciones prácticas, por lo que se fuerza la realización de una selección estructurada de elementos para el conjunto de muestra. Si bien es informal, permite hacer proposiciones científicamente válidas. Para la definición de un perfil, es necesario seguir tres pasos: definición de las categorías del escenario, selección y definición de los escenarios para la categoría y asignación del “peso” a los escenarios. La definición de categorías de escenarios divide la población de escenarios en poblaciones más pequeñas, que cubren aspectos particulares del sistema. La selección y definición de escenarios para cada categoría selecciona un conjunto de escenarios representativo para la subpoblación. Luego, en la asignación del peso a los escenarios, dependiendo del perfil, el peso de un escenario tiene diferentes significados. Se definen escalas que de alguna forma sean cuantificables y puedan ser convertidas a pesos relativos. Cada atributo de calidad tiene un perfil asociado. Algunos perfiles pueden ser usados para evaluar más de un atributo de calidad. Han sido seleccionados cinco atributos de calidad que son considerados de mayor relevancia para una perspectiva general de ingeniería de software, ellos son: desempeño (performance), mantenibilidad (maintainability), confiabilidad (reliability), seguridad externa (safety) y seguridad interna (security). La efectividad de la técnica es altamente dependiente de la representatividad de los escenarios. Existe la evaluación de funcionalidad basada en escenarios, y es utilizada en el diseño orientado a objetos para especificar comportamiento del sistema. La diferencia entre este tipo de evaluación y la evaluación arquitectónica basada en escenarios radica en que la última utiliza los escenarios para evaluar atributos de calidad, en lugar de verificar o describir


funcionalidad, además de que se usan otros escenarios para definir otros atributos de calidad. La siguiente tabla muestra para cada atributo de calidad, el perfil asociado, la forma en que se definen las categorías, el significado de los “pesos” y posibles métricas de evaluación. Atributo Mantenibilid ad

Perfil Perfil de mantenimiento (Maintainance profile)

Categorías Se organizan alrededor de las interfaces del sistema (sistema operativo, interfaces con el usuario, interfaces con otros sistemas). Los escenarios de cambio describen modificaciones en los requerimientos Descompone los escenarios de uso basado en los tipos de usuario y/o interfaces del sistema

Pesos Indican la probabilidad de ocurrencia del cambio de escenario en un período de tiempo

Métricas - Impacto en término de líneas de código que tienen que cambiarse - Se requiere un estimado de líneas de código de los componentes arquitectónicos.

Desempeño

Perfil de uso (Usage profile)

Representan la frecuencia relativa del escenario

Perfil de uso (Usage profile)

Confiabilidad de los componentes, genera la confiabilidad de los escenarios de uso

Indica robustez del sistema

Seguridad Interna

Perfil de seguridad (Security profile) Perfil de uso (usage profile)

Basada en todas las interfaces del sistema

Indica la probabilidad de fallas

Seguridad Externa

Perfil de peligro (Hazard profile)

Se organizan de a acuerdo documentos de certificación (puntos de interacción del sistema con el mundo real, o componentes críticos del sistema)

Indican la probabilidad de falla u ocurrencia de consecuencias desastrosas.

- Funcionalidad de componentes - Comportamiento del sistema en respuesta a los escenarios de uso en el perfil - Promedio y peor caso de latencia por sincronización y sobrecarga en el sistema - Datos estimados de confiabilidad del componente - Datos históricos de confiabilidad del componente Depende del aspecto de seguridad a ser evaluado. Por ejemplo, la disponibilidad puede evaluarse en términos del número de veces que se ejecutan operaciones de seguridad. Bosch (2000) no establece ejemplos

Confiabilida d

la


Tabla 44: Perfiles, categorias, Pesos, y Métricas Asociados a atributos de Calidad La evaluación basada en escenarios puede ser empleada para comparar dos arquitecturas y para la evaluación absoluta de una arquitectura. La diferencia está en que la evaluación absoluta requiere mayor cantidad de datos estimados y cuantitativos necesarios para la evaluación. La técnica se puede descompones en dos etapas: El análisis de impacto, que toma como entrada el perfil y la arquitectura de software, para cada escenario del perfil, se evalúa el impacto de la arquitectura y se obtienen los resultados. La etapa de predicción de resultados, donde los resultados serán usados para pronosticar el valor del atributo de calidad estudiado de acuerdo a las métricas existentes. 8.2.2 Evaluación basada en simulación La evaluación basada en simulación utiliza una implementación de alto nivel de la arquitectura de software. El enfoque básico consiste en la implementación de componentes de la arquitectura y la implementación del contexto del sistema donde se supone va a ejecutarse. La finalidad es evaluar el comportamiento de la arquitectura bajo diversas circunstancias. Una vez disponibles estas implementaciones, pueden usarse los perfiles respectivos para evaluar los atributos de calidad. El proceso de evaluación basada en simulación sigue los pasos mostrados en la siguiente tabla:

Definición contexto

e

Pasos implementación

del

Implementación de componentes arquitectónicos

los

Implementación de componentes arquitectónicos

los

Implementación del perfil

Simulación del sistema e inicio del perfil

Definición Consiste en identificar las interfaces de la arquitectura de software con su contexto, y decidir cómo será simulado el comportamiento del contexto en tales interfaces. La descripción del diseño arquitectónico debe definir las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripción de diseño. La descripción del diseño arquitectónico debe definir las interfaces y las conexiones de los componentes, por lo que estas partes pueden ser tomadas directamente de la descripción de diseño. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar usando simulación, el perfil asociado necesitará ser implementado en el sistema. El arquitecto de software debe ser capaz de activar escenarios individuales, así como también ejecutar un perfil completo usando selección aleatoria, basado en los pesos normalizados de los mismos. El arquitecto de software ejecutará la simulación y activará escenarios de forma manual o automática, y obtendrá resultados de acuerdo al atributo de calidad que está siendo evaluado.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 171 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Predicción de atributos de calidad

Dependiendo del tipo de simulación y del atributo de calidad evaluado, se puede disponer de cantidades excesivas de datos, que requieren ser condensados. Esto permite hacer conclusiones acerca del comportamiento del sistema.

Tabla 45: Pasos para la Evaluación Basada en Simulación En el ámbito de las simulaciones, se encuentra la técnica de implementación de prototipos. Esta técnica implementa una parte de la arquitectura de software y la ejecuta en el contexto del sistema. Es utilizada para evaluar requerimientos de calidad operacional, como desempeño y confiabilidad. 8.2.3 Evaluación basada en modelos matemáticos La evaluación basada en modelos matemáticos se utiliza para evaluar atributos de calidad operacionales. Permite una evaluación estática de los modelos de diseño arquitectónico, y se presentan como alternativa a la simulación, dado que evalúan el mismo tipo de atributos. Ambos enfoques pueden ser combinados, utilizando los resultados de uno como entrada para el otro. El proceso de evaluación basada en modelos matemáticos sigue los pasos mostrados en la siguiente tabla: Pasos Selección y adaptación del modelo matemático

Representación de la arquitectura en términos del modelo

Estimación de los datos de entrada requeridos

Predicción de atributos de calidad

Definición Existen varios modelos matemáticos para medir sus atributos de calidad, los cuales tienden a ser muy elaborados y detallados, así como también requieren de cierto tipo de datos y análisis. Parte de estos datos requeridos no están disponibles a nivel de arquitectura, y la técnica requiere mucho esfuerzo para la evaluación arquitectónica, por lo cual se debe adaptar el modelo. El modelo matemático seleccionado y adaptado no asume necesariamente que el sistema que intenta modelar consiste de componentes y conexiones. Por lo tanto, la arquitectura necesita ser representada en términos del modelo. El modelo matemático aún cuando ha sido adaptado, requiere datos de entrada que no están incluidos en la definición básica de la arquitectura. Es necesario estimar y deducir estos datos de la especificación de requerimientos y de la arquitectura diseñada. Una vez que la arquitectura es expresada en términos del modelo y se encuentran disponibles todos los datos de entrada requeridos, el arquitecto está en capacidad de calcular la predicción resultante del atributo de calidad evaluado.

Tabla 46: Pasos para la Evaluación Basada en Modelos Matemáticos


Entre los instrumentos que se cuentan para las técnicas de evaluación de arquitecturas de software basada en modelos matemáticos, se encuentran las Cadenas de Markov y los denominados “Reliability Block Diagrams”. 8.2.4 Evaluación basada en experiencia En muchas ocasiones los arquitectos e ingenieros de software otorgan valiosas ideas que resultan de utilidad para evitar decisiones erradas de diseño. Aunque todas estas experiencias se basan en factores subjetivos como la intuición y la experiencia. Sin embargo, la mayoría de ellas puede ser justificada por una línea lógica de razonamiento, y pueden ser la base de otros enfoques de evaluación. Existen dos tipos de evaluación basada en experiencia: la evaluación informal, que es realizada por los arquitectos de software durante el proceso de diseño, y la realizada por equipos externos de evaluación de arquitecturas. La siguiente tabla muestra los instrumentos utilizados por las diferentes técnicas de evaluación. Técnica de Evaluación Basada en Escenarios Basada en Simulación Basada en Modelos Matemáticos Basada en Experiencia

Instrumento de Evaluación - Profiles - Utility Tree - Lenguajes de Descripción Arquitectónica (ADL) - Modelos de colas - Cadenas de Markov - Reliability Block Diagrams - Intuición y experiencia - Tradición - Proyectos similares

Tabla 47: Instrumentos asociados a las distintas técnicas de evaluación de arquitecturas de software 8.3 LECCIÓN 3: MÉTODOS DE EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE Los métodos de análisis de arquitecturas de software hace que el proceso sea repetible, y ayuda a garantizar que las respuestas correctas con relación a la arquitectura pueden hacerse durante las fases tempranas de diseño. Es en este punto donde los problemas encontrados pueden ser solucionados de una forma relativamente poco costosa. Un método de evaluación sirve de guía a los involucrados en el desarrollo del sistema, en la búsqueda de conflictos que puede presentar una arquitectura, y sus soluciones.


Actualmente existen múltiples métodos de evaluación han sido propuestos para la evaluación de la arquitectura del software. A continuación se presentan algunos de los más importantes:

8.3.1 Software Architecture Analysis Method (SAAM) El Método de Análisis de Arquitecturas de Software denominado SAAM, es el primero que fue ampliamente promulgado y documentado. El método fue originalmente creado para el análisis de la modificabilidad de una arquitectura, pero en la práctica ha demostrado ser muy útil para evaluar de forma rápida distintos atributos de calidad, tales como modificabilidad, portabilidad, escalabilidad e integrabilidad. El método de evaluación SAAM, se enfoca en la enumeración de un conjunto de escenarios que representan los cambios probables a los que estará sometido el sistema en el futuro. Como entrada principal, es necesaria alguna forma de descripción de la arquitectura a ser evaluada. Las salidas de la evaluación del método SAAM son las siguientes: - Una proyección sobre la arquitectura de los escenarios que representan los cambios posibles ante los que puede estar expuesto el sistema - Entendimiento de la funcionalidad del sistema, e incluso una comparación de múltiples arquitecturas con respecto al nivel de funcionalidad que cada una soporta sin modificación Si se evalúa una sola arquitectura se obtienen los lugares en los que la misma puede fallar, en términos de los requerimientos de modificabilidad. Para el caso en el que se cuenta con varias arquitecturas candidatas, el método produce una escala relativa que permite observar qué opción satisface mejor los requerimientos de calidad con la menor cantidad de modificaciones. Los pasos que contempla el método de evaluación SAAM se muestran en la siguiente tabla: 1. Desarrollo de escenarios 2. Descripción arquitectura

de

la

3. Clasificación y asignación de prioridad de los escenarios

Un escenario es una breve descripción de usos anticipados odeseados del sistema. De igual forma, estos pueden incluir cambios a los que puede estar expuesto el sistema en el futuro. La arquitectura se descibe haciendo uso de alguna notación arquitectónica que sea común a todas las partes involucradas en el análisis. Deben incluirse los componentes de datos y conexiones relevantes, así como la descripción del comportamiento general del sistema. La clasificación de los escenarios puede hacerse en dos clases: Un escenario directo, que es el que puede satisfacerse sin la necesidad de modificaciones en la arquitectura. Un escenario indirecto, que es aquel que requiere modificaciones

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 174 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ en la arquitectura para poder satisfacerse.

4. Evaluación individual de los escenarios indirectos

5. Evaluación de la interacción entre escenarios

6. Creación de la evaluación global

Los escenarios indirectos son de especial interés para SAAM, pues son los que permiten medir el grado en el que una arquitectura puede ajustarse a los cambios de evolución que son importantes para los involucrados en el desarrollo. Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula su costo. Una modificación sobre la arquitectura significa que debe introducirse un nuevo componente o conector, o que alguno de los existentes requiere cambios en su especificación. Cuando dos o más escenarios indirectos proponen cambios sobre un mismo componente, se dice que interactúan sobre ese componente. Es necesario evaluar este hecho, puesto que la interacción de componentes semánticamente no relacionados revela que los componentes de la arquitectura efectúan funciones semánticamente distintas. De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel correcto de descomposición estructural. Debe asignársele un peso a cada escenario, en términos de su importancia relativa al éxito del sistema. Esta asignación de peso suele hacerse con base en las metas del negocio que cada escenario soporta. En el caso de la evaluación de múltiples arquitecturas, la asignación de pesos puede ser utilizada para la determinación de una escala general.

Tabla 48: Pasos contemplados por el método de evaluación SAAM 8.3.2 Architecture Trade-off Analysis Method (ATAM) El Método de Análisis de Acuerdos de Arquitectura denominado ATAM, está inspirado en tres áreas distintas: los estilos arquitectónicos, el análisis de atributos de calidad y el método de evaluación SAAM. El método ATAM revela la forma en que una arquitectura específica satisface ciertos atributos de calidad, y provee una visión de cómo los atributos de calidad interactúan con otros; osea, los tipos de acuerdos que se establecen entre ellos. El método se concentra en la identificación de los estilos arquitectónicos o enfoques arquitectónicos utilizados. Estos elementos representan los medios empleados por la arquitectura para alcanzar los atributos de calidad, así como también permiten describir la forma en la que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas. El método de evaluación ATAM comprende nueve pasos, agrupados en cuatro fases. La siguiente tabla presenta las fases y sus pasos enumerados, junto con su descripción. Fase 1: Presentación 1. Presentación del ATAM 2. Presentación de las metas del negocio

El líder de evaluación describe el método a los participantes, trata de establecer las expectativas y responde las preguntas propuestas. Se realiza la descripción de las metas del negocio que motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectónico.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 175 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ 3. Presentación arquitectura

de

la

El arquitecto describe la arquitectura, enfocándose en cómo ésta cumple con los objetivos del negocio.

Fase 2: Investigación y análisis 4. Identificación de los enfoques Estos elementos son detectados, pero no analizados. arquitectónicos 5. Generación del Utility Tree Se elicitan los atributos de calidad que engloban la “utilidad” del sistema (desempeño, disponibilidad, seguridad, modificabilidad, usabilidad, etc.), especificados en forma de escenarios. Se anotan los estímulos y respuestas, así como se establece la prioridad entre ellos. 6. Análisis de los enfoques Con base en los resultados del establecimiento de prioridades arquitectónicos del paso anterior, se analizan los elementos del paso 4. En este paso se identifican riesgos arquitectónicos, puntos de sensibilidad y puntos de balance. Fase 3: Pruebas 7. Lluvia de ideas y establecimiento de prioridad de escenarios. 8. Análisis de los enfoques arquitectónicos Fase 4: Reporte 9. Presentación resultados

de

los

Con la colaboración de todos los complementa el conjunto de escenarios.

involucrados,

se

Este paso repite las actividades del paso 6, haciendo uso de los resultados del paso 7. Los escenarios son considerados como casos de prueba para confirmar el análisis realizado hasta el momento. Basado en la información recolectada a lo largo de la evaluación del ATAM, se presentan los hallazgos a los participantes.

Tabla 49: Pasos del método de evaluación ATAM 8.3.3 Active Reviews for Intermediate Designs (ARID) El método ARID es conveniente para realizar la evaluación de diseños parciales en las etapas tempranas del desarrollo. En ocasiones, es necesario saber si un diseño propuesto es conveniente, desde el punto de vista de otras partes de la arquitectura. ARID es un híbrido entre Active Design Review (ADR) y Architecture Trade-Off Method (ATAM). ADR es utilizado para la evaluación de diseños detallados de unidades del software como los componentes o módulos. Las preguntas giran en torno a la calidad y completitud de la documentación y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseño propuesto. Tanto ADR como ATAM proveen características útiles para el problema de la evaluación de diseños preliminares. En el caso de ADR, los involucrados reciben documentación detallada y completan cuestionarios, cada uno por separado. En el caso de ATAM, está orientado a la evaluación de toda una arquitectura. Ante la necesidad de evaluación en las fases tempranas del diseño, se propone la utilización de las características que proveen tanto ADR como ATAM


por separado. De la combinación de ambas filosofías surge ARID, para efecto de la evaluación temprana de los diseños de una arquitectura de software. La siguiente tabla muestra los pasos del método de evaluación ARID, con una breve descripción de cada uno:

Fase 1: Actividades Previas 1. Identificación de los encargados de la revisión 2. Preparar Diseño

el

3. Preparar base

los

informe

de

escenarios

4. Preparar los materiales Fase 2: Revisión 5. Presentación del ARID 6. Presentación del diseño

7. Lluvia de ideas establecimiento de prioridad de escenarios

8. Aplicación escenarios

de

y

los

Los encargados de la revisión son los ingenieros de software que se espera que usen el diseño, y todos los involucrados en el diseño. En este punto, converge el concepto de encargado de revisión de ADR e involucrado del ATAM. El diseñador prepara un informe que explica el diseño. Se incluyen ejemplos del uso del mismo para la resolución de problemas reales. Esto permite al facilitador anticipar el tipo de preguntas posibles, así como identificar áreas en las que la presentación puede ser mejorada. El diseñador y el facilitador preparan un conjunto de escenarios base. De forma similar a los escenarios del ATAM y el SAAM, se diseñan para ilustrar el concepto de escenario, que pueden o no ser utilizados para efectos de la evaluación. Se reproducen los materiales preparados para ser presentados en la segunda fase. Se establece la reunión, y los involucrados son invitados. Se explica los pasos del ARID a los participantes. El líder del equipo de diseño realiza una presentación, con ejemplos incluidos. Se propone evitar preguntas que conciernen a la implementación o argumentación, así como alternativas de diseño. El objetivo es verificar que el diseño es conveniente. Se establece una sesión para la lluvia de ideas sobre los escenarios y el establecimiento de prioridad de escenarios. Los involucrados proponen escenarios a ser usados en el diseño para resolver problemas que esperan encontrar. Luego, los escenarios son sometidos a votación, y se utilizan los que resultan ganadores para hacer pruebas sobre el diseño. Comenzando con el escenario que contó con más votos, el facilitador solicita pseudo-código que utiliza el diseño para proveer el servicio, y el diseñador no debe ayudar en esta tarea. Este paso continúa hasta que ocurra alguno de los siguientes eventos: - Se agota el tiempo destinado a la revisión - Se han estudiado los escenarios de más alta prioridad - El grupo se siente satisfecho con la conclusión alcanzada.

9. Resumen

Puede suceder que el diseño presentado sea conveniente, con la exitosa aplicación de los escenarios, o por el contrario, no conveniente, cuando el grupo encuentra problemas o deficiencias. Al final, el facilitador recuenta la lista de puntos tratados, pide opiniones de los participantes sobre la eficiencia del ejercicio

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 177 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ de revisión, y agradece por su participación.

Tabla 50: Pasos del método de evaluación ARID

8.3.4 Modelo de Negociación WinWin El modelo WinWin provee un marco de referencia general para identificar y resolver conflictos de requerimientos. El modelo utiliza la teoría “W”, que pretende que todo involucrado salga ganador. De esta forma, asiste a los involucrados en el desarrollo a identificar y negociar distintos aspectos, reconciliando conflictos entre las opciones de ganancias para todos. Aunque el modelo propone la resolución de posibles conflictos, no siempre es posible llegar a un acuerdo. En este sentido, el método CBAM provee medios para establecer los balances necesarios, y un marco de referencia para la discusión que puede llevar a una posible solución del problema. 8.3.5 Cost-Benefit Analysis Method (CBAM) El método de análisis de costos y beneficios denominado (CBAM), es un marco de referencia que no toma decisiones por los involucrados en el desarrollo del sistema. Uno de los elementos que introduce el método son las llamadas estrategias arquitectónicas, que consisten en posibles opciones para la resolución de conflictos entre atributos de calidad presentes en una arquitectura. El método CBAM abarca los siguientes aspectos: Selección de escenarios, Evaluación de los beneficios de los atributos de calidad, Cuantificación de los beneficios de las estrategias arquitectónicas, Cuantificación de los costos de las estrategias arquitectónicas y las implicaciones de calendario, Cálculo del nivel de deseabilidad y la Toma de decisiones. La siguiente tabla muestra los pasos pertenecientes al marco de referencia para evaluación de arquitecturas de software para este método: 1. Selección de escenarios

2. Identificación de los conflictos entre atributos de calidad 3. Exploración de las opciones en busca de la resolución de conflictos 4. Medición de los beneficios de los atributos de calidad

Cada involucrado en el desarrollo identifica sus condiciones de ganancia. Este paso provee las bases para la identificación de las características ideales del sistema esperadas por los involucrados. La lista de condiciones de ganancia es revisada con la intención de identificar conflictos entre atributos de calidad. Los conflictos son categorizados en directos o potenciales. Con base en los conflictos detectados en el paso anterior, los involucrados pueden generar opciones de resolución de conflictos, o estrategias arquitectónicas. Para ayudar en el proceso de toma de decisiones, los involucrados en el desarrollo deben calcular tanto los costos como los beneficios de las estrategias arquitectónicas elaboradas en el paso


5. Cuantificación beneficios

de

los

6. Cuantificación de costos e implicaciones de calendario

7. Cálculo del nivel de Deseabilidad 8. Alcanzar un acuerdo

anterior. Para esto, se calcula una escala de atributos de calidad, donde se asigna un puntaje a cada atributo. Las escalas establecidas son utilizadas para la evaluación de las estrategias arquitectónicas planteadas en el paso 3. El resultado de la evaluación permite observar el beneficio de cada uno de los cambios arquitectónicos propuestos. En este paso se calculan los costos e implicaciones de calendario que aplican para cada una de las estrategias arquitectónicas propuestas en el paso 3. No se propone un modelo específico para la realización de la estimación de costos y tiempo. Este paso contempla una métrica especial, que se refleja como el cociente entre los beneficios y los costos obtenidos. Las estrategias arquitectónicas que resulten con valores mayores se proponen como las más recomendables. La recomendación general es la documentación del proceso. La acumulación de evidencia permite el establecimiento de un posible consenso, a la hora de la toma de decisiones sobre la arquitectura de un sistema de software.

Tabla 51: Pasos del método de evaluación CBAM 8.3.6 Método Diseño y Uso de Arquitecturas de Software propuesto por Bosch Bosch plantea, en su método de diseño de arquitecturas de software, que el proceso de evaluación debe ser visto como una actividad iterativa, que forma parte del proceso de diseño, también iterativo. Una vez que la arquitectura es evaluada, pasa a una fase de transformación, asumiendo que no satisface todos los requerimientos. Luego, la arquitectura transformada es evaluada de nuevo. El proceso de evaluación propuesto por Bosch se divide en dos etapas, que son presentadas en la siguiente tabla: Etapa I 1. Selección de atributos de calidad

2. Definición de los perfiles 3. Selección de una técnica de evaluación

Etapa II 4. Ejecución de la evaluación

Deben seleccionarse aquellos atributos que se consideran cruciales para el éxito del sistema, y cuya satisfacción resulte poco clara a nivel de arquitectura. Resulta necesario porque es poco factible y poco útil evaluar todos los atributos de calidad, dado que requiere una gran cantidad de tiempo. Para cada atributo de calidad seleccionado, se definen los perfiles respectivos para efectos de la evaluación. Para la evaluación de los atributos de calidad dependientes del diseño de la arquitectura se recomienda utilizar la evaluación basada en escenarios, así como también los modelos basados en métricas o modelos matemáticos. Los atributos de calidad operacionales (observables vía ejecución) pueden evaluarse con técnicas de simulación o modelos matemáticos. La selección de la técnica, y la implementación concreta de ésta depende del objetivo y exactitud de la evaluación. Para cada atributo de calidad, las técnicas arrojan valores


5. Obtención de resultados

cuantitativos. Los resultados se resumen en una tabla que contiene el nivel requerido, el nivel predicho, y un indicador, que puede tener diversos significados: si el atributo se satisface o no, si necesita ser negociado con el cliente, o existencia de alguna relación negativa con otro atributo de calidad. El arquitecto puede decidir acerca de la realización de transformaciones sobre la arquitectura actual, y efectuar una nueva evaluación. Una vez que concluye el proceso de evaluación, con los resultados obtenidos es posible decidir entre la continuación, renegociación o cancelación del proyecto.

Tabla 52: Etapas contempladas por el método de evaluación de arquitecturas propuesto por Bosch 8.3.7 Método de Comparación de Arquitecturas Basada en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software Losavio proponen un método para evaluar y comparar arquitecturas de software candidatas, que hace uso del modelo de especificación de atributos e calidad adaptado del modelo ISO/IEC 9126. Para la evaluación se plantea la especificación de los atributos de calidad haciendo uso de un modelo basado en estándares internacionales ISO/IEC 9126 que ofrecen una vista amplia y global de los atributos de calidad, tanto a usuarios como arquitectos del sistema, para efectos de la evaluación. El método contempla siete actividades que son mostradas y descritas en la siguiente tabla: Actividades 1. Analizar los requerimientos funcionales y no funcionales principales del sistema, para establecer las metas de calidad 2. Utilizar el modelo de calidad ISO/IEC 9126 adaptado para arquitecturas de software. Algunas métricas pueden definirse con mayor nivel de detalle 3. Presentar las arquitecturas candidatas iniciales 4. Construir la tabla comparativa para las arquitecturas candidatas 5. Establecer prioridades para las subcaracterísticas de calidad tomando en cuenta los requerimientos de calidad del sistema 6. Analizar los resultados obtenidos y resumidos en la tabla, de acuerdo con las prioridades establecidas

Tabla 53: Actividades del Método de Comparación de Arquitecturas Basado en el Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio 8.4 LECCIÓN 4: MÉTODOS DE EVALUACIÓN DE ARQUITECTURA DE UN ATRIBUTO ESPECÍFICO


Existen otros métodos de evaluación de arquitectura del software, que evalúan solamente uno de los atributos de calidad específicado por el evaluador, algunos de ellos son:

8.4.1 Architecture Level Modifiability Analysis ALMA Este método es el resultado de los trabajo de investigación de Brengtsson y Lassing, el atributo de calidad que analiza este método es la facilidad de modificación, este atributo se refiere a la capacidad de un sistema para ser ajustado debido a cambios en los requerimientos, o en el entorno, así como la adición de nuevas funcionalidades. ALMA es un método de evaluación orientado a metas, que se apoya en el uso de escenarios de cambio, los cuales escriben los eventos posibles que provocarían cambios al sistema, y como se llevarían a cabo estos. El mismo consta de cinco pasos como se muestran en la siguiente figura:

Figura 33: Método de evaluación de arquitecturas ALMA 8.4.2 Performance Assessment of Software Architecture PASA PASA es el resultado del trabajo de Williams y Smith, el mismo utiliza diversas técnicas de evaluación, tales como la aplicación de estilos


arquitectónicos, anti-patrones, guías de diseño y modelos. El atributo de calidad que analiza este método es el desempeño, se interesa en saber qué tanto tiempo le toma al sistema software responder cuando una o varios eventos ocurren, así como determinar el número de eventos procesados en un intervalo de tiempo dado. Este método también se basa en escenarios y puede aplicarse de forma temprana o tardía. Los escenarios generados en este método sirven como punto de partida para la construcción de modelos de desempeño. Uno de los requisitos o precondiciones es que la arquitectura debe estar previamente documentada y en caso de que no esté completa se debe extraer el resto de la información a los miembros del equipo.

Figura 34: Método de evaluación de arquitecturas PASA 8.4.3 Scenario based Architecture Level Usability Analysis SALUTA Es el primer método desarrollado para evaluar arquitecturas desde la perspectiva de la facilidad del uso del sistema, siendo el resultado de los estudios de Folmer y Gurp. Este método hace uso de marcos de referencia que expresan las relaciones que existen entre facilidad de uso y Arquitectura de Software. Dichos marcos de referencias incluyen un conjunto integrado de soluciones de diseño como patrones de diseños u propiedades que tienen un efecto positivo sobre la facilidad de uso en un sistema software. SALUTA analiza cuatro atributos que están directamente relacionados con la facilidad de uso de un sistema de software: Facilidad de aprendizaje, Eficiencia


de uso, Confiabilidad y Satisfacción. El método se basa en escenarios, que en este caso, son escenarios de uso que agrupan uno a más perfiles de uso valga la redundancia, donde cada uno representa la facilidad de uso requerida por el sistema. Se recomienda utilizarlo una vez que se ha especificado la arquitectura, pero antes de implementarla. La siguiente figura muestra los cuatro pasos del método:

Figura 35: Método de evaluación de arquitecturas SALUTA 8.4.4 Survivable Network Analysis SNA Es un método desarrollado por el CERT (Computer Emergency Response Team) que forma parte del SEI (Software Engineering Institute). Este método ayuda a identificar la capacidad de supervivencia en un sistema, analizando su arquitectura. La supervivencia es la capacidad que tiene un sistema para completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes. Para evaluar esta supervivencia SNA utiliza tres propiedades claves: Resistencia, Reconocimiento y Recuperación. Este procedimiento puede ser realizado después de la especificación de la arquitectura, durante la implementación de esta, o posteriormente. SNA se basa en la técnica de escenarios de uso, e identifica dos tipos de escenarios: Escenarios normales, que se componen de una serie de pasos donde los usuarios invocan servicios y obtienen acceso a activos, tales como bases de datos, Escenarios de intrusión, en los que se representan diferentes tipos de ataques al sistema. En la siguiente tabla se muestra cada uno de los pasos del método:


Figura 36: Método de evaluación de arquitecturas SNA La siguiente tabla muestra una tabla comparativa de cada uno de los métodos de evaluación de arquitectura mencionados anteriormente: ALMA Predecir el costo de mantenimiento, evaluar riesgos, comparación entre arquitecturas

PASA Analizar la arquitectura con respecto a los objetivos de desempeño de un sistema

SALUTA Predecir la facilidad de uso de un sistema analizando la arquitectura

Atributo de calidad Técnica de evaluación

Facilidad modificación Escenarios cambio

de

desempeño

Facilidad de uso

de

escenarios

Escenarios uso

entradas

Especificación de la arquitectura, requerimientos no funcionales

Meta

Especificación la arquitectura

de

de

Especificación de la arquitectura, requerimientos no funcionales relacionados con la facilidad de uso

SNA Identificar la capacidad de supervivencia de un sistema ante presencia de ataques, fallas o accidentes supervivencia Escenarios de uso normales y escenarios de intrusión Especificación de la arquitectura

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 184 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ salidas

Personas involucradas

Duración Validación del método

Dependiendo de la meta de evaluación se generan los resultados Arquitecto y equipo de desarrollo

Hallazgos encontrados, pasos específicos a seguir y recomendaciones Arquitecto, equipo de desarrollo y administradores del proyecto

No especificado Sistemas de control embebido, sistemas médicos, telecomunicacione s, sistemas administrativos

7 días Sistemas basados en la web, aplicaciones financieras, y sistemas en tiempo real

Grado de facilidad de uso que soporta la arquitectura evaluada Arquitecto, ingenieros de requerimientos o ingenieros responsables por la facilidad de uso No especificado Algunos casos de estudio que incluyen principalmente sistemas web

Modificaciones recomendadas de la arquitectura y mapa de supervivencia Arquitecto, diseñador principal, propietarios del sistema, usuarios No especificado Sistemas comerciales y de gobierno

Tabla 54: Comparación entre los métodos ALMA, PASA, SALUTA y SNA. 8.5

LECCIÓN 5: MÉTODO DE EVALUACIÓN DE ARQUITECTURA MECABIC

MECABIT es uno de los métodos para evaluar Arquitecturas de Software Basadas en Componentes con el objetivo de que sea aplicado en Arquitecturas Orientadas a Servicios. Este análisis se realiza desde el punto de vista, que bajo ciertas y determinadas situaciones o condiciones, se puede ver un servicio como un componente. El MECABIC está inspirado en ATAM, al método se le incluyeron en algunos de sus pasos un enfoque de integración de elementos de diseño, inspirado en la construcción de partes arquitectónicas adoptado por el Architecture Based Design (ABD). Además se propone un árbol de utilidad inicial basado en el modelo de calidad ISO/IEC 9126 instanciado para Arquitectura de Software propuesto por Losavio. La adopción de este modelo por parte del MECABIC permite concentrarse en características que dependen exclusivamente de la arquitectura, y al ser un estándar facilita la correspondencia con características de calidad consideradas por los métodos estudiados. Los escenarios incluidos en este árbol son específicos para aplicaciones basadas en componentes. En el método MECABIC participan tres grupos de trabajo: Los arquitectos, el evaluador y los relacionados. Para la especificación de la calidad se hace uso de un árbol de utilidad, el cual tiene como nodo raíz la “bondad” o “utilidad” del sistema. En el segundo nivel del árbol se encuentran los atributos de calidad. Las hojas del árbol de utilidad son escenarios, los cuales representan mecanismos mediante los cuales extensas declaraciones de cualidades son hechas específicas y posibles de evaluar. La generación del árbol de calidad incluye un paso que permite establecer prioridades. Para el análisis de la arquitectura se utiliza la


técnica de escenarios, soportada por cuestionarios, para identificar lo que desean los participantes. La siguiente tabla muestra los participantes en el método MECABIT:

Equipo

Definición

Arquitectos

Responsables de generar y documentar una Arquitectura de Software para el sistema estudiado. Integrado por personas expertas en asuntos de calidad quienes guiarán el proceso de evaluación de la arquitectura Son las personas involucradas de alguna manera con el sistema: programadores, usuarios, gerentes, entre otros.

Evaluador Relacionados

Fases en las que participan Todas Todas Fases 1, 3 y 4.

Tabla 55: Grupos de Trabajo en el Método MECABIT. 8.5.1 Fases del Método El método consta de cuatro fases, la de presentación, la de investigación y análisis, la de prueba y la presentación de resultados. A continuación se describe cada una de las fases: 8.5.1.1 Fase1 – Presentación: En esta fase se da a conocer el método entre todos los grupos, el sistema y su organización, y finalmente se presenta cuál es la arquitectura que debe ser evaluada. En esta fase se realiza una presentación del método MECABIC para que los participantes comprendan en qué punto de la aplicación del método se encuentran en cada momento.También se da a conocer la arquitectura inicial a evaluar y qué características de calidad se esperan lograr. 8.5.1.2 Fase2 – Investigación y Análisis: En esta fase se determina de qué manera se va estudiar la arquitectura, se pide a las personas que están relacionadas con el sistema, ya sea un desarrollador, usuario o gerente, que expresen de una manera precisa que escenarios de calidad se desean y se analiza si la arquitectura es apropiada o se requieren modificaciones para que lo sea. En esta fase sólo participan el grupo evaluador y grupo de arquitectos. En esta fase se identifican elementos de diseño que ayuden a analizar la arquitectura, se especifican los requerimientos planteados durante el paso 2 y se analiza cómo responden los elementos de diseño considerados a los requerimientos. 8.1.1.3 Fase3 - Prueba: Consiste en la revisión de la segunda fase y en ella participan todos los grupos. 8.1.1.4 Fase4 – Presentación de Resultados: En la última fase se lleva a cabo a presentación de los resultados. En esta fase participan todos los grupos. Fase de Generación de la arquitectura final y reporte. En este momento se cuenta ya con un análisis de todas las decisiones que se han producido hasta el momento. Si no


hay conflictos y se puede concluir que existe una arquitectura adecuada para los requerimientos de calidad de las personas involucradas en la evaluación, entonces se puede pasar al paso 10 directamente. Si por el contrario en algún elemento de diseño existen decisiones en las que resulte favorecido algún requerimiento, entonces los usuarios y desarrolladores son los que tienen que determinar o acordar cuáles requerimientos favorecer. En la siguiente tabla se muestra el método MECABIT, con cada una de las fases y el detalle de los pasos que se deben dar para la aplicación del método: Fase 1: Fase de presentación 1. Presentación del método.

2. Presentación de directrices del negocio.

3. Presentación arquitectura.

de

las

la

En el primer paso el director de evaluación presenta el método ante los participantes con el proyecto. Se explica el proceso que debe cumplir cada participante del proyecto, se responden preguntas y se establecen las expectativas y el contexto sobre las actividades o tareas restantes. La finalidad es que todas las personas involucradas en el sistema comprendan la secuencia de los pasos a seguir, los instrumentos utilizados en cada paso y las salidas del método. Se pide a las personas que comenten sus expectativas o que hagan preguntas particulares acerca de lo que esperan de la aplicación del método. Cada persona que posee una responsabilidad sobre la evaluación, necesitan comprender el contexto del sistema y los aspectos primarios del contexto del negocio que motivan su desarrollo. Se explica a las personas el contexto del sistema y los requerimientos del negocio dentro del cual va a funcionar el sistema. Algunos tópicos que debería contener esta presentación son: las funcionalidades más importantes del sistema, los objetivos del negocio y el contexto relacionado con el proyecto, el grupo dirigente de los desarrolladores y usuarios, las directrices arquitectónicas, restricciones técnicas, gerenciales, económicas y políticas y obertura de la evaluación y límites del sistema. El arquitecto o grupo de representantes explican a las personas como desarrollador, usuario o gerente, cuál es la arquitectura evaluada. Debe contener una clara diferenciación estructural, la cual deberá mostrar claramente las relaciones entre componentes de la arquitectura y las diferentes granularidades involucradas. El arquitecto cubre restricciones técnicas y los alcances arquitectónicos usados para alcanzar los requerimientos. El arquitecto debe transmitir lo esencial y de esta manera abreviada la información de la arquitectura que requiere el equipo.

Fase2: Investigación y Análisis 4. Identificación de Contemplan alternativas de diseño de la arquitectura, que elementos de diseño. posteriormente serán analizadas para ver cómo responden a los requerimientos de calidad. La arquitectura debe ser evaluada completamente desde el sistema con sus componentes de mayor granularidad, hasta el mínimo nivel de granularidad que corresponde a los componentes. Se propone identificar elementos de diseño dentro de una arquitectura basada en componentes, como un componente, y el conjunto de componentes con los cuales interactúa, un conjunto de asociaciones que sea de interés sobre alguna característica de


5. Generación del árbol de utilidad.

calidad particular o conjunto de decisiones que tenga influencia considerable sobre otros elementos de diseño. Para identificar un elemento de diseño se considera los servicios ofrecidos por los componentes disponibles y las diferentes opciones para definir los servicios de los componentes desarrollados para el sistema. La manera de documentar los elementos de diseño depende de la importancia que pueda tener dentro de la evaluación, del conjunto de decisiones o adaptaciones a realizar, y del conocimiento de las personas que están relacionadas con el sistema y estén en la evaluación. El árbol de utilidad inicial especifico a partir del cual seleccionan un conjunto de escenarios de interés, está basado en el modelo de calidad ISO/IEC 9126-1 para arquitecturas de software. Se asume que al aplicar el método, las funcionalidades presentes en el sistema son las que necesitan los usuarios, y no se incluye escenarios de aptitud (subcaracterística de funcionalidad). Posteriormente, se consideran escenarios no contemplados en el árbol inicial de utilidad. En este paso el grupo evaluador presenta los diferentes escenarios a considerar al resto de los participantes y se decide cuáles son los que serán incluidos en el árbol de utilidad. Este paso brinda la posibilidad de verificar si es necesario incluir en el árbol de utilidad algún otro escenario. La selección del resto de los escenarios puede realizarse por votación como propone originalmente el ATAM. Luego se organizan los escenarios de calidad introducidos no contemplados en la tabla de generación del árbol de utilidad inicial por características de calidad. Posteriormente, se procede a priorizarlos, es decir, ordenar los escenarios ya que de esta manera se puede tener una orientación para tomar decisiones arquitectónicas, y personas pueden determinar de lo que esperan del sistema, y obtener una idea sobre en qué medida va a ser satisfecho. Posteriormente se procede a asignar un orden a los escenarios de calidad de un sistema utilizando dos criterios: Evaluar el riesgo de no considerar el escenario donde se responde las preguntas: ¿qué pasa si este escenario no se cumple?, ¿cuántas personas se ven afectadas?, ¿es posible compensar el no responder a este escenario?), Evaluar el esfuerzo necesario para lograr cumplir con el escenario (se determina que cambios o integraciones de nuevos componentes se deben realizar para satisfacer el escenario).

6. Análisis de elementos de diseño para ASBC.

Finalmente, se construye el árbol de utilidad con las salidas del paso anterior. La prioridad del escenario define en este método como un par (X, Y) en el cual X define el esfuerzo de satisfacer el escenario, y la Y indica los riesgos que se corren al excluirlos del árbol de utilidad. Los posibles valores para X e Y son A (Alto), B (Bajo) y M (Medio). Se analizan los elementos de diseño identificados en el paso 4 o de nuevos elementos de diseño que puedan ser identificados, para determinar cómo influyen sobre la realización de los escenarios de calidad presentes en el árbol de utilidad generado en el paso 5.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 188 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Los componentes proveen un conjunto de puertos que se deben ir extendiendo para proporcionar nuevos servicios, los cuales a su vez pueden ser ofrecidos para que otros componentes los extiendan. Se debe evaluar un conjunto de opciones que indiquen una manera de definir una relación entre puertos, de acuerdo a algún criterio de calidad. Los escenarios de calidad deben ser aplicados a la arquitectura que ha sido generada. El equipo de evaluación se orienta con las preguntas de análisis propuestas por el método para determinar decisiones sobre la arquitectura. Se debe preguntar si las decisiones tomadas permiten alcanzar los escenarios de calidad planteados. Si la respuesta es negativa se deben reconsiderar cualquiera de las decisiones que han sido hechas. Las decisiones identificadas anteriormente, pueden relacionarse con determinados elementos de diseño. Se deben estudiar los riesgos que introduce la decisión en particular, o si ésta contribuye a algún riesgo ya determinado. También se pueden documentar decisiones que no han sido tomadas o asuntos no resueltos que a juicio del equipo de evaluación pueden ser resueltos en un futuro estudiando con más detalle el elemento de diseño considerado. Fase3: prueba 7. Revisión del árbol de utilidad.

8. Revisión de los elementos de diseño definidos.

Se propone utilizar escenarios de calidad para representar los intereses de todos los grupos de la evaluación y confirmar que se han evaluado los requerimientos deseados de calidad. El equipo de evaluación puede facilitar la elaboración de escenarios haciendo uso del conjunto de pasos propuestos en el paso 6. Los escenarios del árbol de utilidad que no hayan sido considerados, son colocados por las personas como desarrolladores y usuarios en el paquete de tormenta de ideas, lo que les da la oportunidad de revisar escenarios poco atendidos. Los escenarios generados se comparan con la lista inicialmente considerada en el árbol de utilidad. En caso de que la consideración y priorización coincida, entonces se puede decir los escenarios evaluados son adecuados para el grupo de interesados en el sistema. Cuando no se logra un acuerdo entre los dos grupos de desarrolladores y usuarios posiblemente no se representaron adecuadamente los intereses de los involucrados. Los desarrolladores deben analizar también los escenarios que ya han sido evaluados, para verificar que hayan recibido la importancia adecuada. Una vez que el nuevo escenario ha sido considerado se pueden presentar tres casos: El escenario duplica un escenario ya considerado en el árbol de utilidad, El escenario pasa a ser una hoja de una rama ya existente, No existe rama para el escenario debido a que no había sido considerado previamente. Los primeros dos casos sugieren que la arquitectura de software ha sido creada de acuerdo con las expectativas de los usuarios, mientras que en el tercer caso, se ha fallado al considerar algún aspecto de calidad importante y puede existir un riesgo a documentar. El equipo evaluador debe estudiar de qué manera los elementos de diseño analizados en el paso 6, promueven los escenarios propuestos por el nuevo grupo de usuarios y desarrolladores. En

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 189 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ caso que no promuevan las características de calidad deseadas, deben ser reconsiderados. Fase4: Presentación de los resultados 9. Generación de los Se decide cuál será la arquitectura adoptada por el sistema. acuerdos. Para ello se debe buscar un consenso en cuanto a las opciones que existan, en caso de que no se haya identificado alguna notablemente mejor. Si existen requerimientos de calidad que no han sido logrados se debe brindar la posibilidad de replantear los requerimientos de calidad que no hayan podido ser alcanzados, para aprovechar posibles ventajas de la arquitectura. Esta es una negociación crítica, ya que de fallar, implicaría la necesidad de replantear la arquitectura, y de tener éxito hay que cuidar que los requerimientos de calidad no resueltos sean equivalentes, para que los usuarios y desarrolladores estén contentos con el sistema. Finalmente, se documentan todos aquellos requerimientos de calidad para los cuales no es posible encontrar una solución, justificando las razones. 10. Presentación de los Se presenta un resumen de la aplicación del método, de forma resultados. oral y/o escrita. Se deben incluir entonces, los siguientes documentos a partir de los cuales se inició la evaluación: a) b) c) d) e) f) g) h) i) j)

Contexto del negocio. Requerimientos de Calidad. Restricciones. Arquitectura producida. Análisis de elementos de diseño identificados. Conjunto de escenarios negociados. Conjunto de preguntas para evaluación de atributos. Árbol de Utilidad. No-riesgos documentado. Puntos sensibles y de negociación.

Tabla 56: Fases Contempladas en el Método de evaluación de Arquitecturas MECABIT. La generación del árbol de utilidades, descrito en el punto 5 de la fase 2, acerca de la Investigación y Análisis, del método es tomada de acuerdo a la norma ISO/IEC 9126 y adaptada para la evaluación de la arquitectura de software. A continuación se muestra el árbol de utilidad aplicado para el método MECABIT. Característica Funcionalidad

Sub-característica Interoperabilidad

Precisión

Seguridad

Escenario El sistema posee componentes capaces de leer datos provenientes de otros sistemas. El sistema posee componentes capaces de producir datos para otro sistema. Los resultados ofrecidos por los componentes sistema son exactos. La comunicación entre los componentes no altera la exactitud de los datos El sistema detecta la actuación de un intruso e


Obediencia (Compliance) Fiabilidad

Madurez Tolerancia a fallas

Eficiencia

Capacidad restablecimiento recuperación

de o

Tiempo comportamiento

de

Recursos utilizados

Mantenibilidad

Habilidad de cambio, estabilidad, prueba

Portabilidad

Adaptabilidad Capacidad Instalación Co-existencia

de

impide acceso a los componentes que manejen información sensible El sistema asegura que los componentes no pierdan datos ante un ataque (interno o externo). Los componentes respetan un estándar de fiabilidad. La comunicación entre los componentes no viola los estándares de fiabilidad. Los componentes del sistema manejan entradas de datos de datos incorrectas. Todas las operaciones ejecutadas por los componentes se realizan correctamente bajo condiciones adversas. Los componentes del sistema no fallan bajo ciertas condiciones especificadas. Ante problemas con el ambiente un subconjunto determinado de los componentes puede continuar prestando sus servicios. El sistema debe recibir los servicios de sus componentes en el transcurso de un tiempo indicado. Los componentes pueden compartir recursos adecuadamente. El sistema controla que ningún componente se quede sin recursos cuando los necesita. Es posible verificar el estado de los componentes del sistema. El sistema brinda facilidad para adaptar un componente. El sistema debe facilitar la sustitución/adaptación de un componente. El sistema debe continuar funcionando correctamente aun cuando los servicios de los componentes provistos por el ambiente varíen. Los componentes pueden instalarse fácilmente en todos los ambientes donde debe funcionar. Los componentes manejan adecuadamente recursos compartidos del sistema.

Tabla 57: Subconjunto del Árbol de Utilidad Iinicial Propuesto por el Método MECABIT A continuación también se presenta una tabla de preguntas sobre los elementos de revisión del diseño identificados en el punto 8 de la fase 3, del método MECABIT. Característica Funcionalidad

Sub-característica Precisión Interoperabilidad

Preguntas de análisis ¿Puede la comunicación entre los componentes introducir imprecisiones en los servicios ofrecidos por los componentes? ¿Dónde se encuentran los componentes que permiten al sistema interactuar con otros sistemas?

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 191 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Fiabilidad

Madurez Tolerancia a fallas

Eficiencia

Tiempo comportamiento

Mantenibilidad

Habilidad de cambio, estabilidad, prueba

Portabilidad

Capacidad Instalación Co-existencia

de

de

¿Existen decisiones para minimizar el manejo incorrecto de datos en la comunicación entre componentes? ¿Cómo se detecta el funcionamiento incorrecto de un componente? ¿Cómo es la relación entre el número de componentes de las diferentes partes de la arquitectura? ¿Cómo se verifica el funcionamiento correcto de un componente? ¿Cómo se verifica el estado de una comunicación entre componentes? ¿Cómo se facilita el reemplazo de un componente? ¿Existe un mecanismo para determinar si todos los componentes del sistema se encuentran correctamente instalados? ¿Existe alguna manera de identificar las reglas para interactuar con componentes de sistemas externos a la arquitectura?

Tabla 58: Algunas Preguntas para Analizar los Elementos de Diseño Identificados


CAPITULO 3

APLICACIONES DE EVALUACIÓN DEL SOFTWARE


INTRODUCCIÓN La industria de software cada vez esta más consolidada y ofrece un sinnúmero de productos que pretenden satisfacer las necesidades en diversos campos, y por eso es necesario que se tome en consideración las diversas metodologías de evaluación que están surgiendo, ya que cada una de ella pretende evaluar productos software específicos. Actualmente el campo de la evaluación de software ha adquirido mayor madurez y debe responder a la medición de calidad de cada uno de los productos y del proceso de construcción, es por eso que en este capítulo se tratan dos aplicaciones la primera esta relacionada conla evaluación del proceso y es la aplicación de la evaluación a los diseños UML y la segunda aplicada a uno de los productos que adquiere una importacia significativa aplicada al campo educativo, son los productos software que de alguna manera complementan o suplen la educación presencial. A continuación se describirá algunos de los metodos para realizar la evaluación UML y los modelos más reconocidos para la evaluación de los productos software educativos multimedia.


9.1 LECCIÓN 1: METODOLOGÍA PARA LA EVALUACIÓN DE LA CALIDAD EN LOS MODELOS UML El campo de la calidad de las especificaciones y más concretamente, en la calidad de los modelos UML, es relativamente nuevo y solo desde 1998 se contemplan propuestas sobre la calidad en el modelado con UML, este tema es de suma actualidad y relevancia, pero carece todavía de suficiente madurez. Por eso, se ha elaborado en esta lección un seguimiento a una de las metodologías de evaluación de la calidad en los modelos UML, enmarcada dentro del proyecto denominado EVVE “Entorno para la Verificación y Validación de Especificaciones software”. A partir de los principales estándares, normas y metodologías existentes en la actualidad relacionados con la evaluación del software, se ha elaborado l a m e t o d o l o g í a E V V E , analizando las características clave de cada uno de ellos y seleccionando, adaptando e integrando los aspectos más relevantes. Las principales características de la metodologIa EVVE, se pueden resumir en los siguientes principios básicos: Está formada por un conjunto estructurado de procesos, Está orientada a la relación con el cliente y a la externalización de la evaluación de calidad, Está pensada para ser una metodologIa fácilmente adaptable, y Está soportada por un conjunto de técnicas y herramientas. La metodología EVVE proporciona un marco de trabajo donde se identifica claramente el qué, cuándo, y el quién, de cada una de las fases y actividades de los procesos, así como la secuencia de pasos que se debe seguir a la hora de llevar a cabo la evaluación. Además, está orientada a la relación con el cliente de manera que el cliente se encuentra involucrado en la toma de decisiones. La metodología contempla el modo de trabajo externalizado, de manera que para realizar la evaluación no sea necesario encontrarse en las instalaciones del cliente, sino que se pueda planificar, diseñar y realizar la evaluación externamente, poniéndose en contacto con el cliente en los momentos puntuales en los que sea necesario. La metodología de evaluación EVVE, puede ser adaptada a las distintas necesidades del cliente, existiendo unos catálogos de técnicas de evaluación que determinan el nivel y profundidad con el que se desea realizar la evaluación, las métricas de calidad que se obtendrán y las herramientas de evaluación que se utilizarán. La metodología EVVE define un marco de trabajo que permite determinar los procesos para llevar a cabo la evaluación de los modelos UML del software. La metodología, en un principio estaba pensada para trabajar con diagramas de casos de uso, diagramas de clases, y diagramas de transición de estados. La


metodología de evaluación EVVE se puede aplicar a cualquier modelo de análisis y diseño, siempre que esté especificado bajo la notación UML. Además puede ser utilizada independientemente del modelo de ciclo de vida de desarrollo seguido por la empresa cliente. De manera que no existe un proceso, fase, actividad o tarea del ciclo de vida a partir del cual se pueda empezar a aplicar la metodología de evaluación. 9.1.1 Personas, Grupos y Roles A continuación se detallan los roles y grupos identificados a lo largo del proceso de evaluación, así como las principales tareas y responsabilidades de cada uno de ellos. En la siguiente figura se observa los roles involucrados en el proceso de evaluación según la metodología EVVE, así como la relación que existe entre ellos:

Figura 37: Roles y relaciones en el proceso de evaluación. Tal y como se aprecia en la figura, la comunicación entre las empresas (cliente y evaluadora) es realizada a través del patrocinador y del evaluador jefe. Éstos a su vez serán los que se comuniquen directamente con sus equipos internos. A continuación se muestra en una tabla los roles y grupos involucrados en la metodología EVVE. Roles y Grupos Empresa cliente Patrocinador evaluación

de

la

Descripción Representa a la organización que ha expresado su intención y/o necesidad de contratar los servicios de evaluación de la calidad de los modelos UML. El patrocinador de la evaluación es el representante de la empresa cliente que se pone en contacto con la empresa evaluadora para expresar la necesidad de evaluación de la calidad de sus modelos UML. En algunos


Equipo de la empresa cliente

Empresa evaluadora

Evaluador jefe

Evaluador

Equipo de evaluación

casos, el patrocinador de la evaluación podrá disponer de un equipo de trabajo interno formado por personal propio de la empresa. Sirve de apoyo al patrocinador de la evaluación. Su principal responsabilidad consiste en analizar los resultados reportados por la empresa evaluadora para detectar defectos o inconsistencias. La existencia de este equipo no es necesaria siempre, depende de la envergadura del proyecto a evaluar. Representa la organización que ha sido contratada para llevar a cabo el proceso de evaluación. La empresa evaluadora necesitará disponer de un evaluador jefe y uno o varios evaluadores que formaran el equipo de trabajo que llevará a cabo el proceso de evaluación. Es el representante de la empresa evaluadora y líder del equipo de evaluación, cuyo objetivo es asegurar el correcto desarrollo del proceso de evaluación. Este rol debe ser ocupado por un profesional con conocimientos en el análisis y diseño con UML y con experiencia en la práctica de las principales normas y estándares sobre evaluación del producto y procesos software. Está encargado de realizar las actividades y tareas propias del proceso de evaluación. Este rol deberá ser ocupado por una persona con conocimientos de modelado UML y de la metodología de evaluación. Las principales responsabilidades son, realizar las actividades de evaluación asignadas por el evaluador jefe y recoger información del propio proceso de evaluación. Representa el equipo de la empresa evaluadora, formado por el evaluador jefe y un conjunto de uno o varios evaluadores de calidad (según los requisitos del proyecto). Su principal objetivo es cumplir con los requisitos de evaluación acordados con el patrocinador dentro de los tiempos planificados.

T a b l a 5 9 : T a b l a d e Personas, Grupos y Roles 9.1.2 Catálogo de elementos Los elementos pueden ser de entrada y/o salida para las actividades del proceso de evaluación, siendo algunos de ellos entregables finales del proyecto de evaluación. En la siguiente tabla se detallan todos los elementos (documentos, informes, catálogos, artefactos, etc.) que se identifican a lo largo de las actividades de evaluación. Elemento Información de contacto

Detalle Documento donde la empresa evaluadora recoge los datos de contacto de la empresa cliente. Como mínimo debe presentar la siguiente información: Nombre de la empresa, la dirección, el teléfono/Fax, Página Web, Persona de contacto, Email de contacto.

Contrato de evaluación

Este

documento

representa

el

primer

entregable del


Modelo de calidad genérico

Modelo de calidad específico

Catálogo de herramientas de evaluación

Plan de evaluación

Conjunto de artefactos a evaluar

Especificación de la evaluación

proyecto de evaluación y será generado como resultado de la pla n if ica ción . En él se recogen las condiciones bajo las que se realizará el proyecto de evaluación. Está dividido en dos partes: 1. Propuesta técnica de evaluación: contiene aspectos técnicos del contrato de evaluación tales como el objetivo de la evaluación, el plan de trabajo, el equipo de trabajo, el calendario y el esfuerzo necesario. 2. Propuesta económica de evaluación: contiene aspectos económicos del contrato de evaluación tales como el precio, el modo de facturación, las cláusulas, las condiciones generales, etc. Es un documento propiedad de la empresa evaluadora y contiene el conjunto de características, subcaracterísticas y atributos de calidad que se pueden evaluar para cada artefacto software. Las características y subcaracterísticas de calidad se encuentran detalladas en la norma ISO 25010. Es un documento que solo contiene el conjunto de características, subcaracterísticas y atributos de calidad que la empresa cliente ha seleccionado para el proyecto de evaluación. Este documento es público y está integrado dentro de la especificación de la evaluación que representa el tercer entregable del proceso de evaluación. Es un documento propiedad de la empresa evaluadora y que permite identificar las herramientas necesarias y su modo de utilización, en función de las técnicas de evaluación que se vayan a utilizar para evaluar los modelos UML. Este documento público para ambas partes, y representa el segundo entregable del proyecto de evaluación. Una primera versión se desarrolla previamente al inicio del proyecto de evaluación, incluida en la propuesta técnica del contrato de evaluación. Esta primera versión es refinada por ambas partes tras la aceptación del contrato, generándose así la versión definitiva del plan de evaluación, que guiará todos los procesos y actividades realizados durante el proyecto. Este documento es generado como resultado de la planificación del proceso de evaluación y está sujeta a cambios durante todo el proyecto de evaluación. Entendiendo por artefactos los modelos UML que la empresa cliente quiere validar, y toda la documentación n e c e s a r i a para comprender correctamente la naturaleza y contenido de dichos modelos. Es responsabilidad del patrocinador que los artefactos a evaluar estén disponibles en las fechas planificadas, asi como es responsabilidad del evaluador jefe asegurar que los artefactos entregados para ser evaluados cumplen con los requisitos impuestos por las técnicas y herramientas que se van a utilizar en el proceso de evaluación. Este documento representa el tercer entregable del proyecto de evaluación y como tal es público para ambas empresas. La especificación de la evaluación será generada como resultado de la especificación del


Informe de evaluación

Petición de modificación

Información evaluación

interna

de

proceso de evaluación donde se recoje el conjunto de artefactos a analizar, el modelo de calidad específico que se va a analizar, qué técnicas se van a utilizar, qué métricas se esperan obtener, qué herramientas se van a manejar, entre otros. En definitiva un conjunto de características a evaluar por cada uno de los modelos UML, las técnicas y herramientas que se utilizarán y el listado de métricas e indicadores que se esperan obtener. Esta especificación posteriormente se incluye dentro del informe final de evaluación, conforme lo establece la norma ISO/IEC 14598. Este d o c u m e n t o representa el cuarto entregable del proyecto de evaluación y como tal es público para ambas empresas. El informe de evaluación se genera como resultado de la fase de conclusión y estará formado por un documento con todos los resultados obtenidos mediante las técnicas de evaluación, las conclusiones obtenidas del análisis de dichos resultados y un conjunto de recomendaciones y acciones futuras para la mejora de los modelos UML, además de la especificación de la evaluación. Una característica importante del informe es la retroalimentación que se produce posteriormente a la presentación de los resultados y en cuyo caso la empresa cliente reporta a la empresa evaluadora mediante el documento petición de modificación. Este artefacto representa el quinto entregable del proceso de evaluación y como tal es público para ambas empresas. Este documento se genera como resultado de la fase de conclusión y representa el documento mediante el cual la empresa cliente, manifiesta sus opiniones y posibles cambios respecto a los resultados presentados en el informe de evaluación. La empresa evaluadora recibirá el documento que evaluará, revisará y actualizará el informe de evaluación de acuerdo a los cambios sugeridos. El informe modificado será n u e v a m e n t e e ntregado a la empresa cliente. El resultado de esta petición no es más que un refinamiento del informe de evaluación así como la mejora del proceso de evaluación. Además durante la evaluación se genera documentación relacionada con el propio proceso. Esta información principalmente son informes del proceso de gestión y monitorización, informes de métricas de la propia evaluación, informes de cambios y ajustes realizados durante la evaluación, informes de defectos y adaptaciones realizadas en la infraestructura de evaluación, entre otros. Posteriormente esta información e s utilizada por los procesos Gestión de la Evaluación y Gestión de la Infraestructura para realizar una mejora continua del proceso de evaluación.

Tabla 60: Catálogo de Elementos


9.1.3 Procesos de la metodología de evaluación La metodología de evaluación EVVE se encuentra compuesta por tres procesos principales: Proceso de gestión de la evaluación, Proceso de evaluación y Proceso de gestión de la infraestructura. 9.1.3.1 Proceso de evaluación: Este proceso representa el esqueleto de la metodología de evaluación ya que contiene las fases de planificación, especificación, ejecución y conclusión del proyecto de evaluación. El proceso de evaluación se descompone en cuatro fases que son mostradas en la siguiente tabla: Fase Fase 1: Planificación

Fase 2: Especificación

Fase 3: Ejecución

Fase 4: Conclusión

Descripción El objetivo de esta fase es la elaboración del contrato y la obtención de un plan de evaluación de los modelos UML. Esta fase está formada por cuatro actividades: Contratación, Arranque del proyecto, Planificación detallada y Consolidación del plan. El objetivo de esta fase es definir el alcance de la evaluación, determinando el conjunto de características que se van a evaluar para cada uno de los modelos UML (artefactos), las técnicas y herramientas que se van a utilizar para realizar la evaluación, los niveles de evaluación (bajo, medio o alto) que se van a aplicar a cada artefacto y el listado de indicadores y métricas que se esperan obtener. Esta fase está formada por cuatro actividades: Obtención y análisis de artefactos a evaluar, Selección del modelo de calidad y las técnicas, Planificación interna de la evaluación, Verificación de la especificación. El objetivo de la fase de ejecución es la aplicación de las de las técnicas de evaluación y el lanzamiento herramientas (utilizando como entrada los artefactos a evaluar) para obtener los resultados iniciales (métricas de más bajo nivel) sobre la calidad de los modelos UML. Una vez obtenidos los resultados iniciales, es necesario asegurar su veracidad (pueden existir defectos en los resultados) y realizar su almacenamiento de una manera unificada que permita su posterior explotación. Esta fase está formada por tres actividades: Aplicación de técnicas de evaluación, Análisis de la ejecución, Unificación de resultados. El objetivo de la fase de conclusión es la elaboración del informe de evaluación y la presentación de los resultados tanto al patrocinador como al resto de personas involucradas dentro de la empresa cliente. Esta fase está formada por tres actividades: Elaboración del informe de evaluación, Presentación de resultados, Corrección del informe y finalización de la evaluación.

Tabla 61: Fases del Proceso de Evaluación


9.1.3.2 Proceso de gestión de la evaluación: Es el proceso de soporte al proceso de evaluación, que permite controlar, evaluar y mejorar el propio proceso de evaluación. Este proceso está formado únicamente por una fase, denominada de igual manera que el proceso. Esta fase a su vez se descompone en tres actividades bien diferenciadas: Monitorización, Documentación, Ajuste y Evolución. 9.1.3.3 Proceso de gestión de la infraestructura: Es el proceso de soporte al proceso de evaluación, que permite gestionar todo lo relacionado con la infraestructura necesaria para llevar a cabo el proceso de evaluación (técnicas y herramientas de evaluación). Este proceso está formado únicamente por una fase, denominada de igual manera que el proceso. Esta fase a su vez se descompone en tres actividades bien diferenciadas: Especificación de la infraestructura, Mantenimiento de la infraestructura, Adaptación y transferencia de la infraestructura. 9.2 LECCIÓN 2: IMPLEMENTACIÓN DE LA METODOLOGÍA CON SPEM Y EPFC SPEM 2.0 (Software & System Process Engineering Metamodel) es un metamodelo de OMG considerado como el estándar de facto en la industria para la representación de modelos de procesos de ingeniería del software e ingeniería de sistemas. Por otro lado, dentro de la plataforma abierta Eclipse, se ha desarrollado un editor de SPEM 2 llamado EPFC (Eclipse Process Framework Composer), que permite definir, gestionar y reutilizar un repositorio de fragmentos de métodos y procesos. De modo que con EPFC se pueden crear implementaciones en formato SPEM 2 de cualquier método, proceso o metodología de ingeniería del software. La idea central de SPEM 2 para representar procesos está basada en tres elementos básicos: rol, producto de trabajo y tarea. -

Las tareas representan el esfuerzo a hacer.

-

Los roles representan quién lo hace.

-

Los productos de trabajo representan las entradas que se utilizan en las tareas y las salidas que se producen.

9.2.1 Ventajas de SPEM y EPFC Las principales razones por las que se han seleccionado SPEM y EPFC para la implementación práctica de la metodología EVVE, frente a otras alternativas son las que se describen a continuación:


-

El formato en el que se maneja la información en las metodologías suelen ser documentos de texto natural.

-

La creación, revisión, reutilización, adaptación y generación de documentación para las metodologías suele ser un proceso puramente manual.

-

EPFC permite crear metodologías y procesos con un rico contenido (texto con formato, imágenes, elementos multimedia, etc.).

-

EPFC proporciona una estructura de gestión común para todo el contenido metodológico de una organización.

-

EPFC proporciona un entendimiento claro y visual de cómo se relacionan las diferentes tareas de una metodología.

-

EPFC permite seleccionar, combinar, adaptar y ensamblar de forma rápida procesos a partir del contenido de método creado.

-

EPFC permite publicar la documentación metodologías modelados en formato para la web.

-

EPFC reduce el coste de reutilización de contenidos de método en una organización.

de

los

procesos

y

9.2.2 Diagrama de actividad generado por EPFC A continuación, se presenta el flujo de trabajo generado por EPFC para las tareas que se realizan en la actividad Obtención y Análisis de Artefactos a Evaluar, actividad que pertenece a la fase 2 (Especificación) del proceso de evaluación especificado anteriormente. Tal y como se puede ver en la siguiente figura, esta actividad está compuesta por 3 tareas las cuales se deben realizar en orden secuencial. Además para cada una de las tareas se muestra en el margen superior izquierdo la abreviatura del rol implicado en su realización. EPFC permite la generación automática de este tipo de diagramas a partir de la información de la metodología introducida en el sistema. Además, desde este tipo de diagramas, EPFC facilita la navegación directa a cada uno de los componentes de la metodología (roles, tareas, productos de trabajo) identificando la trazabilidad bidireccional entre todos estos elementos.


Figura 38: Diagrama de actividad generado por EPFC para la actividad “Obtención y Análisis de Artefactos a Evaluar” de la fase 2 (Especificación), del proceso de evaluación. 9.3

LECCIÓN 3: EVALUACIÓN DE SOFTWARE EDUCATIVO MULTIMEDIA

Una de las aplicaciones más estudiadas en la actualidad es la Evaluación del Software Educativo Multimedia. Las características que debe cumplir un buen software multimedia formativo atienden a diversos aspectos funcionales, técnicos y pedagógicos, que se enuncian a continuación en la siguiente tabla: Característica Facilidad de uso e instalación

Descripción Hace referencia a que los programas puedan ser realmente utilizados por la mayoría de las personas, y para ello se hace necesario que sean agradables, fáciles de usar y autoexplicativos, de manera que los usuarios puedan utilizarlos inmediatamente sin tener que realizar la lectura de los manuales, ni largas tareas previas de configuración. En cada momento el usuario debe conocer el lugar del programa donde se encuentra y tener la posibilidad de moverse según sus preferencias: retroceder, avanzar, y un sistema de ayuda online solucione las dudas que puedan surgir. Además la instalación del programa deberá ser sencilla, rápida y transparente. También se debe tener en cuenta la existencia


Versatilidad (adaptación diversos contextos)

Calidad audiovisual

del

a

entorno

La calidad en los contenidos (bases de datos)

Navegación e interacción

Originalidad y uso tecnología avanzada

Capacidad de motivación

de

de una utilidad para desintalar para cuando se quiera quitar el programa. Hace referencia a la funcionalidad, es decir, que sean fácilmente integrables con otros medios didácticos en los diferentes contextos formativos, pudiéndose adaptar a diversos entornos, estrategias didácticas, y usuarios. Para lograr esta versatilidad debe tener unas características que permitan su adaptación a los distintos contextos. Por ejemplo que sean programables (que permitan la modificación de parámetros como grado de dificultad, tiempo para las respuestas, número de usuarios simultáneos, idioma), que sean abiertos (permitiendo la modificación de los contenidos de las bases de datos), que incluyan un sistema de evaluación y seguimiento o control (informes de las actividades realizadas por los estudiantes: temas, nivel de dificultad, tiempo invertido, errores, itinerarios seguidos para resolver los problemas), que permitan continuar los trabajos empezados con anterioridad, y que promuevan el uso de otros materiales (fichas, diccionarios) y la realización de actividades complementarias (individuales y en grupo colaborativo). El atractivo de un programa depende en gran manera de su entorno comunicativo. Algunos de los aspectos que más deben cuidarse son: el diseño general claro y atractivo de las pantallas (sin exceso de texto y que resalte los hechos notables), la calidad técnica y estética en sus elementos (títulos, menús, ventanas, iconos, botones, espacios de textoimagen, formularios, barras de navegación, barras de estado, elementos hipertextuales, fondo), elementos multimedia (gráficos, fotografías, animaciones, vídeos, voz, música), estilo y lenguaje, tipografía, color, composición, entre otros, la adecuada integración de medios. Además de las consideraciones pedagógicas sobre la selección y estructuración de los contenidos según las características de los usuarios, se debe tener en cuenta: La información que se presenta es correcta y actual, los textos no tienen fallas, no hay discriminaciones, la presentación y documentación. Los sistemas de navegación y la forma de gestionar las interacciones con los usuarios determinan su facilidad de uso y amigabilidad, por eso se debe tener en cuenta los siguientes aspectos: Mapa de navegación, Sistema de navegación, la velocidad entre el usuario y el programa es adecuada, el uso del teclado, el análisis de respuestas, La gestión de preguntas, respuestas y acciones, la ejecución del programa. Los programas deben presentar entornos originales, bien diferenciados de otros materiales didácticos, y que utilicen las crecientes potencialidades del computador y de las tecnologías multimedia e hipertexto en general, donde el computador resulte potenciador del proceso de aprendizaje, favorezca la asociación de ideas y la creatividad, permita la práctica de nuevas técnicas, la reducción del tiempo y del esfuerzo necesarios para aprender y facilite aprendizajes más completos y significativos. Para motivar al estudiante, las actividades de los programas deben despertar y mantener la curiosidad y el interés de los usuarios hacia la temática de su contenido, sin provocar


Adecuación a los usuarios y a su ritmo de trabajo

Potencialidad de los recursos didácticos

Fomento de la iniciativa y el autoaprendizaje

Enfoque pedagógico actual

La documentación

ansiedad y evitando que los elementos lúdicos interfieren negativamente en los aprendizajes. También conviene que atraigan a los profesores y les animen a utilizarlos. Los programas deben tener en cuenta la audiencia de los estudiantes a los que van dirigidos y los progresos que vayan realizando. Cada sujeto construye sus conocimientos sobre los esquemas cognitivos que ya posee, y utilizando determinadas técnicas. Esta adecuación se manifestará en tres ámbitos principales: Los contenidos deben ser significativos para los estudiantes y estar relacionados con situaciones y problemas de su interés, actividades de tipo de interacción, duración, elementos motivacionales, mensajes de corrección de errores y de ayuda, niveles de dificultad, itinerarios, progresión y profundidad de los contenidos según los aprendizajes realizados, Y el entorno de comunicación. Los programas multimedia utilizan potentes recursos didácticos para facilitar los aprendizajes de sus usuarios. Entre estos recursos se pueden destacar: Proponer diversos tipos de actividades que permitan diversas formas de utilización y de acercamiento al conocimiento, utilizar organizadores previos al introducir los temas, síntesis, resúmenes y esquemas, emplear diversos códigos comunicativos, incluir preguntas para orientar la relación de los nuevos conocimientos con los conocimientos anteriores de los estudiantes, tutorización las acciones de los estudiantes, orientando su actividad, prestando ayuda cuando lo necesitan y suministrando refuerzos. Las actividades de los programas educativos deben potenciar el desarrollo de la iniciativa y el aprendizaje autónomo de los usuarios, proporcionando herramientas cognitivas para que los estudiantes hagan el máximo uso de su potencial de aprendizaje, puedan decidir las tareas a realizar, la forma de llevarlas a cabo, el nivel de profundidad de los temas y puedan autocontrolar su trabajo. Además estimularán el desarrollo de habilidades metacognitivas y estrategias de aprendizaje en los usuarios, que les permitirán planificar, regular y evaluar su propia actividad de aprendizaje, provocando la reflexión sobre su conocimiento y sobre los métodos que utilizan al pensar. El aprendizaje es un proceso activo en el que el sujeto tiene que realizar una serie de actividades para asimilar los contenidos informativos que recibe. Las actividades de los programas deben estar en consonancia con las tendencias pedagógicas actuales, para que su uso en las aulas y demás entornos educativos provoque un cambio metodológico en este sentido. Por lo tanto los programas evitarán la simple memorización y presentarán entornos heurísticos centrados en los estudiantes que tengan en cuenta las teorías constructivistas y los principios del aprendizaje significativo donde además de comprender los contenidos puedan investigar y buscar nuevas relaciones. Los programas deberán tener una información acerca de sus características, forma de uso y posibilidades didácticas. Esta documentación debe tener una presentación agradable, con textos bien legibles y adecuados a sus destinatarios, y resultar útil, clara, suficiente y sencilla. Se distingue tres partes: Ficha resumen (con las características básicas del programa), El


Esfuerzo cognitivo

manual del usuario (Presenta el programa, informa sobre su instalación y explica sus objetivos, contenidos, destinatarios, modelo de aprendizaje que propone, sus opciones y funcionalidades), la guía didáctica (con sugerencias didácticas y ejemplos de utilización que propone estrategias de uso y indicaciones para su integración curricular). Las actividades de los programas, contextualizadas a partir de los conocimientos previos e intereses de los estudiantes, deben facilitar aprendizajes significativos y transferibles a otras situaciones mediante una continua actividad mental en consonancia con la naturaleza de los aprendizajes que se pretenden. Así desarrollarán las capacidades y las estructuras mentales de los estudiantes y sus formas de representación del conocimiento (categorías, secuencias, redes conceptuales, representaciones visuales) mediante el ejercicio de actividades cognitivas del varios tipos (control psicomotriz, memorizar, comprender, comparar, relacionar, calcular, analizar, sintetizar, razonamiento, pensamiento divergente, imaginar, resolver problemas, expresión, crear, experimentar, explorar, reflexión metacognitivareflexión sobre su conocimiento y los métodos que utilizan al pensar y aprender).

Tabla 62: Características de los Productos de Software Educativo Multimedia 9.4 LECCIÓN 4: MODELOS DE EVALUACIÓN DE SOFTWARE EDUCATIVO MULTIMEDIA Existe una diversidad de herramientas y modelos para la evaluación de productos de software multimea educativos, dentro de ellos se han elegido algunos que son los más representativos y de los cuales se describirá la metodología de aplicación. Cada modelo tiene unas características específicas que diferencian y a la vez complementan a los otros modelos. A continuación se hará una descripción de los modelos seleccionados, las características y componentes que deben ser evaluados. 9.4.1 Modelo de evaluación de materiales educativos computarizados de Galvis Uno de los modelos más conocidos para la evaluación de productos educativos computarizados (MEC) es planteado por Galvis, que propone un modelo que será descrito por sus componentes y criterios. Este autor establece la evaluación como actividad necesaria para la elaboración de información requerida en la toma de decisiones, siendo aplicable a cualquier sistema. Para la evaluación sistemática de los MEC, se establecen criterios relevantes y consistentes, Además de la creación de instrumentos de evaluación válidos y confiables según las fuentes de información apropiadas al respecto. Los MEC se desarrollan para satisfacer necesidades educativas que no pueden ser abordadas por otros medios de enseñanza, y por consiguiente, debe ser de calidad y viables de utilizar por parte de los usuarios a quienes va dirigido.


La evaluación sistemática de los MEC comprende evaluar los aspectos de Calidad educativa, Calidad computacional y Probabilidad de uso del recurso informático. A continuación se presentan las tablas donde se muestra las partes en que se descompone cada aspecto mencionado anteriormente. ASPECTOS Generales

VARIABLES Función educativa del tipo de MEC Función administrativa

Enseñanza

Objetivos del material Contenido Estrategias de Instrucción

Aprendizaje

Opinión y actitud del estudiante. Realimentación de su desempeño

CRITERIOS Aborda la necesidad educativa Suministra información útil para el docente El nivel de dificultad es adecuado a la necesidad educativa Es claro, conciso y actualizado. Estas son coherentes y suficientes para lograr los objetivos previstos. Es positiva frente al programa. Se ofrece en forma oportuna, amigable y adecuada.

Tabla 63: Partes de la calidad educacional del MEC ASPECTOS Generales Técnicos

VARIABLES Funciones según el usuario Características de: interfaz, programa, programación. Estructura de la información Recursos computacionales

INDICADORES Fácil de utilizar. Amigable. Claridad de instrucciones. Legibles. Bien documentada Son eficientes y adecuadas a los datos del programa Los suministrados por el equipo son utilizados al máximo

Tabla 64: Calidad computacional del MEC y sus elementos VARIABLES Requerimientos Requerimientos Requerimientos Requerimientos

de Hardware de Software de personal financieros

CRITERIOS Los diversos equipos se pueden conseguir en el mercado Los diversos softwares que amerita son fáciles de usar El personal técnico de orientación al usuario es localizable. Estos son accesibles a los aprendices del programa.

Tabla 65: Elementos considerados en la viabilidad del recurso informático En cuanto a los tipos de evaluaciones de los recursos educativos computarizados, este autor propone la Valoración comprensiva del MEC por expertos y la Prueba con estudiantes. En la siguiente tabla se muestra las variables, indicadores y criterios de valoración considerados en esta prueba. VARIABLES

INDICADORES

CRITERIOS PARA VALORAR

Relevancia y pertinencia

Contenido, objetivos. Tipo de software educativo.

El programa satisface una necesidad educativa que no puede ser lograda con otros medios existentes

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 207 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Viabilidad

Requerimientos computacionales. Requerimientos físicos.Costos

Interactividad

Participación que exige del usuario. Funciones educativas que asume el MEC.

Calidad como tipo de aplicación

El software educativo es viable de utilizar por los usuarios a quien se dirige considerando sus recursos disponibles. Los costos de adquisición y mantenimiento permiten la accesibilidad del MEC por los aprendices. El MEC emplea al máximo la capacidad de interacción que suministra el computador. El tipo o combinaciones de MEC requeridos según la necesidad educativa son un buen prototipo de estos.

Tabla 66: Elementos Considerados en la Valoración Comprensiva del MEC La evaluación por expertos del MEC, se refiere a la revisión y crítica por especialistas en contenido, metodología e informática, de grupos distintos a sus desarrolladores a fin de que exista objetividad en las apreciaciones. La valoración de software educativo por experto en contenido y en metodología se muestra en las siguientes tablas. Estas se refieren a los aspectos generales relativos a: objetivos que persigue, contenidos, motivación, metodología, interfaz y otros. Cada ítem puede ser evaluado con cinco opciones de respuesta (excelente, bueno, regular, malo, no aplica). Además en el instrumento se solicita la anotación de los defectos encontrados en el MEC, su ubicación y posible solución, junto con las fortalezas, debilidades, el uso potencial y las sugerencias para lograr su aplicación. VARIABLES Objetivos Contenido Desarrollo del contenido Herramientas Retroinformación

INDICADORES El nivel de complejidad es adecuado para el uso de software Es coherente, suficiente y actualizado en relación a los objetivos El estudiante siempre esta informado sobre su ubicación dentro del contenido. Estas son: adecuadas, sencillas de usar y facilitan la exploración. Su orientación es suficiente y adecuada a la actuación del aprendiz.

Tabla 67: Algunos elementos de la valoración por experto en contenido del MEC VARIABLES Objetivos Motivación Metodología Interfaz de salida

INDICADORES Definidos claramente. Se mantiene el interés por el logro de los objetivos. Se sustenta en una didáctica adecuada al contenido a enseñar. Las pantallas no se encuentran sobrecargadas de información. El vocabulario o terminología es apropiada para el nivel cultural del usuario.

Tabla 68: Elementos considerados en la valoración por experto en metodología Posteriormente es necesario comprobar que para los usuarios reales (docentes y estudiantes) representa un apoyo para el logro de sus objetivos. Esta labor se lleva a cabo con las pruebas: piloto (realizada a una muestra representativa de la población a la que se dirige el software) y de campo (se aplica a toda la población). Adicionalmente, se propone la encuesta final del MEC para


recabar información sobre sus aspectos didácticos, lo que permitirá hacer los ajustes y recomendaciones necesarias para su uso en el proceso de enseñanzaaprendizaje. El aporte de Galvis al modelo de evaluación de software educativo lo constituye el tratamiento sistémico de la valoración de los materiales educativos computarizados, por cuanto establece diversos tipos de pruebas (juicio de expertos en contenido, metodología e informática; pruebas piloto y de campo, encuestas a los usuarios) son realizadas por diferentes fuentes de información (informantes). Además especifica las variables, indicadores y criterios de evaluación que responden a la calidad educativa y computacional del recurso informático. En los instrumentos de evaluación resalta la consideración de los problemas del material, su localización y posible solución, junto con sus aspectos positivos, negativos y sugerencias de uso en el proceso de enseñanza-aprendizaje real. 9.4.2 Lista de control para la evaluación de software educativo de Bostock Otro de los autores que propone una lista de Control para la Evaluación de Software Educativo es Bostock, la cual ha sido reestructurada y actualizada. Las siguientes tablas presentan las variables, características más importantes y los indicadores de los aspectos técnicos y pedagógicos. En referencia a los aspectos técnicos más importantes se muestran las siguientes categorías: Protección del programa, Calidad y disposición de las pantallas e Interactividad. Al evaluar el software se debe considerar los casos en que el formato del programa tenga daños, o requiera de otro software adicional para su funcionamiento, casos donde se hace necesario disponer de otras copias del mismo y disponer de elementos de hardware adicionales para la operatividad de la aplicación. Los aspectos pedagógicos abarcan desde los objetivos hasta la adaptabilidad del software. Esta última categoría define el rol del docente durante la aplicación del software en función de lo que le permita realizar el programa frente a sus estudiantes. La evidencia de progreso del estudiante, muestra las formas como la aplicación puede llevar a cabo este seguimiento, que junto a la realimentación, establecen un posible tratamiento frente a respuestas incorrectas del aprendiz. VARIABLES Requerimientos técnicos

CARACTERÍSTICAS Y/O INDICADORES Equipos necesarios y materiales de apoyo del Software: ¿Se dispone de información sobre la capacidad de memoria y los periféricos requeridos? ¿Hay un manual sobre la instalación y la puesta en marcha del programa? ¿Especifica las características mínimas necesarias para su correcta operación? Asistencia técnica: ¿La ofrece? ¿Te ayuda a recuperar fallas? Protección del programa: ¿Posee un mecanismo de seguridad que no permite la copia no autorizada del programa? ¿Tiene el usuario un


Diseño de la Interfase

respaldo disponible? ¿Reemplazan los CDs defectuosos? ¿La información se limita a un número determinado de estaciones de trabajo? ¿Se debe mantener el CD o el Internet conectado para poder acceder al material? Validación: ¿El programa fue validado por especialistas? ¿Puede el usuario obtener una versión de prueba? Organización de la Pantalla: Se refiere al uso del espacio y la forma en que la información se despliega en la pantalla. Texto en la pantalla: ¿La presentación del texto le permite al usuario leerlo de forma sistemática? ¿Están las palabras importantes de los párrafos enfatizadas? ¿El fondo de la pantalla permite leer sin problemas el texto? ¿Hay un cambio en la página cuando se presenta nueva información? ¿El espaciado entre las palabras y las líneas es óptimo? Gráficos: ¿Se encuentran bien posicionados? ¿Son las imágenes ambiguas? ¿Hay acceso a una ilustración cada vez que sea necesario? Color: ¿Se usa el color para captar la atención hacia puntos importantes? ¿Hay suficiente contraste de color entre el fondo, los gráficos y el texto? ¿Hay colores específicos para ciertos tipos de mensajes? Sonido: ¿Puede el usuario controlar el sonido? ¿Se usa apropiadamente el sonido para captar la atención? Calidad y disposición de las pantallas: ¿Hay variedad? ¿La transición es adecuada? ¿Se pueden sobreponer? ¿Es posible controlar la velocidad de transición? ¿Se utilizan señales para atraer la atención hacia partes importantes? Interactividad: Definida para un software educativo como, si reacciona de una manera que sea variada y adaptable según las respuestas de sus diferentes usuarios y si le permite a este último afectar la manera en la cual el software procede Puede el usuario: ¿Obtener ayuda? ¿Detener el programa y salir a voluntad? ¿Ver el objetivo alcanzado hasta el momento y los que faltan? ¿Controlar la velocidad de la presentación? ¿Controlar la cantidad de información? Respecto al programa, después de elecciones del usuario: ¿Puede mostrar diferentes mensajes? ¿Puede seleccionar diferentes alternativas dependiendo de la dificultad? ¿Puede proveer una retroalimentación diferenciada adaptada? ¿Puede tomar en cuenta las diferentes formas de trabajar? ¿Puede ayudar al usuario? ¿Le da pistas o acepta respuestas aproximadas?

Tabla 69: Aspectos técnicos de la evaluación de software de Bostock VARIABLES Estructura interna software Legibilidad

Analizador de respuestas

del

CARACTERÍSTICAS Y/O INDICADORES ¿Es la división de los módulos la apropiada? ¿Están los objetivos de cada modulo explicados apropiadamente? ¿Los diferentes procedimientos tienen coherencia hacia una idea principal? Determina si es agradable para leerlo. Texto: ¿Se usa un vocabulario adecuado al nivel de educación del usuario? ¿Las oraciones están estructuradas con coherencia? Gráficos: ¿Complementan y se identifican con el texto? ¿Son de tamaño apropiado? ¿Su complejidad esta adecuada al nivel de educación del aprendiz? Consiste en todas las operaciones que se utilizan para lidiar con las respuestas en un lenguaje común. Su calidad depende de la extensión y la variedad de las respuestas que es capaz de


Contenido

Retroalimentación

Evidencia del progreso del usuario

Adaptabilidad

interpretar. ¿Hay varias maneras de expresar los mismos resultados numéricos? ¿Se especifica la unidad requerida? ¿Acepta que la respuesta numérica en unidades se exprese de distintas maneras? ¿Permite el uso de respuestas aproximadas o equivalentes semánticos? ¿Es preciso, progresivo y actualizado? ¿Contiene introducciones a los temas, o relaciones con los temas anteriores? ¿Se le da importancia a los puntos esenciales? ¿Las simulaciones corresponden con el ambiente real? ¿Contiene ejemplos apropiados? Es la información dada al usuario sobre la validez de sus respuestas ¿Es apropiada al nivel educativo del aprendiz? ¿Puede variar dependiendo de la respuesta? ¿Especifica que respuesta fue la incorrecta, por qué fue incorrecta y cuál sería la correcta? ¿Puede el usuario evaluar los resultados de una sesión de uso? ¿Puede el aprendiz llevar un registro de la experiencia de aprendizaje realizada? ¿Puede el usuario conocer los objetivos alcanzados? ¿Puede el estudiante acceder a una lista de futuras actividades sugeridas? ¿Puede el instructor modificar la documentación y/o los ejemplos? ¿Puede el docente cambiar objetivos? ¿Se puede usar el programa en diferentes intervalos de tiempo eficazmente? ¿Puede el instructor modificar la libertad y por lo tanto el progreso del aprendizaje del usuario?

Tabla 70: Aspectos pedagógicos de la evaluación de software de Bostock Esta lista de control de evaluación de software educativo aporta una variedad de preguntas que orientan al evaluador en el proceso. Otro elemento importante lo constituye la protección del programa, factor que se debe considerar cuando se presentan fallas en la aplicación. El instrumento integra explicaciones de algunas variables, aspecto que puede canalizar las dudas del evaluador y lo hace bastante concreto y práctico. Por otra parte, ofrece resultados cualitativos ya que no especifica una valoración cuantitativa de los ítems. 9.4.3 Metodología de evaluación de software educativo de Cataldi Otra de las autoras que propone un modelo de evaluación es Cataldi, quien establece la importancia de la evaluación del software educativo por el crecimiento rápido de la cantidad de éstos en el mercado. Los docentes tienen la necesidad de evaluarlos para determinar su grado de adecuación a su propio entorno, mientras que los estudiantes requieren saber cómo pueden mejorar sus aprendizajes mediante una aplicación específica. En general, el desarrollo de instrumentos de evaluación y el hecho de utilizarlos con un programa en particular y un grupo de usuarios específico no aporta resultados generalizables a todas las áreas de uso, pero ofrece orientaciones en su selección para los docentes. Cataldi propone una metodología de evaluación de software educativo en tres momentos de su ciclo de vida. Una evaluación interna realizada por el equipo de desarrolladores del programa durante la creación de prototipos. Otra externa,


aplicada al producto final por los docentes; y la evaluación contextualizada efectuada en un contexto parecido a aquel para el cual fue elaborado el software, que brinda información sobre las reacciones de los usuarios de la eficacia de la aplicación. El software educativo integra dos aspectos fundamentales a evaluar: el técnico y el pedagógico que conlleva a establecer la calidad técnica y educativa. La calidad educativa de estas aplicaciones se refiere a la potenciación de habilidades cognitivas y de adquisición de conocimientos a partir del uso del software en particular. La siguiente tabla muestra los aspectos pedagógicos, didácticos y los técnicos ASPECTOS Utilidad Pedagógicos y didácticos

Técnicos

CRITERIOS Facilidad de Uso Grado de adaptación a otros niveles de usuarios Claridad de contenidos Nivel de actualización Interfase de navegación Nivel de Motivación ¿Es adecuado para la comprensión del tema? ¿Es adecuado para el aprendizaje del tema? ¿Hay documentación y ayudas? ¿Son adecuados los recursos que necesita?

Tabla 71: Esquema de evaluación del producto final La autora sostien que el software educativo debe reunir algunas características de acuerdo a las necesidades de aplicación y los objetivos educativos a lograr, y también debe responder a la calidad y pertinencia, así se establece en la siguiente tabla el criterio de usabilidad y varios subcriterios, valorados según tres niveles: muy bueno (valorado con 3 puntos), bueno (2 puntos) y malo (1 punto). CRITERIO UTILIDAD Utilidad externa Utilidad interna

SUBCRITERIOS Velocidad de aprendizaje; facilidad de uso; nivel de adicción. Nivel de legibilidad; grado de comprensión; uso de menús, gráficos e imágenes; mensajes de errores e información; ayudas online; definición de adecuación de la interfase

VALORACIÓN Muy bueno, bueno y malo. Muy bueno, bueno y malo.

Tabla 72: Criterios y Subcriterios para Evaluación de la Calidad del Software Educativo A partir de la revisión de la información presentada en las tablas anteriores, junto al cuestionario de evaluación del producto final, se presenta la siguiente tabla que indica las características de las variables según los criterios de calidad previstos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 212 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ CATEGORÍAS Técnica

DIMENSIONES Interfase

Pedagógica

Contenidos

Condiciones relativas al usuario

ALGUNAS CARACTERÍSTICAS La interfase es amigable y de fácil manejo. El diseño general de la pantalla es adecuado. La secuenciación de las pantallas se rige por criterios. El uso de ventanas, botones, colores, tipos de letras es adecuado. El uso de iconos es correcto. La utilización de teclas rápidas es útil. Su selección es adecuada y actualizada. El programa se puede adaptar a otros niveles de usuarios. Su estructura le permite al usuario conocer hacia donde va en los aprendizajes. Se le facilita la comprensión del tema al aprendiz. Despierta su interés. Prefiere que el programa sea tutorial. Le gustaría sonidos en los videos El programa le permite ver cosas que no se hubiese imaginado.

Tabla 73: Características de las variables según criterios de calidad En cuanto a la evaluación contextualizada del software educativo, se debe realizar experiencias para establecer las diferencias en cuanto al logro de aprendizajes significativos entre un software elaborado con la metodología extendida en los aspectos pedagógicos y otro de idéntica funcionalidad pero desarrollado con una metodología tradicional. 9.4.4 Instrumento de evaluación de recursos multimedia de Soto y Gómez Soto y Gómez, proponen un instrumento de evaluación de recursos multimedia para la atención a la diversidad, denominado “EVALÚA”, que es una base de datos sobre software educativo que pretende ser un instrumento de apoyo a los docentes en la labor de evaluación y selección de recursos informáticos, con el propósito de favorecer la integración de las TIC en el sistema educativo. La ficha de evaluación del software contiene las siguientes partes: Datos del programa (datos descriptivos de la aplicación), Aspectos curriculares (relativos al currículum, destinatarios y la descripción educativa), Aspectos pedagógicos (motivación, contenidos, interactividad y las capacidades que desarrolla), Aspectos técnicos-estéticos (el entorno audiovisual, navegación y calidad de contenidos), Observaciones y valoración global. Los aspectos pedagógicos y técnicos-estéticos son valorados en una escala cuantitativa de 1 a 5 puntos, uno es muy bajo y 5 muy alto. A continuación se muestra la siguiente tabla, donde se presentan algunas características de este instrumento. ASPECTOS Datos del programa

VARIABLES Identificación del programa Requerimientos

CARACTERÍSTICA O INDICADORES Título de la aplicación. Datos del autor o empresa. Información sobre el procesador mínimo.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 213 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ técnicos

Curriculares

Pedagógicos

Tipo de adquisición del software. Tipo de dificultad que aborda Destinatarios Ubicación en el currículum Contenidos curriculares Descripción educativa del programa Capacidad de motivación Adecuación a los contenidos

Interactividad

Capacidades que desarrolla Técnico-estético

Entorno audiovisual

Navegación

Calidad de los contenidos Observaciones

Aspectos relevantes

Valoración global

Puntuación aspectos

de

Espacio que ocupa en disco. Configuración de colores y área de pantalla. La aplicación es gratuita. Un icono la indica: auditiva, visual, motorica Edad recomendada Etapa educativa. Ciclo dentro de Área/ámbito. Se presenta en orden de importancia Objetivos, niveles de dificultad, impresión, informes de evaluación

la

etapa.

opciones

de

Es motivante si: elementos del mismo (colores, animaciones, sonidos) atraen la curiosidad del aprendiz.; las actividades atraen al docente y les anima a usarlo con sus estudiantes. Los contenidos son significativos para el usuario y se relación con situaciones y problemas de su interés. Presenta niveles de dificultad acorde con los estudiantes. La velocidad entre el usuario y el programa (animaciones, lectura de datos) es adecuada. Se tutoriza la acción del aprendiz, orientando su actividad, prestando ayuda efectiva oportunamente y ofrece refuerzos positivos. Según los niveles cognoscitivos de Bloom: conocimientos, comprensión, análisis, creatividad, resolución de problemas. Diseño general claro y atractivo de las pantallas, sin exceso de texto y que resalte a simple vista los hechos notables. Calidad técnica y estética de: títulos, menús, ventanas, iconos, botones, gráficos, animaciones, videos, voz. Adecuada integración de medias al servicio del aprendizaje sin redundancias. Facilidad de uso y amigabilidad del software. Mapa de navegación bien estructurado, de acceso fácil y rápido a los distintos elementos del programa. Sistema de navegación transparente que permita al aprendiz ejercer el control efectivo sobre el programa. Información presentada científicamente correcta y actualizada. Si no hay discriminaciones, los contenidos y mensajes no son negativos o tendenciosos. Ventajas y desventajas Recomendaciones para su uso Datos de utilidad acerca de suinstalación, manejo y funcionamiento. Se ilustra con número de estrellas.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 214 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Pedagógicos y técnicos-estéticos.

Tabla 74: Algunas características de la ficha de evaluación de software Este instrumento de evaluación aporta una forma sencilla para la valoración de software educativos, integrando aspectos cualitativos con cuantitativos, utiliza símbolos para la valoración global y para identificar el tipo de dificultad que aborda. En los aspectos pedagógicos resalta el establecimiento de niveles de dificultad de acuerdo a los usuarios, además de precisar las capacidades que desarrolla el programa. Desde el punto de vista técnico-estético esta integración resulta muy favorable, permitiendo que específicamente el entorno audiovisual, presente tanto un diseño claro en las pantallas como atractivo en sus componentes. 9.5 LECCIÓN MULTIMEDIA

5:

PLANTILLAS

DE

EVALUACIÓN

DE

SOFTWARE

Al seleccionar un programa para utilizarlo en una determinada situación educativa hay que considerar dos aspectos fundamentales: sus características y su adecuación al contexto en el que se quiere utilizar. Para conocer las características de un programa, el profesor debe leer el manual e interactuar con él con el propósito de determinar sus objetivos, los contenidos, el planteamiento didáctico, el tipo de actividades que presenta, la calidad técnica, es decir, deberá realizar una evaluación del programa. Para facilitar esta evaluación objetiva de las características de un programa, se propone una ficha de catalogación y evaluación que permitirá recoger los rasgos principales del programa y algunas valoraciones sobre sus aspectos técnicos, pedagógicos y funcionales. FICHA DE CATALOGACIÓN Y EVALUACIÓN MULTIMEDIA Título del programa (+ versión, idiomas) Autores (+ e-mail) Editorial (+ año, lugar, web) Temática (área, materia)

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 215 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Objetivos . . . Contenidos que se tratan (hechos, conceptos, procedimientos, actitudes) . . . Destinatarios (características, etapa educativa) (subrayar uno o varios de cada apartado) TIPOLOGÍA: EJERCITACIÓN-TUTORIAL-BASE CONSTRUCTOR-HERRAMIENTA

DE

DATOS-LIBRO-SIMULADOR-JUEGO-

USOS POSIBLES: ENTRENAR - INSTRUIR - INFORMAR - MOTIVAR - EXPLORAR EXPERIMENTAR – EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR PROCESAR DATOS ENFOQUE NINGUNO

PEDAGÓGICO: CONDUCTISTA

-

COGNITIVISTA

-

CONSTRUCTIVISTA

-

DOCUMENTACIÓN: MANUAL - GUÍA DIDÁCTICA - MANUAL ON-LINE - GUÍA DIDÁCTICA ON-LINE - OTROS –NINGUNA Breve descripción . . . Requisitos técnicos (hardware y software) Valores que potencia o presenta ASPECTOS FUNCIONALES. UTILIDAD valorar EXCELENTE, ALTA, CORRECTA o BAJA - Eficacia (puede facilitar el logro de los objetivos que pretende)


- Facilidad de uso e instalación (entorno amable) - Versatilidad (ajustable, modificable, niveles de dificultad, evaluación, informes) ASPECTOS TÉCNICOS Y ESTÉTICOS - Calidad del entorno audiovisual (pantallas ) - Calidad en los contenidos (texto,audiovisual...) - Navegación e interacción - Originalidad y uso de tecnología avanzada ASPECTOS PEDAGÓGICOS Esfuerzo cognitivo que exigen sus actividades: marcar uno o varios • CONTROL PSICOMOTRIZ • MEMORIZACIÓN /EVOCACIÓN • COMPRENSIÓN / INTERPRETACIÓN • COMPARACIÓN / RELACIÓN (orden, clases...) • ANÁLISIS / SÍNTESIS • CÁLCULO • RAZONAMIENTO (deductivo, inductivo, crítico) • • • •

PENSAMIENTO DIVERGENTE / IMAGINACIÓN RESOLUCIÓN DE PROBLEMAS EXPRESIÓN (verbal, escrita, gráfica...) / CREAR EXPLORACIÓN / EXPERIMENTACIÓN

•

REFLEXIÓN METACOGNITIVA

OBSERVACIONES Ventajas que comporta respecto a otros medios . Problemas e inconvenientes . A destacar... . IMPRESIÓN PERSONAL. me ha gustado: si no lo recomendaría: NOMBRE DE LA PERSONA EVALUADORA Y FECHA:

si

no

Tabla 75: Ficha de Catalogación y Evaluación 9.5.1 Aspectos a considerar en la selección de producto multimedia


Para cada situación educativa concreta puede aconsejar, la utilización de determinados programas educativos multimedia como generadores de actividades de aprendizaje para los estudiantes y, por otra parte, un mismo programa puede convenir utilizarlo de manera distinta en contextos educativos diferentes. Como norma general conviene utilizar un determinado programa cuando su empleo aporte más ventajas que la aplicación de otros medios didácticos alternativos. Y en cuanto a la forma de utilización, nuevamente será la que proporcione más ventajas. La utilización de los medios debe venir condicionada por los siguientes factores: Las características del material: Hardware necesario, calidad técnica, facilidad de uso, objetivos y contenidos, actividades, planteamiento pedagógico... La adecuación del material a las circunstancias: Que caracterizan la situación educativa donde se piensan aplicar: objetivos, características de los estudiantes, contexto, entre otros. El coste: Costo del material o el esfuerzo que hay que realizar para poder disponer de él. También hay que considerar la posibilidad de utilizar otros medios alternativos que puedan realizar la misma función pero de manera más eficiente. 9.5.2 Diseño de actividades con soporte multimedia Para diseñar actividades formativas con soporte multimedia hay que tener en cuenta diversos aspectos: Las características del contexto educativo: Marco general, características. Las características de los estudiantes: Edad, capacidades, conocimientos y habilidades previas, experiencias, actitudes, intereses, entorno sociocultural. Los objetivos educativos que se persiguen: Con la realización de la actividad y su importancia dentro del marco del programa de la materia. Los contenidos: que se tratarán. La selección de los materiales didácticos: Se considerarán las características de los materiales, adecuación a la situación educativa (estudiantes, objetivos) y el costo de los diversos materiales al alcance. La función que tendrá el material: Según las características del material y según la manera en que se utilice, un mismo programa puede realizar diversas funciones: Motivación del estudiante; Fuente de información y transmisión de contenidos; Entrenamiento, ejercitación, práctica, adquisición de habilidades de procedimiento, memorizar; Instruir (conducir aprendizajes); Introducción y actualización de conocimientos previos; Núcleo central de un tema; Repaso,


refuerzo; Recuperación; Ampliación, perfeccionamiento; Entorno para la exploración (libre o guiada), descubrimiento; Entorno para experimentar, Investigar (explorar el conocimiento); Evaluación; Medio de expresión personal (escrita, oral, gráfica); Medio de comunicación; Instrumento para el proceso de datos; Entretenimiento El entorno en el que se utilizará: Espacio, en el aula normal, en la biblioteca o sala de estudio, en el aula informática, en la empresa, en casa; Tiempo, escolar/laboral, extraescolar, en casa; Otras características y condicionantes. La organización de la actividad: Se considerará especialmente: Agrupamiento, individual, parejas, grupo pequeño, grupo grande; Ámbito de aplicación, todos los estudiantes, sólo algunos estudiantes (refuerzo, recuperación, ampliación de conocimientos), sólo el profesor. La metodología: La manera en la que se va a utilizar el programa: Papel del programa (Información que facilitará al estudiante, Tareas que propondrá, Modo en que deberán realizarse); Papel de los estudiantes (Tareas que realizarán los estudiantes; Nivel de autonomía en el uso del programa, si es libre, semidirigido, dirigido, siguiendo las instrucciones específicas del profesor; Interacciones de cada estudiante (Con el programa, Con otros compañeros: consultas, opiniones, comentarios, Con el profesor: consultas, orientaciones, ayudas, Con otros materiales fuentes de información); Técnicas de aprendizaje que se utilizarán ( Repetitivas (memorizando), Elaborativas (relacionando la nueva información con la anterior): subrayar, resumir, esquematizar, elaborar diagramas y mapas conceptuales, Exploratorias: explorar, experimentar, Regulativas (analizando y reflexionando sobre los propios procesos cognitivos, metacognición)); Papel del profesor (Información inicial a los estudiantes (objetivos, trabajo a realizar, materiales y metodología, fuentes de información), Orientación y seguimiento de los trabajos (dinamización, asesoramiento y orientación); Técnicas de enseñanza que se utilizarán ( Motivación, Ejercicios de memorización, Prácticas para la adquisición de habilidades de procedimiento, Enseñanza directiva, Exploración guiada, Experimentación guiada, Descubrimiento personal, Expresión personal, Comunicación interpersonal, Metacognición. Empleo de materiales complementarios. ¿Cuáles?, cómo? El sistema de evaluación que se seguirá para determinar en que medida los estudiantes han logrado los aprendizajes previstos y la funcionalidad de las estrategias didácticas utilizadas. DISEÑO DE ACTIVIDADES CON SOPORTE MULTIMEDIA Contexto educativo .

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 219 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ Estudiantes (edad, capacidades, conocimientos...) Objetivos que se persiguen . . . Contenidos que se tratan (hechos, conceptos, procedimientos, actitudes) . . . Programa multimedia (subrayar uno o varios de cada apartado) FUNCIÓN QUE REALIZARÁ: ENTRENAR EXPERIMENTAR -

INSTRUIR -

INFORMAR

-

MOTIVAR

-

EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR - PROCESAR DATOS ENTORNO DE USO:CLASE-AULA INFORMÁTICA-OTRAS SALAS-USO EXTRAESCOLARCASA ORGANIZACIÓN: TODOS LOS ESTUDIANTES-ALGUNOS-SÓLO PROFESOR USO INDIVIDUAL - PAREJAS - GRUPO - - - TODOS A LA VEZ - SUCESIVAMENTE El programa (información que facilitará, tareas que propondrá) . . El estudiante (tareas, autonomía, interacciones, técnicas de aprendizaje) .

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD 220 ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA - ECBTI CURSO DE EVALUACIÓN DE SOFTWARE - CÓDIGO 301569__________________________________________ . El profesor (información inicial, seguimiento, técnicas de enseñanza) . . Sistema de evaluación .

Tabla 76: Ficha de Diseño de actividades 9.5.3 Aspectos a considerar en la evaluación contextual La evaluación contextual considera la forma en la que un determinado programa, independientemente de su calidad técnica y pedagógica, ha sido utilizado en un contexto educativo concreto, valorando su eficacia y eficiencia. Como en definitiva durante la sesión de trabajo con el programa los estudiantes han realizado unas actividades cognitivas, se trata de valorar en que medida han sido las más idóneas para lograr los objetivos previstos y de que manera se podía haber organizado mejor la sesión. La evaluación contextual tiene en cuenta los objetivos educativos que se pretendían y el grado en el que se han logrado, los contenidos tratados, el empleo de la infraestructura disponible, las características de los estudiantes y la estrategia didáctica utilizada por el profesor. Los objetivos educativos y los resultados obtenidos: A partir de la consideración de los objetivos educativos previstos y los contenidos que se han tratado se evalúan los aprendizajes realizados por los estudiantes para determinar el grado en el que se han conseguido. Este estudio constituye la parte más importante de la evaluación contextual. Si se han conseguido los objetivos previstos queda demostrado que la utilización del programa ha sido correcta; en caso contrario, habrá que revisar con más detalle los demás elementos: la adecuación del programa a los estudiantes, el aprovechamiento de la infraestructura y la metodología que se ha empleado. Los contenidos tratados: Su grado de profundidad y extensión. ¿Ha sido suficiente? Los recursos utilizados: Al evaluar los recursos empleados se pretende determinar el aprovechamiento que se ha hecho de los medios materiales disponibles y considerar la posibilidad de utilizarlos de otra forma más eficiente.


Los alumnos: Aquí deben considerarse las características de los estudiantes: edad, conocimientos y habilidades previas, experiencias anteriores, capacidades, estilos cognitivos e intereses, a fin de determinar el grado de adecuación de las actividades del programa a las circunstancias de los alumnos. También se considerarán aspectos como la motivación de los estudiantes durante la sesión y su opinión sobre las actividades realizadas. La organización y la metodología didáctica: La metodología didáctica utilizada por el profesor constituye el principal elemento determinante del éxito de la intervención didáctica, por lo tanto se considerarán: las actividades previas realizadas sobre la materia del programa, la motivación que ha realizado el profesor antes de la sesión, la distribución de los estudiantes, la autonomía que se les ha dado para interactuar con el programa, las sugerencias y seguimiento que ha realizado durante la sesión, las actividades posteriores, etc. Instrumentos para la evaluación contextual: La evaluación de la eficacia y la eficiencia de un programa debe realizarse a partir de la observación de su utilización por parte de los estudiantes y de los profesores y mediante la recogida de informaciones de diverso tipo: Informes ( características de los estudiantes); Informes(aprendizajes realizados y objetivos previstos); Observación e información del profesorado (utilización de los recursos disponibles, características del material, metodología utilizada); Valoraciones de los estudiantes sobre su percepción de los aprendizajes realizados, utilidad del programa y nivel de satisfacción; Valoraciones de los profesores sobre los aprendizajes realizados por los estudiantes, utilidad del programa y nivel de satisfacción.


FUENTES DOCUMENTALES Bibliografía de referencia: Allen, R. y Garlan, D. (1997). A Formal Basis for Architectural Connection. ACM Trans. on Software Engineering and Methodology. A. Cechich, M. Piattini and A. Vallecillo (Eds.). Component-Based Software Quality: Methods and Techniques, LNCS 2693, Springer-Verlag, 2003. Bosch, J. (1996). Language Support for Component Communication in LayOM. En Mühlhäuser, M. (ed.), Special Issues in Object-Oriented Programming. Workshop Reader of ECOOP’96, págs. 131–138. Dpunkt Verlag. BRAUDE. Ingeniería de software, una perspectiva orientada a objetos. México. 2003. Alfaomega grupo editor. S.A. CALERO, C. y Otros,CALERO, CORAL / MORAGA, Ma ANGELES / PIATTINI VELTHUIS, MARIO G. Calidad Del Producto Y Proceso Software. Editorial RA – MA . 2010 Cavano, J.P., McCall, J.A., A Framework for the Measurement of Software Quality, Proc. of the ACM Software Quality Assurance Workshop, pp. 133-139, Nov. 1978. De Millo, R. A. et al., Software Testing and Evaluation, Benjamin/Cummings Pub. Co., 1987. Eclipse Fundation, Foundation,2007.

Eclipse – An open

development Platform, Eclipse

Hivart, M.P.; Romain, M.M.; Software Quality measurement in complex systems, Proceedings 7th International Conference on Reliability and Maintainability; Brest, France; pp. 18-22, Jun. 1990. HUMPHREY, Watts S. Introducción al proceso de software personal. Pearson Addison wesley. 2001. ISO/IEC 9126-1:2001. Software engineering product quality part 1: Quality model. International Standard ISO/IEC 9126-1, International Standard Organization, June 2001. ISO, ISO/IEC 25000 Software and system engineering – Software product Quality Requirements and Evaluation (SQuaRE) –Guide to SQuaRE, ISO, 2005. James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software


quality, volume III: Preliminary handbook on software quality for an acquisition manager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731, 1977. Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2a ed., IEEE Computer Society Press, 1981. Norma ISO/IEC TR 9126-3: 2003 - Software engineering -- Product quality -Otto Preiss, Alain Wegmann, and Jason Wong. On quality attribute based software engineering. In Proc. of the 27th Euromicro Conference, Warsaw, Poland, September 2001. IEEE CS Press. PRESSMAN, Roger S. Ingeniería del Software. Un enfoque práctico. Quinta edición. España. 2002. Editorial McGraw Hill. Richards Adrion, W., Branstad M.A., Cherniavsky, J.C., Validation, Verification and Testing of Computer Software, Computing Surveys, Vol. 14, No 2, pp. 159-192, Junio 1982. Rodríguez Nuria, Martínez William.Planificación y evaluación de Proyectos Informáticos. Editorial Universidad Estatal a Distancia, San José, Costarrica. 2006. SOMMERVILLE, Ian. Ingeniería de software. 6ª. Edición. Pearson Addison Wesley. 2001 Direcciones Electronicas (webgrafía) http://www.pressman5.com http://www.wiley.com/college/braude http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html http://www.monografias.com/trabajos5/inso/inso.shtml http://www.sistemas.unam.mx/software.html http://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdf http://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf http://www.iso.org http://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL %209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.html http://www.gestiopolis.com/canales2/gerencia/1/modcalidad.htm

Modulo Evaluacion Software 2010

Recommend Documents